Anthropic OSS Scanner explained
Free security scans for open-source maintainers who can act on the findings.
Anthropic OSS Scanner is a free, opt-in vulnerability scanning service for eligible open-source projects. Announced on October 8, 2026, it periodically examines enrolled repositories with Anthropic's strongest models and emails findings to maintainers. Its defining tradeoff: reports arrive without human review by Anthropic, so the project takes responsibility for validating and prioritizing them.
If you maintain an important library or application and have capacity to investigate reports, start with the official FAQ. Enrollment happens through a pull request to Anthropic's repository. Downloading a tool or buying an API key does not enroll a project.
Sources checked October 9, 2026. This guide analyzes Anthropic's announcement, FAQ and enrollment code. We did not enroll a project or run the scanner. Performance figures are vendor-reported. The linked primary sources are in English.
Who can use OSS Scanner?
Anthropic evaluates established projects with a critical impact on infrastructure and user security, using criteria similar to OSS-Fuzz. Exposure to remote attacks, including processing untrusted input, and the number of users or dependent projects inform the decision. Acceptance is case by case; there is no published automatic star-count threshold in the FAQ.
A core maintainer must apply, and Anthropic verifies that role. A useful application explains why the project matters and identifies someone who can handle the security inbox. The FAQ explicitly targets teams already able to keep up with verified high- and critical-severity reports. Free scanning still requires maintainer time for triage, fixes and releases.
OSS Scanner, Claude Security and Claude Code
These services address related work through different access paths. The OSS Scanner FAQ and Claude Code Security Reviewer repository describe the boundaries:
| Tool or process | Intended use | Access and output |
|---|---|---|
| OSS Scanner | Periodic audits of accepted open-source projects | Free opt-in service; model-generated reports by email |
| Claude Security | Commercial source-code scanning and remediation | Separate enterprise product and access path |
| Claude Code Security Reviewer | Review code changes in development | Separate GitHub Action and /security-review workflow |
| Anthropic's standard CVD process | Coordinated disclosure of validated findings | Human-reviewed reports under its disclosure policy |
The launch research says OSS Scanner uses Anthropic's strongest models, including Claude Mythos. That describes the service's scanning pipeline; it does not grant maintainers a model download or general Mythos API access. The public repository provides enrollment configuration and preparation tools, rather than a documented way to reproduce the full hosted scanner locally.
How to enroll an open-source project
1. Prepare the build and security contact
Read the repository instructions and contribution guide. Prepare a Dockerfile that installs dependencies and builds your project. The build has network access; the subsequent security audit does not. Fetch anything required by tests during setup, then confirm the tests work in the prepared environment without the internet.
The contact addresses in the enrollment file are public. Prefer a security alias you can publish. If you request encrypted reports with a pgp public key, reports go only to primary_contact; you cannot combine that with auto_ccs.
2. Add the enrollment configuration
In your fork of Anthropic's repository, create projects/my-project/project.yaml from the official template. This minimal example assumes the build and threat-model files live in your own project repository. Replace the example repository and contact, and create the referenced files:
repo: https://github.com/example/project#main
primary_contact: security@example.org
dockerfile: .oss-scanner/Dockerfile
threat_model: .oss-scanner/threat_model.md
Use the lowercase dockerfile key shown in the template and validator. Alternatively, place a file named Dockerfile beside the enrollment configuration and omit the dockerfile field. Choose one location. The Git repository being scanned does not have to be hosted on GitHub.
The optional threat_model file is especially useful. Describe untrusted inputs, security boundaries, out-of-scope behavior, severity rules and what constitutes a useful reproducer or patch. This helps the scanner interpret intended behavior; it is not a guarantee that every finding follows your threat model correctly.
3. Validate and check the offline environment
From the root of your enrollment-repository checkout, the documented preparation commands are:
python3 tools/validate.py
tools/check my-project
The first checks enrollment configurations. The second builds the project and opens a shell with networking disabled, where you can run its tests. The upstream instructions require Git, Docker and Python 3 with PyYAML. Build only trusted project definitions: the build stage has network access. These commands were checked against upstream documentation, not executed as a scanner trial for this article.
4. Submit the enrollment pull request
Submit one project per PR, complete the checklist and follow the repository's terms and contributor-agreement process. Anthropic confirms the applicant's maintainer role before acceptance. If its infrastructure cannot build the accepted project, it contacts the primary email address.
After the initial scan, later scans look for newly introduced issues and previously missed vulnerabilities. No fixed daily or weekly cadence is promised: the FAQ says frequency depends on pipeline load, project use and other factors.
What reports contain, and what the numbers mean
Anthropic describes a bundle of emailed reports containing a reproducer and vulnerability explanation, plus a candidate patch when available. Reports may include a bisection identifying when a bug was introduced. The pipeline uses agents to double-check findings, but that is not human validation. Severity can be overstated, findings can duplicate known issues, and the model can misunderstand a project's threat model.
The launch evaluation sampled 97 high- or critical-severity findings across 48 projects: 85 met Anthropic's CVD bar, 11 were real but duplicates, and one was invalid. This is a selected early sample, not an independent accuracy test across every severity level. It does not measure how many vulnerabilities the scanner misses.
The Cyber Mission announcement's “above 90%” true-positive rate is an expectation, not a service guarantee. Keep confirmed findings, duplicates, incorrect severity and invalid reports as separate categories in your own evaluation.
A practical workflow for maintainers
The following is our suggested handling process, rather than an Anthropic service promise:
- Route and record. Assign an owner in a restricted security inbox and track the report ID, affected revision and initial status.
- Reproduce and deduplicate. Check the reproducer in an isolated test environment and compare it with existing advisories or private reports. A duplicate can describe a real flaw without requiring a second fix.
- Assess impact. Verify whether the input is attacker-controlled, whether the vulnerable path is reachable in supported configurations, and which privileges are required. Apply your project's severity rubric.
- Review the patch and release. Inspect the proposed change, add a regression test and check compatibility. Coordinate the fix and advisory through your security process before publishing sensitive details.
For example, if a report labels a bug “critical” but reaching it requires administrator privileges, record that prerequisite and reassess impact. Do not dismiss the report solely because its original rating was wrong. Feed recurring misunderstandings back into the threat-model file and replies to Anthropic.
Disclosure, pausing and common questions
Does every report start a 90-day disclosure clock?
No. The FAQ says unvalidated findings do not carry an automatic 90-day deadline. If Anthropic later validates a finding manually, it may disclose it under its CVD policy, with the period starting when you are notified of that human validation. This is not a promise that findings can never become public.
Can a project pause or leave?
Yes. Submit a PR setting disabled: true to pause reports, or remove the project's enrollment directory to withdraw. Standard human-reviewed CVD reports can still arrive after opting out. The FAQ also says future disclosure-policy changes would come with notice and an opt-out option.
Is it free, and does it replace other checks?
Anthropic covers OSS Scanner's scanning cost for accepted projects. We recommend keeping dependency checks, tests and human security review alongside it: the published evidence does not establish complete vulnerability coverage. The practical decision is whether your team can turn additional findings into reviewed fixes without overwhelming its security process.
Where OmniaKey fits
For separate coding and remediation work, our Claude Code setup guide explains the development-tool connection, and the model catalog lists current gateway options. OSS Scanner enrollment remains with Anthropic; an OmniaKey account does not unlock this service or its internal models.