Core maintainers can apply for Anthropic’s free OSS Scanner through a pull request using a standard project template. Accepted projects receive periodic security audits by the company’s strongest models, with findings delivered directly from the automated pipeline. Anthropic’s staff do not review or triage the reports first.
The company’s OSS Scanner announcement, published October 8, 2026, describes reports containing vulnerability explanations, self-contained reproducers, and candidate patches when available. Acceptance is case-by-case, so the service is not automatically available to every public repository.
Maintainers gain additional security analysis without paying for scans, while taking on the work of verifying the results. Anthropic explicitly warns that reports may be incorrect or invalid. A project’s capacity to investigate findings is therefore as important as its eligibility.
Enrollment Requires a Maintainer, a Configuration, and a Working Build
Anthropic’s OSS Scanner enrollment guide directs core maintainers to open a pull request in the anthropics/oss-scanner GitHub repository, adding a configuration at projects/<project>/project.yaml using the supplied template.
Eligibility follows criteria similar to OSS-Fuzz: established projects with a critical impact on infrastructure and user security. Anthropic considers exposure to remote attacks, including libraries processing untrusted input, and the number of users or other projects depending on the software. Maintainers can include a short explanation of their project’s importance when that isn’t obvious.
Before enrollment, Anthropic will manually confirm that an applicant is a core maintainer. That identity check is separate from the subsequent vulnerability reports, which receive no human review.
Preparing an application involves more than naming a repository:
- Identify the source and contact. The configuration requires the Git repository and a primary contact email. The source repository does not have to be hosted on GitHub.
- Supply the build environment. A Dockerfile must install dependencies and build the project so an offline agent can audit it. Maintainers can reference a Dockerfile in their project or place one beside the scanner configuration.
- Check the configuration and build. Anthropic recommends running
tools/validate.py, building the container locally, and confirming that tests pass inside it. - Explain the security boundaries. An optional threat-model file can define adversarial inputs, excluded code, severity criteria, preferred reproducer formats, and patch expectations.
The Dockerfile builds with network access, but the audit runs without internet access afterward. Dependencies needed during analysis must therefore be available in the prepared environment.
The threat-model file deserves particular attention. Without it, Anthropic acknowledges, the scanner will make its own guesses about ambiguous cases. Documenting which inputs are actually attacker-controlled and which behaviors are intentional can give the models better context for producing useful findings.
The Models Send Evidence and Proposed Fixes, Not Verified Verdicts
After acceptance and an initial scan, maintainers receive a bundle of bug reports by email. The pipeline includes agents that double-check bugs, propose patches, and investigate root causes, according to Anthropic. These are automated checks, not human validation.
Each report contains a self-contained reproducer and an explanation of the suspected vulnerability, the launch announcement says. Where possible, it includes a bisection identifying when the bug was introduced. Candidate patches are included when available; enrollment does not promise a ready-to-merge fix for every finding.
Subsequent scans look for newly introduced vulnerabilities and issues missed previously. There is no fixed cadence. Frequency may depend on the number of enrolled projects, a project’s usage, and other factors.
Anthropic deliberately distinguishes this service from its existing coordinated vulnerability disclosure process. The company says it discovered more than 29,000 candidate vulnerabilities over the preceding six months but manually reviewed and triaged approximately 6,000. Some maintainers asked to receive the remaining unverified material rather than wait.
OSS Scanner formalizes that faster route, reducing the delay before a project can investigate a finding while leaving the investigation to maintainers.
The Validation Sample Supports Usefulness, Not Blanket Trust
Anthropic provides unusually specific validation data for an early version of the scanner. Expert penetration testers reviewed 97 critical- and high-severity findings across 48 projects, it says, and 85 findings, or 88%, met the company’s coordinated-disclosure bar.
Of the remaining findings, 11 described real issues but duplicated known problems or other findings from the scan. Only one was invalid. Describing all 12 findings outside the disclosure bar as false positives would therefore be wrong.
The 88% figure is also not an independently established accuracy rate for everything OSS Scanner will send. The sample covered high- and critical-severity findings from an early pipeline; it does not establish performance across every severity level, language, repository, or future scan. Anthropic reported the results, and the supplied evidence does not include an independent reproduction of that evaluation.
The company also acknowledges feedback that severity ratings can be inflated or that the scanner can misunderstand a project’s threat model. A report may identify reproducible behavior while overstating what an attacker can accomplish under the project’s supported configurations. Establishing that a bug is real and assessing its security impact are separate tasks.
The data supports taking these reports seriously, without accepting their severity labels or merging their patches automatically.
Validate the Reproducer Before Reviewing the Patch
An incoming report is best treated as an investigation package. Its explanation, reproducer, and proposed fix provide starting points, but each needs an independent check within the project’s own security process.
A practical validation sequence is:
- Reproduce the behavior in isolation. Inspect the supplied reproducer before running it, then use a disposable test environment rather than production infrastructure. Confirm the affected commit, dependency versions, build options, and configuration.
- Establish the security boundary. Determine whether an attacker can reach the relevant code and control the necessary input. Check required privileges, authentication, and deployment assumptions against the project’s documented threat model.
- Check novelty and affected versions. Compare the finding with existing reports and fixes. Verify any supplied bisection rather than treating it as definitive evidence of when exposure began.
- Review the candidate patch as a separate contribution. Confirm that it addresses the root cause, preserves intended behavior, and does not introduce regressions or incompatible changes.
- Add regression coverage and reassess severity. Where feasible, create a test that fails before the fix and passes afterward, then run the broader test suite and assign severity using the project’s own criteria.
These are editorial recommendations, not claims that Anthropic has performed those steps for each delivered finding.
Maintainers can also use the optional threat-model file to specify whether they want minimal patches demonstrating a fix or more complete, merge-oriented changes. Either preference gives the agent useful guidance, but neither format establishes correctness.
Sources
- OSS Scanner announcementanthropic.com
- OSS Scanner enrollment guidered.anthropic.com
- Anthropic Cyber Missionanthropic.com
