Security Review of a Diff
Perform a focused security review of a code change or diff and produce a vulnerability report mapped to a threat checklist. First scopes the change's attack surface and locks a security checklist (injection, authn/authz, secrets, deserialization, SSRF, crypto misuse, input validation, dependency risk), then audits the diff against each class while tracing tainted data from untrusted sources to dangerous sinks, then writes a findings report rating each issue by severity and likelihood with a concrete remediation. Use this for a security review, secure code review, vulnerability assessment of a diff, an AppSec pass, or checking a change for injection/auth/secret-leak risks before merge — it surfaces exploitable flaws tied to specific lines rather than generic security platitudes.
Steps
Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.
- Scope the attack surfacereviewerentry
map trust boundaries, lock a security checklist
Show working prompt
Step 1: Read the diff and identify the attack surface it touches: new/changed endpoints, inputs from untrusted sources (HTTP params, headers, files, env, third-party data), data sinks (SQL, shell, filesystem, eval, HTML render, outbound requests), and any auth/permission logic. Step 2: Map the trust boundaries — where does untrusted data enter and where could it reach a dangerous operation. Step 3: Write a security acceptance-criteria checklist tuned to this change, drawn from: injection (SQL/command/template/XSS), broken authn/authz (missing checks, IDOR), secrets handling (no hardcoded keys, no secrets logged), unsafe deserialization, SSRF/path traversal, crypto misuse (weak algo, static IV, no salt), missing input validation, and risky new dependencies. Step 4: For each item, state what 'safe' looks like for THIS diff (e.g. 'all SQL uses parameterized queries', 'the user-supplied filename is canonicalized and confined to the upload dir'). Step 5: Record assumptions and out-of-scope areas. Write the surface map + checklist to `write_task_note` AND `notes/scope.md`. No findings yet.
- Audit for vulnerabilitiesreviewer
trace tainted data to sinks, check each threat class
Show working prompt
Step 1: For each untrusted input identified in scope, trace it through the code to every sink it can reach — flag any path where it hits a sink without validation/escaping/parameterization (that is the vulnerability). Step 2: Walk EACH checklist threat class against the diff and the code it calls, looking for concrete violations, not theoretical ones. Step 3: For every finding capture: file:line, the vulnerability class, an exploit sketch (how an attacker triggers it), severity (critical/high/medium/low) and likelihood, and a concrete remediation (parameterize this query, add this authz check, move this secret to env). Step 4: Verify the negatives too — confirm the dangerous-looking spots that are actually safe and note WHY (so the report is trustworthy). Step 5: Note anything requiring dynamic testing you could not perform statically. Good looks like: a finding with a real taint path from source to sink, not 'consider validating inputs'. Stage findings to `write_task_note`. Do not write the report yet.
- Write the security reportreviewer
findings with severity, exploit, remediation
Show working prompt
Step 1: Open `security-review.md` and write a top-line verdict: Safe-to-merge / Merge-after-fixes / Block, with the count of findings by severity. Step 2: Add a '## Findings' section; for each, write `### [SEVERITY] class — file:line` with the exploit sketch, the impact, the likelihood, and the concrete remediation. Order by severity then likelihood. Step 3: Add a '## Verified safe' section noting the threat classes you checked and found clean (so the review's coverage is auditable). Step 4: Add a '## Not statically verifiable' section for anything needing a pentest/runtime check. Every finding must have a concrete taint path or rule violation and a specific fix — no generic advice. On a loop-back, fix only the named gaps without dropping real findings. `write_task_note` the report path and the severity counts.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Open `security-review.md` and grade it against the scope checklist. Check EACH criterion and write PASS/FAIL with a one-line reason: (1) every threat class in the checklist was assessed (found-and-reported or verified-safe); (2) each finding is pinned to file:line with an exploit sketch; (3) each finding has a severity and a concrete remediation; (4) tainted-data paths from untrusted source to sink are traced where applicable; (5) a Verified-safe section makes coverage auditable; (6) the verdict matches the findings (no 'Safe-to-merge' with an open critical). If any criterion fails, name the exact gap and loop back. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "report" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- security review
- is this change secure
- check this diff for vulnerabilities
- secure code review
- appsec review
- review for injection
Source
View this craftbook on GitHub · MIT license