A Security Code Review Prompt Mapped to CWE

A security review prompt that says "this code might have vulnerabilities" has done nothing. Nobody can file that, fix it, or prove it's resolved. The research papers and one-off prompts that dominate this topic stop right there: they show that a model can find a flaw, then leave you with prose you can't act on.

The missing piece is structure. A security code review prompt earns its place when every finding carries a CWE ID, a severity, the exact location, and a fix, ranked so the exploitable thing is at the top. That's the difference between a demo and a tool you run on every diff.

This post is about building that prompt: mapped to CWE, triaged by risk, and reusable across files instead of rewritten each time.

Why "find the vulnerabilities" isn't enough

Point a model at code and ask for security issues, and you get a grab bag. Some real, some imagined, none ranked, none tied to anything you can track. Three failures repeat:

1. No taxonomy. Without CWE or OWASP categories, the model describes flaws in its own words, so the same bug gets named differently every run and you can't dedupe.
2. No severity anchor. A reflected XSS and a verbose error message read as equally urgent, so triage is impossible.
3. No remediation. "Sanitise the input" isn't a fix. Which input, which sink, what does safe look like here?

A mapped, triaged contract closes all three. CWE gives findings a stable identity. A severity scale ranks them. A required fix column forces the model from "this is risky" to "do this."

Anatomy of a CWE-mapped review prompt

Variables → {{code_or_diff}}, {{language}}, {{trust_boundaries}}
Role      → Application security reviewer.
Scope     → OWASP Top 10 plus the language's common CWE classes
Per finding → CWE-ID | TITLE | FILE:LINE | severity | likelihood | exploit path | fix
Triage    → sort by severity × likelihood (risk), highest first
Verdict   → counts by severity, and a ship/hold recommendation

The {{trust_boundaries}} variable matters more than it looks. Most exploitable bugs live where untrusted input crosses into trusted code: a request body hitting a query, a filename reaching the filesystem. Tell the model where those boundaries are and its false-positive rate drops sharply. Leave it out and the model flags every string concatenation it sees.

Model behavior on security review

Security review punishes sloppy prompting harder than style review, because a missed finding is an open door.

Claude tends to hold the CWE mapping and the per-finding columns across a long file, and it's comfortable saying a stretch of code is clean. GPT-4o is stronger at spotting the obscure injection sink but more likely to inflate severity and to keep listing low-value nits unless you anchor the scale. Both improve dramatically when you name the language: a security review prompt that knows it's reading Python flags pickle and subprocess shell=True; the same prompt unaware of the language treats them as ordinary calls.

Prompt-craft patterns for security work

Pattern 1: demand the exploit path

Require a one-line "how it's exploited" per finding. This single column kills most false positives, because the model has to actually trace input to sink. If it can't write the path, the finding usually isn't real.

Pattern 2: rank by risk, not by count

Risk is severity times likelihood. A critical flaw that needs admin access ranks below a medium flaw any anonymous user can hit. Make the model compute and sort on that, so the report leads with what an attacker reaches first.

Pattern 3: anchor severity to impact

critical: remote code execution, auth bypass, or data exfiltration
high:     injection or access-control flaw with a clear exploit path
medium:   exploitable only with chaining or unusual preconditions
low:      hardening gap; not directly exploitable

Without anchors, "high" means whatever the model felt. With them, severity is comparable across runs and across reviewers.

Variables you'll set

Getting started

1. Set the CWE classes in scope. The OWASP Top 10 plus your language's usual suspects is a strong start.
2. Write the per-finding row with a CWE column and an exploit-path column. Lock it.
3. Always fill {{language}}; it changes which sinks the model treats as dangerous.
4. Run it on code with a known CVE-style bug. Did it land the right CWE and rank it correctly?
5. Add "report clean files as clean; do not pad with low findings."
6. For a full assessment rather than a single file, the Application Security Audit Playbook runs a four-phase pass: map the threat surface, review against OWASP Top 10, prioritise by risk, and produce a phased remediation roadmap.

If the code you're reviewing is an AI agent rather than a web app, the relevant weakness class shifts. The Agent Prompt-Injection Defense Harness covers the injection surface that lives in repo content, issues, and tool output.

Security is one dimension of a complete review, not the whole thing. For the broader correctness-and-severity layer, see the ai code review prompt that actually finds bugs. For the agent-specific threat that a normal security review won't catch, read prompt injection defense for AI agents.