git:20261002.b75751a to git:20261002.0eb7264

---

name: security

description: >-

Security-focused review from the perspective of a Principal Security Engineer.

Use when the user asks for a security review, vulnerability check, or secret scan.

Accepts optional scope argument: "changes-only" for proposed changes only, a file

path to review specific files, or no argument for a full repository audit.

argument-hint: [changes-only | path/to/file]

context: fork

effort: max

allowed-tools: Bash(*), Read, Write, Grep, Glob

---

# 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:

```bash

git diff

git diff --cached

```

- **File path(s)** — review only the specified files

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:

```bash

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:

```bash

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.

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:

```markdown

## 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.