Anthropic launches free code scans and infrastructure defense program

Anthropic launched its Cyber Mission on October 8, pairing free scans for eligible open source projects with a defense program for critical infrastructure. The practical question is whether maintainers can investigate the findings.

Updated October 8, 2026. This article now includes enrollment requirements, disclosure rules and the evidence behind the scanner’s accuracy claims.

Two programs with different entry points

The Critical Infrastructure Defense Program starts with Accenture, Booz Allen, CrowdStrike, Deloitte, Dragos, Hitachi, Insane Cyber, Nozomi Networks, Palo Alto Networks, PwC and Rockwell Automation. Claude models, engineers and threat research will support providers serving industrial operators. The announcement describes work already underway and broader participation planned. It does not announce universal access or pricing for every infrastructure operator.

OSS Scanner is open for enrollment requests, with acceptance decided individually. Anthropic checks that applicants are core maintainers and favors established projects important to infrastructure and user security. Exposure to remote attacks and the number of dependents matter. The FAQ distinguishes this funded service from commercial Claude Security.

Enrollment requires a working build

The official repository accepts enrollment through a pull request adding a project directory. Maintainers supply a repository address, primary email and Dockerfile. The code can live outside GitHub. The Dockerfile must fetch dependencies and build the project before the audit loses internet access. Anthropic recommends checking that tests pass in the resulting container.

Contact addresses in the configuration are public, so a project security alias is a sensible choice. An optional OpenPGP public key enables encrypted reports to the primary contact, but cannot be combined with additional recipients. A threat model can explain trust boundaries, excluded components and severity expectations. Those instructions give the scanner project context that code alone may not communicate.

Preparation tools check the configuration and build environment. Read their security notes before running them. The local build has network access and can reach local services. Enrollment is therefore more involved than pasting a repository link into a dashboard.

What the accuracy evidence actually says

Anthropic’s research post reports an early evaluation of 97 critical and high severity findings across 48 projects. Its expert reviewers accepted 85, or 88 percent, under the company’s coordinated disclosure process. Eleven remaining findings were real but duplicated known issues or other scan findings. One was invalid.

Those figures describe different questions. A valid but duplicate report can still consume maintainer time. The 88 percent acceptance rate is not a measure of how many vulnerabilities the scanner finds in all code, and the sample does not establish performance across every severity. This was an evaluation commissioned by Anthropic, rather than a published independent comparison of competing tools.

Its expected true positive rate above 90 percent remains a forecast.

Anthropic also says maintainers have reported inflated severity or misunderstandings of a project’s threat model. Reports include a reproducer, explanation and a candidate fix when available. That is useful evidence to investigate, rather than proof that every proposed change belongs in a release.

Faster reports leave review with maintainers

Findings arrive in email bundles without human review. Subsequent scans can look for newly introduced issues and older problems previously missed. The FAQ gives no fixed scan interval, saying frequency depends partly on demand and project use. It describes reports stored in an isolated cloud project with access limited to security staff who need it, and scanning agents running without internet access. The FAQ does not specify a retention period or make a scanner specific model training commitment. Teams needing those assurances should ask before providing additional information.

The service agreement makes the remaining responsibility explicit. Maintainers must review reports and proposed patches before acting on or sharing them. Reports can miss vulnerabilities, misclassify severity or suggest changes that break functionality. Participation is free, but the service carries no accuracy or completeness warranty. Anthropic can change, suspend or end it.

The agreement also restricts report use to assessing and fixing the enrolled project. Reports may be shared with authorized maintainers. Maintainers must take reasonable steps to protect reports until the vulnerability is fixed or publicly disclosed. Teams should read these terms before enrollment, particularly if their normal process routes reports to outside contractors or publishes them automatically.

Disclosure timing depends on human validation

Unvalidated scanner findings do not currently start a 90 day disclosure countdown. If Anthropic later validates one manually, its disclosure policy can apply from notification of that validation. The FAQ allows pausing or ending automated reports and says future disclosure changes would come with notice and an option to withdraw.

The separate coordinated disclosure policy generally targets disclosure after 90 days or a patch release, whichever comes first, with exceptions. It describes possible extensions for maintainers making progress, shorter targets for actively exploited critical flaws, and a usual delay before publishing full technical patch details. It also says human reviewed submissions should be paced to what a project can absorb.

For a small volunteer team, that distinction matters. Accepting a stream of unreviewed reports and receiving a confirmed disclosure are different operational commitments. Teams should track which route each report follows rather than assume every email carries the same deadline.

Keep existing checks in the workflow

Google’s fuzzing documentation describes running code against generated inputs to expose bugs, supported by fuzzing engines and sanitizers. That is a different testing method from asking models to investigate a repository. The fact that Anthropic borrowed the enrollment model does not establish equivalent coverage or show that one service can replace the other.

GitHub’s code scanning workflow illustrates another distinction. Depending on configuration, findings appear directly on pull requests as checks and code annotations. Reviewers can inspect context and data flow, record dismissals and rerun checks after fixes. Its guidance for generated patches calls for assessing behavior, testing changes and confirming that both tests and the security check pass.

ByteForward’s assessment is to keep those review and testing steps around any scanner suggestion. A periodic email report is an input to remediation work. Someone still needs to reproduce the issue, check whether the deployed configuration is affected, evaluate the patch and follow the change through release. Counting reports alone says little about how much risk was removed.

The practical takeaway

Before applying, name the person who will triage findings and decide how much review time the team can sustain. Prepare a reproducible build and a clear threat model, read the enrollment terms, and choose a contact address suitable for publication. The useful outcome is a verified fix shipped safely to users. Free scanning can help start that process, but it does not finish it.