Anthropic OSS Scanner is a new, free, opt-in security scanning service for eligible open-source projects. Announced on 8 October 2026 as part of the Anthropic Cyber Mission, it gives maintainers a faster route to model-generated vulnerability reports. The central trade-off is important: those reports arrive without human review, so the receiving project needs the capacity to validate them.
The wider Cyber Mission announcement also introduces a Critical Infrastructure Defense Program. For developers and people running software businesses, the immediate question is which route fits their role and whether they can act on the findings.
Reporting cutoff: 9 October 2026, 17:58 Pakistan time. AIX Radar has not used the scanner or independently validated its reported results.
What changed beyond Claude cyber access?
The Cyber Mission combines software security work with support for critical infrastructure defenders. Its initial infrastructure program brings Claude models, engineers and threat research to a cohort of specialist providers. Anthropic says work with partners is underway, while companies seeking involvement can register interest. An interest form is not a guaranteed admission or a self-service deployment.
This differs from the earlier model-access announcement explained in our Claude Cyber Verification Program guide. Access to a model, enrollment in a scanning service and participation in an infrastructure partnership are separate decisions. They should not be presented as one subscription benefit.
The practical distinction is the unit of work. A model-access program lets a qualifying team perform its own security work; a scanning service sends findings for a particular enrolled project; the infrastructure program supports providers working in specialized environments. Choosing the right route avoids applying for something that cannot serve your actual task.
Who can join the free OSS Scanner?
According to the official scanner FAQ, Anthropic considers established projects important to infrastructure and user security. It considers exposure to remote attacks and how many users or projects depend on the code. Applications are reviewed individually, and Anthropic validates that the applicant is a core maintainer.
There is no blanket entitlement for every public repository. The FAQ describes the service as suitable for projects already able to keep up with serious verified reports and willing to take on additional findings. It is not a button for scanning somebody else’s repository on demand.
| Reader | Route to investigate | Practical limit |
|---|---|---|
| Core maintainer of an important open-source project | OSS Scanner enrollment | Eligibility review and report-handling capacity |
| Company protecting operational technology | Critical Infrastructure Defense Program | Specialist partnership and interest process |
| Security professional seeking broader model access | Cyber Verification Program | Separate qualification requirements |
| Website owner using third-party software | Maintainer advisories and updates | Using software does not make you its core maintainer |
For a website operator, the value may therefore be indirect: an upstream maintainer could identify and repair a weakness in code your site uses. That does not replace reviewing your own updates, custom code or service configuration.
What findings look like, and what the evidence proves
Anthropic’s technical launch post says reports can include a self-contained reproducer, an explanation and a proposed patch where available. It reports an early expert review of 97 high- or critical-severity findings across 48 projects: 85 met its coordinated-disclosure bar; 11 were real but duplicated known issues or other findings; one was invalid.
Those figures describe Anthropic’s selected evaluation sample. They are not an independent accuracy guarantee across every future scan. The same post notes feedback about inflated severity and misunderstood threat models. A suggested patch is evidence to investigate, not a reason to skip engineering review.
Our reading is that two questions must stay separate: is the reported bug real, and does it matter under this project’s actual deployment conditions? A reproducible issue can still have a different severity from the one assigned in a report. A maintainer should also distinguish a new finding from an already tracked issue.
This is why a simple score would be misleading. A project needs actionable findings, reasonable prioritization and a manageable review load. None of those outcomes is established for your repository by a launch announcement or a selected vendor sample.
Enrollment: prepare the project before submitting it
The official enrollment repository uses a pull request adding a project configuration and build setup. The project supplies its repository and contact information, a Dockerfile for the build environment, and optionally a threat-model document. The setup phase can use the network; the security audit runs without internet access.
The repository explicitly warns that configuration email addresses are public. Use an appropriate security contact rather than accidentally exposing a personal inbox. It also provides configuration and build checks to run before submission. Follow the current template instead of copying an abbreviated example from an article.
Our suggested preparation sequence is to nominate a maintainer, confirm that the project builds with its required dependencies, write the intended security boundaries and choose how findings will be tracked. Allocate time for triage before enrollment. Receiving a large bundle faster does not help if nobody can examine it.
For example, a parser library might document which untrusted inputs it accepts, the supported build options and which components are outside the review scope. That makes a report easier to assess against the intended design. This is an illustrative preparation example, not a scanner result.
A sensible review process for incoming reports
This proposed workflow can help a maintainer turn incoming findings into engineering decisions:
- Register the report. Give it an owner and compare it with existing issues.
- Reproduce in an isolated test environment. Preserve the affected revision and distinguish a working reproducer from an unsupported allegation.
- Assess exposure. Compare assumptions with supported configurations and the project’s documented threat model.
- Review the candidate fix. Examine behavior changes and run relevant regression checks.
- Coordinate the release. Decide the advisory, supported-version updates and communication through the project’s normal security process.
The FAQ says raw, unvalidated findings do not carry its usual 90-day coordinated-disclosure deadline. A report later validated through Anthropic’s existing process can enter that separate process. This is a distinction between reporting routes, not permission to ignore a potentially serious weakness.
For critical infrastructure, repairs also need operational expertise. Finding a software issue and applying a change safely to running equipment are different stages. Do not infer that the new program authorizes unattended modification of industrial systems.
Frequently asked questions
Is OSS Scanner free?
Anthropic covers the scanning cost for enrolled projects. A project still needs to budget maintainer time to review and address the output.
Are its reports verified by a person?
No. The service deliberately provides model-generated reports without human triage. That is the main distinction from the existing human-reviewed disclosure route.
Does it guarantee secure software?
No. Its outputs may be wrong, duplicate an existing finding or misjudge severity. Treat it as an additional defensive input, with the project’s own review process determining the response.
Should a small maintainer enroll immediately?
Only if the project appears eligible and can handle the reports. Prepare the build, security context and ownership first. The useful outcome is a verified fix delivered safely, rather than simply a larger inbox.
