Security & Rollback (High-Risk Track)

When a plan is High-Risk, security is not a later phase — it is a constraint on the design. This skill makes the master-planner add a threat model, hardening boundaries, and a rollback plan to spec.md before the plan is approved.

Adapts the threat-model-first, three-tier-boundary, and OWASP-prevention model from addyosmani/agent-skills security-and-hardening (MIT). See docs/ATTRIBUTION.md.

Step 1 — Threat model first (five minutes, like an attacker)

1. Map trust boundaries — where untrusted data crosses in: HTTP requests, form fields, file uploads, webhooks, third-party APIs, message queues, and LLM output. Every boundary is attack surface.
2. Name the assets — what's worth stealing/breaking: credentials, PII, payment data, admin actions, money movement.
3. Run STRIDE over each boundary (a lens, not a ceremony):

4. Write abuse cases next to use cases — for each feature, "how would I misuse this?" becomes the first test.

If you can't name the trust boundaries, the plan isn't ready to be secured (OWASP A04: Insecure Design).

Step 2 — Record the three-tier boundary set in the spec

• Always: validate all external input at the boundary; parameterize DB queries; encode output (anti-XSS); HTTPS everywhere; hash passwords (bcrypt/scrypt/argon2); security headers (CSP/HSTS/X-Frame-Options); httpOnly+secure+sameSite session cookies; dependency audit before release.
• Ask first (human approval): new/changed auth flows; storing new categories of sensitive data; new external integrations; CORS changes; file-upload handlers; rate-limit changes; granting elevated roles.
• Never: commit secrets; log sensitive data; trust client-side validation as a boundary; disable security headers; eval()/innerHTML with user data; store auth tokens in client-accessible storage; expose stack traces to users.

Step 3 — Cover the high-frequency risks in the plan

Note the prevention approach for whichever apply: injection (parameterized queries/ORM), broken auth (hashing + secure sessions), XSS (framework auto-escaping / sanitize), broken access control (authorize per resource, not just authenticate), security misconfig (helmet/headers/CORS allowlist), sensitive-data exposure (field allowlists, env-var secrets), SSRF (allowlist scheme+host, reject private/reserved IPs, forbid redirects), and — if the app calls an LLM — treat model output as untrusted input, keep secrets/other-users' data out of prompts, and scope tool/agent permissions (OWASP LLM Top 10).

Step 4 — Rollback and operability

Add to the spec a Deployment & Rollback section: deployment target, CI/CD approach, how to revert (the rollback procedure), what signals indicate a bad deploy, and the data-migration reversal plan (if any). A "production-ready" claim without a rollback plan is [NO RELIABLE DATA].

Step 5 — Security review checklist (hand to plan-griller)

Authentication (hashing, secure sessions, login rate-limit, expiring reset tokens); Authorization (per-endpoint checks, users access only their own resources, admin role checks); Input (boundary validation, parameterized queries, output encoding, SSRF allowlist); Data (no secrets in VCS, sensitive fields excluded from responses, PII encrypted at rest); Infrastructure (security headers, CORS restricted, deps audited, no internal errors leaked); Supply chain (lockfile committed, npm ci in CI, new deps reviewed); AI/LLM if used (output treated as untrusted, secrets out of prompts, tool permissions scoped).

Anti-Rationalization