Security Review
Use this workflow before merging or releasing changes that touch authentication, authorization, data handling, network surfaces, infrastructure, dependencies, or LLM-facing inputs.
Workflow
- Establish the review scope with the user request, current branch, pull request, commit range, or changed files.
- Inspect the diff first, then read the smallest amount of surrounding code needed to validate each candidate issue.
- Review by concern:
- Injection: SQL, NoSQL, shell, template, deserialization, path traversal, prompt injection.
- Authn/Authz: session handling, tokens, RBAC, object-level authorization, privilege boundaries.
- Secrets: committed credentials, unsafe logging, insufficient redaction, private key material.
- Supply chain: new dependencies, unpinned executables, lockfile drift, install scripts.
- Infrastructure: public exposure, missing encryption, weak defaults, overly broad permissions.
- Business logic: state bypasses, replay, race conditions, idempotency, rollback gaps.
- Confirm reachability before reporting a finding. Do not report pattern matches that cannot execute.
- Redact any secret values. Cite only enough structure to identify the issue safely.
- Rank findings by severity and provide concrete fix directions.
- If no issues are found, say so clearly and note the remaining verification gaps.
Final Report
Lead with a verdict: Ready to Merge, Needs Attention, or Needs Work.
For each finding, include:
- severity
- file and line when available
- reachable path or trigger
- what can fail
- why it matters
- concrete fix direction
End with reviewed scope, verification consulted, and residual risks.
1---2name: security-review-23description: Review a diff for concrete security risks across injection, authn/authz, secrets, supply chain, infrastructure, and business logic.4---56# Security Review78Use this workflow before merging or releasing changes that touch authentication, authorization, data handling, network surfaces, infrastructure, dependencies, or LLM-facing inputs.910## Workflow11121. Establish the review scope with the user request, current branch, pull request, commit range, or changed files.132. Inspect the diff first, then read the smallest amount of surrounding code needed to validate each candidate issue.143. Review by concern:15 - Injection: SQL, NoSQL, shell, template, deserialization, path traversal, prompt injection.16 - Authn/Authz: session handling, tokens, RBAC, object-level authorization, privilege boundaries.17 - Secrets: committed credentials, unsafe logging, insufficient redaction, private key material.18 - Supply chain: new dependencies, unpinned executables, lockfile drift, install scripts.19 - Infrastructure: public exposure, missing encryption, weak defaults, overly broad permissions.20 - Business logic: state bypasses, replay, race conditions, idempotency, rollback gaps.214. Confirm reachability before reporting a finding. Do not report pattern matches that cannot execute.225. Redact any secret values. Cite only enough structure to identify the issue safely.236. Rank findings by severity and provide concrete fix directions.247. If no issues are found, say so clearly and note the remaining verification gaps.2526## Final Report2728Lead with a verdict: `Ready to Merge`, `Needs Attention`, or `Needs Work`.2930For each finding, include:3132- severity33- file and line when available34- reachable path or trigger35- what can fail36- why it matters37- concrete fix direction3839End with reviewed scope, verification consulted, and residual risks.
s-hiraoku