Anthropic adds continuous scanning and fix tracking to Claude Security beta

1. Executive summary

Anthropic has updated Claude Security, its codebase vulnerability scanning and patch-suggestion service, with recurring scans of code changes, automatic fix tracking that closes and reopens findings as code changes, per-project threat models, an API, an MCP connector and role-based access controls. The update is in public beta for Claude Enterprise customers only, so the direct exposure is limited to firms that already hold that licence and choose to enable the feature in the admin console. No CVE, exploitation activity or threat actor is associated with this item, and no vulnerability is described in it. The risk to EMEA financial services is not a flaw in the product but the operational one: connecting source repositories to a third-party AI service through the Claude GitHub app or a Git provider access token, where the token inherits the user's permissions. Firms that enable it take on a new ICT third-party dependency and a new path by which source code leaves their estate.

2. Regulatory framing

3. Technical analysis & attack chain

This is a product update, not an incident. There is no exploited component, no malware and no attacker chain to reconstruct. What follows is how the feature works and where the security-relevant decisions sit, from the vendor description as reported.

A team creates a project and connects one or more repositories through the Claude GitHub app or an access token from GitLab or another Git provider. For each repository the team selects the branch and scope to be scanned. Claude runs a baseline scan, then recurring scans of changes, with the frequency and depth of the recurring scans set by the risk and complexity of each change. A project can hold multiple repositories, which lets the service flag issues that span services rather than sitting inside one repository.

Findings are tracked against code changes. When a patch lands, whether it was written in Claude Code or through another process, the open finding is marked fixed. If a later scan detects the same issue again, the finding is reopened. Each project carries a knowledge base where teams record how the code is deployed, which security policies apply and what a new security engineer needs to know. Claude also generates a threat model from the code, which teams review and edit; later scans use that threat model to decide which issues to flag and to account for risks already covered by existing controls. Each finding carries a severity rating assessed against the project's threat model, an explanation of how an attacker could reach the vulnerable code, and in some cases a diagram of the attack path.

The integration surface is the part that matters for a defender. A new API lets connected systems manage projects and repositories, view findings and resolve or reopen issues. Access tokens inherit the user's permissions, and webhooks notify connected systems of new findings. An MCP connector lets engineers read findings in Claude.ai and Claude Code, discuss them with Claude, start fixes and mark findings resolved in the same session. Role-based access controls let administrators assign permission to view projects, triage findings and create projects, and teams can be given access without project creation rights. The feature is enabled by an administrator in the admin console, who also chooses who has access.

Two properties carry the operational risk. First, the access token inherits the permissions of the user who created it, so the reach of the integration is the reach of that account, not a scoped read-only grant. Second, findings, threat models and the project knowledge base describe where the code is weak and how it is deployed, which is material an attacker would value. Neither property is a defect; both are configuration decisions the customer makes.

The only effectiveness claim in the source is a quoted customer statement from Nathan Hunstad, Director of Security at Vanta, that the service found logic flaws other tools had missed and that findings aligned with their priorities once their risk policy was written into the threat model. That is a single vendor-supplied testimonial, not independent testing, and should be read as such.

4. Mitigation & containment

P1 within 24h, for firms that already run Claude Enterprise and intend to enable the beta:

• Decide who may create projects before enabling the feature. In the admin console, grant project creation only to named repository owners, and give the wider security team view and triage rights without creation rights.
• Issue the Git provider access token from a dedicated service account scoped to the repositories in scope, not from an engineer's personal account, because the token inherits that user's permissions. Record which account issued each token and what it can reach.
• Restrict repository scope and branch selection per project to what the scan needs. Do not connect organisation-wide access where a single repository will do.

P2 within 72h:

• Treat the project knowledge base and generated threat models as sensitive. They describe deployment, controls and weak points. Apply the same access review to them as to the findings themselves.
• Register Anthropic as an ICT third-party provider for the development toolchain and confirm the Claude Enterprise agreement covers source code handling, data location, access logging and exit. This is the DORA Art. 28 and Art. 30 work, and it precedes connection.
• Authenticate and monitor the webhook endpoint that receives new findings. A webhook that notifies an unauthenticated or internet-facing receiver leaks finding data.

P3 within 7 days:

• Point the API at your existing ticketing or vulnerability management workflow so findings are triaged in one place rather than in the Claude interface alone.
• Review MCP connector use. Engineers can start fixes and mark findings resolved inside a Claude session; confirm that resolution state is not treated as verification without a human check.
• Set a review cadence for the threat model. Scans prioritise against it, so a stale threat model produces stale priorities.

No vendor patch applies to this item. There is no CVE and no fixed version to deploy.

5. Indicators of compromise

No indicators of compromise available in the source material.

The source describes no malicious artefacts. The observable behaviours it does describe are product functions, not threat activity, and are not reproduced here as indicators.

6. Detection

Insufficient indicators to author detection rules.

7. Sources

• Help Net Security, "Claude Security can now spot vulnerabilities that reappear in code", 2026-10-22, https://www.helpnetsecurity.com/2026/10/22/claude-security-continuous-scanning-update/

8. Adverse Trace position

Adverse Trace assesses this as an informational product update with no vulnerability, exploitation or actor attribution attached; no CVE has been assigned and nothing in the source indicates malicious activity. The client impact is confined to firms holding Claude Enterprise that enable the public beta, and it is a governance impact rather than a technical compromise: a new third-party dependency in the development path, a Git access token that inherits user permissions, and a store of findings and threat models that maps where code is weak. The effectiveness claim rests on a single vendor-supplied customer quote and is not independently corroborated. We will track Anthropic's beta-to-general-availability changes for any shift in token scoping, data handling or default permissions, and will reissue if a security-relevant change appears. Clients intending to enable the beta should complete the P1 token and project-creation controls before connecting any repository.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.