External Publication
Visit Post

Claude Code Security Review: CodeGuard vs the Built-in Tools

CyberDesserts June 20, 2026
Source

June 2026

Claude Code can review your code for security flaws. Type /security-review and it scans your project for injection, exposed secrets, request-forgery risks and the rest, then hands back findings with severity and file locations. That is the native feature, and on its own it works well.

But it is rarely the only reviewer you can run. I tried three against the same codebase: the built-in /security-review command, the third-party Project CodeGuard skill, and Claude with no framework at all, simply asked to check the code for security issues. They broadly agreed on what mattered. Where they diverge is worth testing, and I can share what I have found so far. CodeGuard is a useful addition to /security-review and worth exploring to up your game, but installing it quietly changes what /security-review runs, which is easy to miss.

The security reviewers and what they do

Ask for a Claude Code security review and you could mean one of several things, which can cause confusion.

The native /security-review command is a built-in Claude Code feature, documented by Anthropic since early 2026. You run it in the terminal for an on-demand check, typically before committing, and the same engine is available as Anthropic's claude-code-security-review GitHub Action that reviews pull requests automatically. Project CodeGuard is something else: an open-source, model-agnostic ruleset from CoSAI, the Coalition for Secure AI, originally built by Cisco's security team and donated to the OASIS-hosted project in early 2026. It ships as a Claude Code skill carrying 23 rules and applies them across the repository. The third is no tool at all, just Claude asked to review the code with no ruleset behind it.

There is also a fourth reviewer you will meet on a current install: Anthropic's security-guidance plugin, released May 2026. It runs automatically in three layers as you code, an instant pattern check on every edit, a model-backed review of the diff at the end of each turn, and a deeper cross-file review at commit, and it can fix what it finds in the same session. I left it out of the comparison because it runs continuously rather than being something you invoke and point at a target, which is what the three below have in common. Worth knowing it exists, and worth running, but it is a different kind of tool and collectively important.

So I got the three reviewers looking at the same codebase.

Where they agreed, and where they split

All three flagged the same top two issues: a request-forgery risk where user input could reach an internal address, and a live credential sitting in the working tree. Three independent passes converging on the same priorities is the strongest signal you get that a finding is real.

Where they split is more useful. CodeGuard, scoped to one language on its first run, missed issues elsewhere in the stack. The unstructured pass caught a resource-exhaustion risk the checklist under-weighted, and it went further than the others in one respect: it verified a tenant-isolation boundary was clean rather than asserting it.

That looked like a tool limitation at first. It was not. Run CodeGuard across the whole repository instead of one language and it reaches the authentication and frontend surfaces fine, catching trust-boundary and configuration issues the narrower run missed first time. The blind spot was the scope I gave it, not the tool. An AI security review is only as wide as what you point it at, and two runs of the same reviewer can hand you two different blind spots.

Which one earns a place in your workflow depends on what you are building and how you work, so it is worth running all three for a while before you settle. The point is not to crown one. It is to stop relying on a single method.

Watch for the name collision

Here is the part that needs checking, and it is worth your attention when you install so you can verify the behaviour.

Type /security-review with CodeGuard installed and you do not get Anthropic's command. You get CodeGuard's. The plugin ships a skill named security-review, which collides with the built-in command of the same name, and Claude Code's documented rule is that when a skill and a command share a name, the skill wins. The behaviour is in Anthropic's own slash-command documentation and logged as a GitHub issue. It is expected platform behaviour rather than a bug.

The name collision, visible in the picker. Both are called /security-review; the skill takes precedence when you type the bare command.

What is not documented is the collision. CodeGuard's plugin page does not mention that its skill shares a name with the built-in command, so the precedence is easy to walk into unaware. I confirmed it both directions: with the plugin enabled, the command ran CodeGuard; disabled, the same command reverted to the native security reviewer.

The practical point is simple: once CodeGuard is installed, a plain /security-review runs the skill, not the native command. Open the command picker and you will see both entries sitting under the same name. Check which one a bare invocation runs, so you know what you are actually running.

Get the most from a finding: understand it before you fix it

None of this is an argument against AI code review. It is an argument for not trusting it blind, like any other area of AI usage you need to question the output.

Run more than one. Where they agree, you can be fairly confident a finding is real; where they disagree, you have a potential false positive to rule out or something only one of them caught.

When a tool flags something, that is where your work starts. Understand why it is a problem before you reach for a fix, and dig into the mitigations and their trade-offs, because the same finding can warrant a one-line guard or a structural change. Get that wrong and it cuts both ways: you over-engineer something trivial, or you patch the surface and leave the deeper flaw in place. The fix the tool suggests can be scoped wrong too, so if something does not sound right, research it and say so rather than applying it on trust. Take a session-management finding. Until you understand the attack behind it, an adversary-in-the-middle scenario, say, you cannot tell whether the suggested fix closes the real exposure or just quiets the warning. Careful scrutiny is the part you should exercise. Question the logic on every point.

Watch for context pollution

A long session is not a neutral reviewer. The more it has worked on one thing, the more its attention narrows to that theme, and it carries that frame into whatever you ask next. Call it context pollution: the session so shaped by what came before that it reviews new code through an old, narrow lens rather than on its own terms. You see it when the review keeps pulling toward the previous task, defends an approach you have already moved past, or reads fresh code as if it were the thing you were just working on. A fresh session drops all of that and looks at the code cold. The clearest time to start one: if the session reviewing the code is the same one that helped write it and you start seeing some of the symptoms above.

If you are serious about security, these tools are worth using, but only if you know their limits. They are all the same model from different angles, so the independent check has to be yours.

What it taught me

CodeGuard is a good addition and I will keep using it, though I am still early in testing. But what I take from this is not really about the tools. Working across them showed me how much can go wrong in one codebase, and seeing that range makes you design security better. AI gives you the breadth fast. It does not give you the judgement. That stays yours. Become the orchestrator, in control of every decision. Do not let the output decide for you.

References

Discussion in the ATmosphere

Loading comments...