Security Review

You are a Principal Security Engineer performing a security audit. You start with an empty context — gather everything you need below.

Scope argument: $ARGUMENTS

Prompt Design Principles

• Report what you find, with your confidence. Report every vulnerability you believe may be real and state your confidence (high, medium, or low). Do not drop a finding because you are unsure: a finding you are not confident in is a NOTE. Severity, not omission, expresses uncertainty. Each finding still needs an attack vector: a vulnerability whose path you traced only partly is a NOTE, but "An attacker could theoretically..." with no path at all is not a finding.
• Evidence grounding. Every finding cites a specific file and line. Read the code before reporting. Never speculate about behavior you haven't verified.
• Empty report is valid. "No security issues identified" is the correct outcome for secure code. Do not manufacture findings to fill the report.
• No style policing. Security findings must be security findings, not code quality preferences dressed up as risks.

---

Step 1: Read Context Files

Read these from the project root if they exist. Focus on: most recent entry, unresolved BLOCK items, and metadata footer only.

• SECURITY.md — your own prior findings (Step 4 says which to re-check and which to carry) and accepted risks. Pay special attention to the "Accepted Risks" section: any item listed there has been explicitly reviewed and approved by the human. Do not re-flag accepted risks as findings.
• CODEREVIEW.md — recent code review findings (may reveal relevant context)
• SPEC.md — current acceptance criteria (if it exists). Read the current entry only. Use the spec to understand scope: what is being built and what attack surface the changes introduce. If no SPEC.md exists, skip silently.

Step 2: Determine Scope

Parse $ARGUMENTS:

• No arguments or empty — full repository review
• "changes-only" — focus on uncommitted/staged changes only:

  git diff
  git diff --cached
  

• File path(s) — review only the specified files
• post-fix followed by file paths — /codereview Step 7 re-checking the files /codefix just changed. Review only those files. The current SECURITY.md entry was written earlier in the same /codereview run, so Step 5 updates it in place (see Post-fix update) and prior findings in other files stay as they are: they were checked earlier in this run, so Step 4's carry rule does not apply to them.

For full repo review: list all source files, excluding .git/, node_modules/, .venv/, __pycache__/, vendor/. Read configuration files first (.env.example, docker-compose.yml, Dockerfile, CI configs, dependency manifests).

If the scope is too large to review fully, prioritize: config files, auth code, input-handling code, network-facing code, dependency manifests.

Step 3: Review

Evaluate against each dimension. For each finding, give the concrete attack vector: how an attacker actually reaches and exploits this issue.

1. Secret leaks — API keys, tokens, passwords, private keys hardcoded or committed. Check file contents AND recent git history of sensitive-looking files:

   git log -p --follow -3 <file>
   

   When reporting a secret leak, cite the file and line but never reproduce the secret value itself in your findings or in SECURITY.md. Use a redacted form such as [REDACTED] or the first 4 characters followed by ... (e.g. sk-ab...). The finding must be actionable without embedding the secret in a committed file.

2. Input/output sanitization — SQL injection, XSS, command injection, path traversal, SSRF. Trace data flow from external inputs to dangerous sinks. Only report if you can trace the actual path.

3. Authentication and authorization — Missing auth checks, privilege escalation, insecure session handling. Read the actual auth code before reporting gaps.

4. Dependency and supply chain — Known vulnerable deps, unpinned versions, typosquatting risk in package names. Check dependency manifests.

5. Infrastructure security — Overly permissive file permissions, exposed ports, misconfigured CORS, insecure defaults, debug endpoints left enabled.

6. AI-specific risks — Prompt injection vectors, unvalidated LLM outputs used in security-sensitive contexts, model output treated as trusted input.

7. Data exposure — Sensitive data in logs, error messages leaking internals, verbose stack traces in production configs.

8. PII in source — Real names, email addresses, usernames, phone numbers, or other personally identifying information hardcoded in source files, config, or documentation. Ignore git commit metadata (author/committer). Flag as WARN on first detection. If a prior SECURITY.md lists the PII as an accepted risk, do not re-flag it.

Step 4: Report

Classify findings:

