Running a Claude Code security review that finds real bugs

It is a model reading your code with a security-shaped prompt. Run /security-review in a session and it examines your pending changes and reports findings. There is also a GitHub Action form of the same idea that comments on pull requests. Underneath, both are the same thing: read the diff, trace where untrusted input goes, report.

Understanding that it is prompt plus diff, and not a static analyser, explains everything about how it behaves. It has no rule database. It is not deterministic. Run it twice and you get overlapping but different findings. And it can reason about code that a rules engine cannot parse, which is the actual advantage.

Where it is genuinely strong

• Taint tracking through your own helpers. A request parameter that reaches a query builder five functions later, through a wrapper that a pattern matcher would not follow.
• Authorisation gaps. A new endpoint that checks authentication and forgets to check that the record belongs to the caller. This is the most common real finding we see.
• Secrets and tokens ending up in logs, error messages, or exception payloads sent to a third party.
• Unsafe deserialisation and template rendering with user-controlled input.
• Missing output encoding in one branch of a component where the other three branches do it correctly.

The last two categories matter because they are the ones humans skim past. A reviewer reads the interesting part of a diff carefully and the repetitive part quickly. The model reads all of it at the same level of attention.

Where it fails, and how

It reviews what changed. It cannot tell you the feature should not exist, that this data should never have been collected, or that your tenancy model has a hole that predates the diff. Design review is still a person's job.

False positives cluster in predictable places. Test fixtures with hardcoded credentials get flagged as leaked secrets. Internal admin tooling gets flagged for missing rate limits. Code that is protected by a gateway or middleware the model cannot see gets flagged for missing auth. That last one is the expensive one, because the fix is to tell the model where the protection lives, not to add a second check.

It also has no severity calibration of its own. Everything arrives sounding urgent. Somebody has to triage, and if nobody does, engineers learn to close the report unread.

Making the findings worth reading

Give it the context that changes the answer. In CLAUDE.md, write down where authentication and authorisation are enforced, which directories are test-only, what your trust boundaries are, and which sinks are already safe by construction. Four or five lines is enough:

Auth: all /api routes pass through requireSession in middleware.ts. Tenant scoping is enforced in db/scope.ts, never in handlers. Anything under fixtures/ is test data, not production secrets.

Then narrow the ask. A review of a whole repository produces a long, shallow list. A review of one pull request produces findings you can act on today. Run it on the diff, before a human reviews, so the human never spends attention on a missing encode.

Measure one number: the share of findings that led to a code change. Under one in five and your context file is the problem, not the model.

What to do next

Find the last security bug your team shipped, check out the commit before the fix, and run the review against that diff. If it catches the bug, you know what it is worth. If it does not, you know which context you failed to write down. Either result is worth the hour.

If you want help putting this into practice, talk to us.