Does continuous AI code scanning show when a vulnerability is really fixed?
Anthropic's Enterprise public beta now rescans changing repositories and can reopen findings, but its claim of more than one million vulnerabilities lacks a denominator, false-positive rate and independent benchmark.
The short version
- What happened
- Claude Security can establish a repository baseline, scan later changes and mark a finding fixed when the relevant code lands; rediscovery reopens it.
- Who it affects
- Security engineers may spend less time reconciling scanner tickets with changing code, but they still need to validate findings, review the threat model and confirm that a code fix reached the deployed system.
- What remains unproven
- The source is a vendor announcement for a public beta and contains no independent performance evaluation.
Keep in mind
The source is a vendor announcement for a public beta and contains no independent performance evaluation.
The reported million-plus findings have no denominator, verification method, severity distribution, duplicate rate or false-positive rate.
Customer testimonials are not accompanied by protocols, comparison tables or incident outcomes.
Marking code changed does not establish that a production exposure was removed or that the change introduced no new weakness.
Source analysis · 1 linked source. Primary analysed source date: 21 October 2026.
Read the full report · 4 min The evidence, methods, implications and limitations
The beta follows code changes instead of freezing one scan
Claude Security now offers continuous repository monitoring to Enterprise customers in public beta. A team connects GitHub—including GitHub Enterprise Server—or another Git provider, selects branches and scope, and receives a baseline scan. Anthropic says later changes are scanned according to risk and complexity. When changed code addresses an open finding, the system marks it fixed; if the issue reappears, it reopens the finding.
That workflow targets a familiar gap between detection and remediation. A one-time scanner can produce a queue that drifts away from the deployed code, while fixes may happen in a different tool. The beta adds an API, webhooks and an MCP connector so teams can read, resolve or reopen findings in existing workflows. Role-based controls separate viewing, triage and project creation.[1]
Team context can change what the scanner treats as important
Each project can include multiple repositories and a knowledge base describing deployment controls and security policy. Claude generates an editable threat model, then uses that model and the added context when judging severity and explaining an attack path. In principle, this can surface weaknesses that cross service boundaries and reduce alerts for risks already controlled elsewhere.
It can also create a new governance dependency: inaccurate context or an incomplete threat model could lower a finding's priority. Security teams therefore need to review the generated model, control who may change it and preserve evidence of why a finding was closed. An automatically marked fix is a code-state signal, not proof that the deployed service is no longer exploitable.[1]
The distinction that matters
What the continuous loop adds
The product announcement describes a lifecycle around findings, but not a validated security outcome.
Baseline
Scan connected repositories
Create findings and attack-path explanations
Change
Inspect later code by risk and complexity
Mark a finding fixed or reopen it
Outcome
Prevent exploitable incidents in production
Not measured in the announcement
The largest number in the announcement is not an accuracy measure
Anthropic says thousands of organisations have used the product since April and found more than one million vulnerabilities. The announcement does not state how many repositories or scans produced that total, how findings were verified, how many were duplicates, or the false-positive and false-negative rates. It includes favourable customer statements, including a claim that the tool found issues missed by a simultaneous penetration test, but supplies no protocol or results table.
For an engineering team, the useful trial question is not how many alerts appear. It is whether verified important flaws are found earlier without overwhelming reviewers, whether fix status agrees with deployment reality and whether sensitive source code is handled acceptably. A reproducible benchmark against established static analysis and expert review, followed by incident and remediation outcomes, would materially change the assessment.[1]