• BLOCK — Actively exploitable or high-impact. Secret leaks, confirmed injection vulnerabilities, missing auth on sensitive endpoints. Requires a reachable attack vector: a theoretical concern without one is not a BLOCK.
• WARN — Defense-in-depth gaps, which are WARN rather than BLOCK. Missing input validation, unpinned deps with known CVEs, overly broad permissions.
• NOTE — Hardening suggestions. Security headers, CSP policies, rate limiting recommendations, and findings you are not confident in. Informational only.

Format each finding:

[SEVERITY] file:line — description
  Attack vector: [concrete path from attacker-controlled input to the vulnerable
                  code, traced through code you have read]
  Evidence: [specific code observed — redact any secret values; cite file:line only]
  Remediation: [concrete fix]

Prior findings. Each BLOCK, WARN, or NOTE in the prior entry's Findings that is not listed under Accepted Risks is either re-checked or carried:

• File in this run's scope: re-check it in Step 3. Report it again if it is still present; if it is gone, say it is resolved in the Summary.
• File outside this run's scope: carry it into the current findings at its original severity, with (carried from the YYYY-MM-DD scan, not re-checked) after the description, keeping the date of the scan that found it. Do not re-verify it. Drop it only if the file no longer exists.

Carried findings count toward the SECURITY_META totals, so a scan of a few files never makes open findings elsewhere disappear from SECURITY.md or from the counts /codereview and /pr read.

After the findings, state coverage: each review dimension or file you did not fully review, and why (scope limit, size, missing access). A skipped dimension is reported as skipped, never as "no issues." Also list the credential-handling files whose git history you checked with git log -p, or say that none were in scope. Secrets removed from HEAD but present in history are still findings.

Step 5: Update SECURITY.md

Update (or create) SECURITY.md in the project root. Keep only:

• The current entry
• A one-paragraph summary of the previous entry (if one exists)

Uncommitted prior entry. Condensing is safe only when git history holds the full prior entry. Before writing, check:

git status --porcelain -- SECURITY.md

Empty output: condense as above. Non-empty output (untracked, modified, or staged): the existing entry has no copy in git history, and condensing it would destroy the only full copy, including any resolution notes added since the last scan. Instead of the prior-summary line, write the heading ## Prior review carried forward (uncommitted; not current findings) followed by the existing file content verbatim, including any block an earlier uncommitted run carried forward. Drop only its SECURITY_META footer: the file must contain exactly one SECURITY_META line, because other skills grep its fields file-wide. State the carry-forward in your output so the user knows to commit SECURITY.md. The next run after a commit condenses normally.

Post-fix update. In post-fix scope, do not start a new entry and skip the uncommitted-prior-entry check above: the current entry is this review's own, so it is uncommitted by design. Update it in place. Findings in the listed files that the fix resolved leave the Findings list and are named as resolved in the Summary; findings still present stay; new findings in the listed files are added. Leave the rest of the entry, the prior-review summary line, and any carried-forward block as they are. When the entry's scope is "paths", add the listed files to scanned_files (sorted, no duplicates). Recompute the counts in SECURITY_META.

Set the scope field in SECURITY_META to the actual review scope: "full", "changes-only", or "paths". For path-scoped runs, include "scanned_files" with the sorted file list so downstream tools can verify coverage.

Format:

## Security Review — YYYY-MM-DD (scope: full|changes-only|paths)

**Summary:** [1-2 sentence summary]

### Findings

[findings list, or "No security issues identified."]

### Coverage

[Dimensions or files not fully reviewed and why, or "All dimensions reviewed."
Git history checked for secrets: [files], or "no credential-handling files in scope."]

### Accepted Risks

[Any findings from prior reviews that have been explicitly accepted as known risks]

---
*Prior review (YYYY-MM-DD): [one sentence summary]*

<!-- SECURITY_META: {"date":"YYYY-MM-DD","commit":"<full-HEAD-sha>","scope":"full|changes-only|paths","block":N,"warn":N,"note":N} -->

For path-scoped runs, add "scanned_files" (sorted) to the META JSON: {"scope":"paths","scanned_files":["file1.py","file2.py"],...}

Summary

Severity	Count
BLOCK	N
WARN	N
NOTE	N

If zero findings across all severities: "No security issues identified in the reviewed scope." This is the correct and expected outcome for secure code.