learnaiwithrafa
ClaudeWorkflows

Three Free Security Reviewers for AI-Written Code

If Claude writes a meaningful share of your code, you need a review layer that runs without you remembering to ask. Three exist, they are free, and one of them runs before the edit lands.

5 min read3 sources
  • #claude-code
  • #security
  • #code-review

The uncomfortable arithmetic of AI-assisted engineering: your code output went up several times over, and your review capacity did not move at all. That gap is where security bugs live now. Not because Claude writes unusually dangerous code, but because volume was always the thing that made review work, and volume just broke.

The useful response is not to review harder. It is to put review where you cannot forget it. Three layers, all free, in the order they should fire.

Layer 1 — before the edit lands

Anthropic ships a Security Guidance plugin that is not a command you run. It is a PreToolUse hook: it intercepts Write, Edit and MultiEdit, scans the code for dangerous patterns, and warns you before the change is applied. It sits at 235,822 installs and is Anthropic Verified — worth noting, for reasons I get to below.

What it looks for is specific and mostly familiar:

  • Command injection in GitHub Actions workflows
  • Unsafe child_process.exec() calls — it suggests execFileNoThrow() instead
  • eval() and new Function()
  • XSS vectors: dangerouslySetInnerHTML, innerHTML
  • Python pickle deserialization
  • os.system() command injection

Warnings are session-scoped, so you see each one once rather than being nagged. That design choice is why it survives past week one — the security tooling people actually keep is the tooling that does not cry wolf.

This is the cheapest layer to adopt and the one I would install first: it costs zero workflow change. You do not have to remember anything.

Layer 2 — before you commit

/security-review in your project directory scans the codebase, explains what it found, and then — the part that matters — Claude can implement the fixes, because it is already in the terminal with your files. Coverage is the standard heavy hitters: SQL injection, XSS, authentication and authorization flaws, insecure data handling, dependency vulnerabilities.

Auth and authorization flaws are the interesting entry on that list. They are the class a linter structurally cannot find, because the bug is not a pattern — it is a missing check that only makes sense against the intent of your app. That is exactly where a model reading your whole codebase beats a rules engine.

Layer 3 — before it merges

The GitHub Action triggers on new pull requests and posts inline comments with recommended fixes. This is the layer that turns security review into a property of your repo rather than a habit of your best engineer.

Anthropic says these features have caught real vulnerabilities in their own code before shipping, and they name two: a DNS rebinding vulnerability in a local HTTP server feature, found and fixed before the PR merged, and an SSRF flaw in a credential proxy system that was flagged automatically and fixed. Both are the kind of bug that gets through human review not because reviewers are careless but because they are reading a diff, not a threat model.

Now review the reviewer

Here is the part most posts about plugins skip entirely. Every skill or plugin you install is instructions that shape what an agent does with your repo, your credentials, and your shell. The install is the trust decision.

Note what I said about the Security Guidance plugin above — Anthropic Verified, 235,822 installs. Those two facts are why I ran it without reading every line. Neither is true of the average marketplace plugin, and "it was on the marketplace" is not vetting.

Three checks before you install anything:

  1. Read the SKILL.md. All of it. It is a text file. If it is asking to run a remote script or read files it has no business reading, you will see that in under a minute.
  2. Check who ships it and how many people use it. Verified publisher and real install counts are weak signals, but they are signals. Zero installs and no named author is not.
  3. Look for what it will not tell you it does. Network calls, credential reads, anything writing outside the repo.

Then make the decision structural instead of per-install. Two managed settings exist for exactly this:

{
  "strictKnownMarketplaces": true,
  "blockedMarketplaces": [
    { "source": "github", "repo": "untrusted/plugins" }
  ]
}

strictKnownMarketplaces restricts plugins to known Anthropic marketplaces; blockedMarketplaces blocklists specific sources. Both are managed-settings keys — which means if you lead a team, this is a decision you get to make once for everyone rather than trusting each engineer's judgment on a Friday afternoon.

Do this today

Install the Security Guidance plugin — it changes nothing about how you work and starts catching eval() and innerHTML immediately. Then open the last plugin or skill you installed and actually read its SKILL.md. If you find yourself unable to say what it is allowed to do, you have found your real problem, and it is not the one the plugin was scanning for.

Sources