Most security scanners leave behind a point-in-time report. You run a scan, review the results, open tickets, and scan again next quarter. The code keeps moving in between. Claude Security's October 21, 2026 update is aimed at that gap: it follows repository changes, tracks whether findings are actually fixed, and lets teams add environment knowledge to the scan.
The important change is not a detection-rate number. It is the lifecycle of a finding. And the most dangerous word in that lifecycle is "fixed." A code change and a deployed fix are different events.
What changed
Claude Security entered public beta in April 2026. The new version remains a public beta for Claude Enterprise customers. It is not generally available, and an admin has to enable it in the Claude console. Anthropic says Claude Security is powered by its full model family, including Mythos, with no Cyber Verification Program access required.
| Area | Before | This update |
|---|---|---|
| Scanning | Manual or scheduled scans | Continuous scanning that follows repository changes |
| Findings | Scan output | Fix tracking, with automatic reopen when a finding returns |
| Context | Mostly code | Project knowledge base and editable threat model |
| Severity | Generic scoring | Severity judged against the project threat model, plus exploit paths |
| Integration | Export and webhooks | API, MCP connector, and webhooks |
| Permissions | Project access | RBAC for viewing, triage, and project creation |
Anthropic says thousands of organizations have used Claude Security since April and found more than a million vulnerabilities. That is a cumulative vendor figure. This review did not find an independent measurement of detection rate, false-positive rate, or remediation rate.
How continuous scanning works
According to Anthropic, a team creates a project and connects repositories through the Claude GitHub app, including GitHub Enterprise Server, or through an access token for GitLab and other providers. The team chooses a branch and scope. Claude runs a deep baseline scan, then scans changes regularly based on their risk and complexity. It does not re-run the same full scan on every commit.
A project can hold multiple repositories. That is meant to catch issues at service boundaries, such as a backend that trusts input a client was supposed to validate. A single-repository scan can miss that kind of path.
Findings are checked against code changes. If a team fixes an issue in Claude Code or through a separate process, Claude Security can mark it fixed when the fix lands. If the same issue is found again later, the finding reopens automatically. That fixed-to-reopen loop is the part a static report cannot provide.
The threat model becomes a filter
Each project gets a knowledge base. Teams can describe how the code is deployed, which security policies apply, and what a new security engineer would need to know. Claude Security also generates a threat model from the code, which the team can review and edit. Later scans use that threat model to decide what is worth flagging.
The design can reduce noise. A pattern that looks dangerous in isolation may be unreachable in production or covered by another control. But the inverse is also true: if the threat model is wrong, the scanner can quietly skip something important. The threat model is configuration and attack surface at the same time. It needs review, ownership, and a change history.
Anthropic says each finding includes a severity rating judged against the project threat model, an explanation of how an attacker could reach the vulnerable code, and sometimes an attack-path diagram. That is an attempt to prioritize reachability over a bare score. Whether the explanation and diagram match the current code still needs separate verification.
Four states, not one "fixed"
A "fixed" label in a security tool is not proof of deployment. At minimum, separate four states.
| State | Meaning | Evidence needed |
|---|---|---|
| Open | The issue exists in code | Finding, reproduction, or code location |
| Fixed in code | A fix is merged | Commit or PR, review, tests |
| Verified in runtime | The fixed artifact is deployed | Image digest, deployed version, runtime check |
| Accepted risk | The team knowingly accepts the risk | Approver, expiry date, compensating controls |
Claude Security observing a code change can establish the second state. The third belongs to CI/CD and runtime verification. The fourth is a security policy decision. Without that separation, teams end up asking why the scanner says "fixed" while production is still vulnerable.
The gap gets wider in microservices and mobile apps, where a fix can take days to reach production. Closing the finding at the code stage makes the dashboard green while the attack surface remains open.
Putting it in a CI gate
The policy below is an unexecuted illustration, not a Claude Security configuration file. The actual API and CI schema may differ.
# Illustrative policy, not a Claude Security configuration file.
security_gate:
block_on:
- severity: critical
reachable: true
state: open
- severity: high
reachable: true
state: open
require_for_fixed:
- fix_commit
- deployed_artifact
waiver:
owner: required
reason: required
expires_at: required
The gate should not block every finding. It should stop reachable critical and high issues before deployment, and require an owner and expiry date for exceptions. Passing a gate on "fixed in code" alone misses deployment lag. Blocking everything creates false-positive bottlenecks, and teams respond by writing waivers.
API and MCP expand automation, and risk
The new API can list and read projects and findings, resolve or reopen findings, and create and manage projects and repositories. A user can create a personal access token that can only see and change what that user can. Webhooks can notify external systems when a new finding arrives.
The MCP connector works in Claude.ai and Claude Code. An engineer can pull up a finding, ask about it, start the fix, and mark it resolved in the same session. That is convenient, and it increases the impact of a stolen token. A credential with permission to close findings can change state without fixing code. Token scope, expiry, audit logs, and the sensitivity of webhook payloads all need design review.
RBAC separates viewing, triage, and project creation. That matters operationally. A security tool should distinguish "can see the scan" from "can change the finding state."
Which numbers to measure
"A million vulnerabilities" is a numerator without your denominator. An organization needs its own rates.
| Metric | Question |
|---|---|
| Confirmed true-positive rate | What share of findings were real issues? |
| False-positive rate | What share did developers reject? |
| Triage time | How long from finding to an assigned owner? |
| Fix time | How long from confirmation to a fix commit? |
| Deploy time | How long from fix commit to production? |
| Reopen rate | How often does a fixed issue return? |
| Escaped defects | Which incidents passed the scanner? |
Look at reopen rate and deploy time together. A high reopen rate can mean the fix was a patch rather than a root-cause repair, or that the scan context is unstable. A long deploy time means the "fixed" dashboard and the real risk are diverging.
Questions before adoption
- Are the GitHub app or access-token permissions read-only where possible, and limited to the required repositories and branches?
- Who reviews and approves the threat model, and is the change history retained?
- How will finding states sync with Jira, the SIEM, or an existing vulnerability-management system?
- What scope, expiry, and revocation process applies to API personal access tokens?
- Who is allowed to close findings through the MCP connector?
- Do webhook payloads contain code snippets or sensitive data?
- What do the public-beta terms say about data retention and model training?
- Do you have an internal distinction between "fixed" and "deployed"?
Anthropic says eligible Claude Enterprise organizations receive $25,000 in free usage credits each month for two months, for usage through December 31, 2026. That lowers the cost of a trial. It is not a guarantee of detection accuracy or of total operating cost.
Limits
Claude Security examines code and repository context. It does not replace DAST, cloud security posture management, or runtime inspection of deployed artifacts, network boundaries, and cloud permissions. If the threat model assumes a control that does not exist, the scanner can produce a false negative. The product is in public beta, so features, pricing, and API schemas can change.
"Continuous" also does not mean a full scan of every commit. Scan depth depends on risk and complexity. Keep branch protection, code review, and other static analysis in place so an important change does not pass through a shallow scan.
Conclusion: a lifecycle system, not an oracle
Claude Security's update is less about adding one more detector and more about keeping findings alive as code changes. Its value is not the number of findings on a dashboard. It is the ability to ask whether a fix actually reached the environment where the risk exists.
Do not take the fixed count at face value. Separate the code fix, the deployed artifact, the runtime check, and the accepted exception. Connect those states to CI and audit logs. Then continuous scanning becomes a deployment gate for engineering, not just another report for the security team.
Further reading
- OSS Scanner: How AI Runs Open-Source Vulnerability Checks First
- CodeQL 2.27.2: What Security Analysis Catches and What It Misses
- Claude Code Team Code Review: What to Verify Before Merging a PR
References
Go deeper with a course
Connecting a security finding from code change to deployment verification is a workflow-control problem. If you want practice tying project rules, hooks, subagents, and MCP permissions to a real Claude Code workflow, this course is a useful next step.