Security Context (Addendum)
Harden engineering work by adding security constraints to story artifacts.
Inputs
- •Tech vision docs (if provided)
- •PRD (
{ide-folder}/{outputFolder}/product/prd/.../US-*.md) - •Technical context (if exists)
- •Technical plan (if exists)
Output
{ide-folder}/{outputFolder}/task/{epicNumber}-EPIC-{epicName}/US-{usName}-{usNumber}/security-addendum.md
How to Operate
- •If only
technical-context.mdexists: focus on constraints, threat model, missing info - •If
technical-plan.mdexists: propose concrete security constraints (no code) - •If both: consolidated addendum, clearly state what applies to context vs plan
Required Structure
yaml
Epic ID: EPIC-{epicNumber}
User Story ID: US-{usNumber}
Document: Security Addendum
Status: Draft | Ready
Owner: Security Engineer (Addendum)
Last Updated: (ISO timestamp)
Inputs: (list exact paths)
| # | Section | Content |
|---|---|---|
| 1 | Security objectives | What must be protected and why (1-5 bullets) |
| 2 | Mini threat model | Assets, actors, trust boundaries, abuse cases (top 3) |
| 3 | Multi-tenancy isolation | MANDATORY - tenant boundary, "must never happen" list |
| 4 | Security requirements | SEC-REQ-01... - specific, testable. Cover: AuthN/Z, input validation, CSRF, rate limiting, logging, secrets, error handling |
| 5 | OWASP Top 10 mapping | Only relevant items, not generic checkbox |
| 6 | Privacy / GDPR constraints | Data minimization, retention, access/export, logging |
| 7 | Security Verification Matrix | MANDATORY - SEC-REQ-* → tests/checks |
| 8 | Required changes to Technical Plan | Explicit additions/edits with SEC-REQ-* / AC-* refs |
| 9 | Open questions / assumptions | Only blockers, propose safe defaults |
Guardrails
- •Do not write implementation code
- •Do not expand product scope
- •Prefer requirements enforceable by tests and automated checks
- •If architecture is unsafe, say so clearly and propose safer options
- •Run
/sync-issueafter writing