The most important line in Anthropic’s update isn’t about finding bugs. It’s about closing them.
Claude Security now runs a baseline scan of connected repos, then rescans changes based on their risk and complexity. Open findings get checked against new code. When a patch lands, the finding is marked fixed, “whether it was developed in Claude Code or through another process.” If the issue shows up again, it reopens. It’s in public beta for Claude Enterprise customers and runs on Anthropic’s full model family, including Claude Mythos, without Cyber Verification Program access (Help Net Security).
Add a generated threat model the team can edit, a per-project knowledge base, an API with webhooks, an MCP connector into Claude.ai and Claude Code, and role-based access. That isn’t a demo. That’s the outline of an AppSec product.
Why scanners should be nervous. Most of the AppSec budget pays for three things: finding issues, ranking them, and proving they got fixed. Point-in-time SAST is weak on the last two. Scans go stale. Severity scores ignore reachability. Tickets close without anyone checking the code.
Anthropic is going straight at that. Each finding carries a severity rated against the project’s threat model and an explanation of how an attacker reaches the vulnerable code, sometimes with an attack-path diagram. Vanta’s security director, Nathan Hunstad, said it “found a number of logic flaws that none of our other tools had caught,” and that once his team wrote its risk policy into the threat model, findings matched how they prioritize “instead of only a severity score” (Help Net Security).
Logic flaws are the tell. Pattern-matching scanners are good at injection sinks and bad at “this endpoint trusts a user-supplied tenant ID.” A model that reads the whole repo, plus the threat model you wrote, is aimed at the bugs that actually cause breaches.
And it ships inside a seat the buyer already pays for. The admin turns it on in the console. No new vendor review. No new procurement cycle. That’s how platforms beat best-of-breed: not on features, on friction.
The awkward part. More and more enterprise code is being written by Claude Code. Now Claude Security scans it, ranks it against a threat model Claude generated, and can mark it fixed when a patch lands, often a patch Claude wrote. The MCP connector lets an engineer discuss a finding, start the fix and mark it resolved in the same session.
That’s efficient. It’s also one vendor’s models on both sides of the review. If a model family has a blind spot, a class of bug it tends to write and tends to miss, the loop doesn’t catch it. It closes the ticket.
Audit committees have a name for this. Separation of duties. You don’t let the person who books the entry approve it. Software is about to need the same rule for AI-written code.
Where this leaves AppSec vendors. Three lanes stay open.
Independence. A second engine from a different vendor, ideally a different model family, becomes the control a regulator or an auditor asks for. “Your AI wrote it and your AI cleared it” won’t survive a serious breach review.
Runtime truth. Static findings are still guesses about reachability. Vendors that tie code findings to what’s actually deployed and exposed keep a role a repo scanner can’t fill on its own.
Supply chain and policy. Dependencies, build pipelines, artifact signing and the org-wide policy layer sit outside any one repo scan.
Vendors whose main pitch is “we find bugs in your source” face a hard renewal conversation next year.
What we’d do. If you’re on Claude Enterprise, turn it on for one service with a real threat model and run it next to your current scanner for a few sprints. Count the logic flaws only Claude finds and the classes only the incumbent finds. Then set one rule before you scale it: no AI-authored fix gets auto-closed by the same vendor’s scanner without a second check. Keep that rule even if the second check is a human.