security-review

Security Review

Treat security as a design and verification gate. Perform the lightweight form for every feature; expand it whenever data, privileges, trust boundaries, or availability are affected.

For first-run adoption of an existing application, remain read-only until the Adopt Existing Project approval gate completes. Produce requirement-level ASVS and framework gap evidence during assessment; do not silently implement fixes.

Mandatory pre-implementation gate

Before writing implementation code:

1. Describe the feature, assets, actors, entry points, data flows, external dependencies, privilege levels, and trust boundaries.
2. State data classification, retention, tenant boundaries, and abuse cases.
3. Produce a STRIDE table covering all six categories. For each category record: threat | applicable/N/A with reason | mitigation | planned verification.
4. Identify applicable OWASP ASVS 5.0.0 Level 2 requirements. Use versioned IDs such as v5.0.0-8.3.1; do not claim Level 2 compliance from chapter names alone.
5. Map applicable OWASP Top 10:2025 risks and explicitly check SSRF even though it is no longer a standalone 2025 category.
6. Map the design to all six NIST CSF 2.0 functions: Govern, Identify, Protect, Detect, Respond, and Recover.
7. Apply Zero Trust: no implicit trust from network location, device ownership, client state, or prior access. Authenticate and authorize access to each protected resource using server-side policy.
8. Mention the selected mitigations before implementation. Do not continue when a critical threat has neither a mitigation nor an explicitly accepted owner.

For a cosmetic or documentation-only change, still state that no executable behavior, trust boundary, protected asset, or sensitive data flow changed and mark the framework checks N/A with that reason.

Implementation invariants

• Verify authorization at object and operation level on every server-side path.
• Treat the frontend, hidden UI, cookies, headers, query parameters, path parameters, request bodies, filenames, redirects, webhooks, queues, caches, and upstream responses as untrusted.
• Validate type, structure, range, length, encoding, canonical form, and business rules before use; encode output for its destination context.
• Use parameterized interfaces and maintained platform security primitives.
• Deny by default, grant least privilege, separate duties, and fail securely.
• Bind security decisions to current server-side identity, tenant, resource, action, device/workload context when available, and policy—not client claims.
• Protect secrets and keys with managed stores; never log credentials, tokens, sensitive payloads, or unnecessary personal data.
• Make security events attributable and tamper-resistant without exposing data.
• Bound CPU, memory, request size, concurrency, retries, and expensive actions.
• Pin and review dependencies and build provenance; verify artifacts before use.

Post-implementation gate

1. Revisit every STRIDE row and test each mitigation.
2. Record each applicable ASVS L2 requirement as pass, fail, or N/A with evidence. A scanner result alone is not ASVS verification.
3. Review all OWASP Top 10:2025 categories plus the explicit SSRF gate.
4. Execute abuse and negative tests for unauthorized, cross-tenant, malformed, replayed, oversized, concurrent, rate-limit, timeout, and dependency-failure scenarios where applicable.
5. Run available SAST, dependency, secret, IaC, container, and dynamic scans that match the changed surface. Triage findings by exploitability and impact.
6. Verify NIST Detect/Respond/Recover outcomes: useful telemetry, alert path, containment or revocation, rollback, restoration, and lessons learned.
7. Report residual risks, owner, severity, due date or acceptance, and evidence.

Read references/checklist.md for the operational framework checklist and references/framework-crosswalk.md when mapping a feature across frameworks.