Anthropic has launched OSS Scanner, a free, opt-in service that scans open-source repositories for security vulnerabilities with its strongest models and emails the findings straight to maintainers. The service is described on Anthropic's red team page and runs through a new anthropics/oss-scanner GitHub repository, where projects enroll by pull request. The notable design choices: the reports skip human review, there is no 90-day public disclosure clock, and Anthropic pays the compute bill.
If you maintain a widely used library, that is a real offer: a deep scan by a frontier model, with a reproducer and often a patch, for the price of writing a Dockerfile. If you maintain a small project already drowning in AI-generated reports, the fine print matters. This guide covers both sides.
Related: Anthropic's Frontier Red Team also used Claude to write machine-checked proofs for 123 libraries; see Claude formal verification of 123 libraries.
Update (October 22, 2026): first-week numbers and the report-flood complaint
Two follow-ups surfaced this week, both reported in posts we could only see secondhand. Per posts attributed to Anthropic's developer account and to Logan Graham, the first scans have reported 77 critical and 803 high model-rated findings to maintainers, the program accepted 114 of 650 applicants in its first week, and one finding was a use-after-free in curl tracked as CVE-2026-92392. Anthropic also said some of its automated reports were flagged as malware by security systems; Graham's thread describes how that happened and what the team learned. We have not seen the original posts, so treat the counts and the CVE number as unverified until you check Anthropic's page and the curl advisory.
Axios reported the other side of the same story: that a key internet security tool is getting buried in AI-generated bug reports, with legitimate alerts drowned out and maintainers facing extra noise. That is the risk we flag below under unreviewed reports. For maintainers, the practical advice stands: enroll only if you can triage a burst of findings, and consider asking for a reproducer and patch with every report.
OSS Scanner at a glance
| Question | Answer |
|---|---|
| What is it? | A free service that scans open-source repos for vulnerabilities with Anthropic's strongest models |
| Who runs it? | Anthropic, informed by its experience finding bugs during Project Glasswing |
| What does it cost? | Nothing; Anthropic says it covers the full cost |
| Are reports human-reviewed? | No, model-generated and unreviewed |
| Is there a 90-day disclosure deadline? | No, not on these unvalidated findings, and they will not be made public |
| How do I join? | Open a PR adding projects/NAME/project.yaml to the anthropics/oss-scanner repo |
| Who can join? | Core maintainers of established, high-impact projects (OSS-Fuzz-like criteria) |
| How are reports delivered? | By email to the primary contact, optionally PGP-encrypted |
Why Anthropic built it
Anthropic already runs a coordinated vulnerability disclosure (CVD) program: it scans open-source software, has humans validate the bugs, and then reports them to maintainers. According to the OSS Scanner page, the company had reviewed over 6,000 such reports by October 2026. The catch is speed. Manual review takes time, so valid findings can sit before they reach the people who can fix them.
OSS Scanner is the optional fast track. Projects that enroll get reports "as soon as they're scanned," directly from the model. Anthropic frames it as a trade: you accept the possibility of false positives, and in return you get findings earlier and on your own terms.
This follows a pattern we have tracked all year. Anthropic's Mythos-class models proved good at finding security bugs, which is why Claude Mythos Preview and Project Glasswing existed in the first place, and why the company later built a tiered access scheme in its Cyber Verification Program. The government's reaction to those capabilities is covered in our posts on Fable 5 and Mythos 5 and the US export-control action. OSS Scanner is the defender-side release of the same capability, pointed at the commons.
How enrollment works
According to the repository README and the OSS Scanner page, the process is a pull request:
- Add a directory. Create projects/NAME/ in the anthropics/oss-scanner repository.
- Write project.yaml. Two fields are required: repo (the git URL, optionally with a branch after a hash sign) and primary_contact (one email address). Optional fields include auto_ccs, homepage, threat_model, pgp, and disabled.
- Provide a Dockerfile. It must set up the environment, install every dependency, and build the project. Setup runs with network access; the security audit afterward runs with no internet at all, so anything the build or tests need must be fetched during setup. Anthropic recommends verifying that your tests pass inside the built image.
- Optionally add threat_model.md. This is where you tell the scanner what your project defends, which inputs are adversarial, what is out of scope, and how you rate severity.
- Validate locally. Run tools/validate.py before opening the PR.
- Get verified. Anthropic manually confirms you are a core maintainer before enrolling the project, and may contact you through other channels if unsure.
The Dockerfile can live in your own repo (the preferred option, since you can update it without another PR) or next to project.yaml in the Anthropic repo. A starting template sits in the repo's templates folder.
One detail to note: the email addresses in project.yaml are public, since the file is committed to a public repository. Use a security alias you are happy to see published. For encrypted reports, add an armored OpenPGP public key; in that case reports go to the primary contact only and cannot be combined with auto_ccs.
Why the threat model file matters
The README says the threat model is optional but "strongly recommended," and the advice behind it is practical. Scanners find many things; maintainers only care about some of them. Telling the model your severity rubric avoids a flood of low-value findings. Anthropic's examples: do you treat post-authentication SQL injection as high or critical? Are buffer overflows without a demonstrated exploit capped at high? When is stored XSS medium, high, or critical?
You can also tell the scanner what the project does, where untrusted input enters, which components matter, and how you want reports and patches formatted. If you have ever triaged a noisy automated report, this is the lever that makes the output usable.
The trade-offs: unreviewed reports and no disclosure clock
Two policies set OSS Scanner apart from the standard disclosure norm.
No human review. Reports are model-generated and, as the README puts it, not reviewed by a human. Anthropic warns that they may contain false positives. Each report is supposed to carry a reproducer, which is the maintainer's fastest way to check a claim, plus a proposed patch where one exists.
No 90-day deadline. The industry norm is a 90-day window after which the reporter may publish. Anthropic says it will not impose that on unvalidated findings, because it is "not comfortable forcing maintainers to carefully read each finding" it has not read itself. Findings will not be made public. If a report is later validated through the standard CVD program, a 90-day period can start from the date the maintainer is notified of human validation. Anthropic also says it may, in the future, impose disclosure periods on some high-severity reports as confidence grows, with notice and an opt-out.
That second policy is generous, and also a sign of how seriously the company takes the maintainer-burnout problem. The service page states plainly that it is built for projects "already able to keep up with verified high/critical vulnerability reports." If your queue is already overflowing, wait.
Should you enroll? A quick decision guide
| If you are... | Consider |
|---|---|
| A maintainer of a critical, widely used library with a security process | Enroll; the cost is a Dockerfile |
| A small hobby project with no security contact | Probably wait; you may not meet the eligibility bar |
| A project already swamped by automated reports | Wait or enroll and set disabled: true until ready |
| Running a security team inside a company with proprietary code | Look at Claude Security instead; OSS Scanner is for open source |
| A researcher wanting early, public findings | This service does not publish reports |
You can pause at any time by adding disabled: true in a PR, or remove your project by deleting its directory. After opting out you return to the standard CVD process.
How it differs from Claude Security and from fuzzing
Anthropic distinguishes the service from Claude Security, its commercial offering for enterprises to find and fix vulnerabilities in their own code with Claude Mythos. OSS Scanner is aimed at open-source maintainers, applies "additional token-hungry and experimental harnesses" to look for deeper bugs, and covers the cost.
It also is not a replacement for fuzzing. The eligibility test is modeled on OSS-Fuzz, which accepts established projects with critical impact on infrastructure and user security, weighted by exposure to remote attacks and by dependent users. Fuzzing and model-driven code review find different bugs: fuzzers hammer input handling and need a harness; a model can read code, reason about logic flaws and authorization mistakes, and write a patch. Used together they cover more ground. For another example of agentic bug-hunting that maintainers can run themselves, see the open-source security audit skill from Cloudflare.
Security of the pipeline itself
Maintainers will reasonably ask where their vulnerabilities go. Anthropic says reports are held in an isolated, locked-down cloud project available only to security staff who need access to run the program, using the same practices as its standard CVD process. Scanning agents run only after internet access is fully disabled inside hardened sandboxes. That last point is also the reason the Dockerfile must pre-fetch everything: the agent cannot download anything during the audit.
The sandbox detail connects to a broader concern in the field. Isolation is only as good as the layer below it, a lesson from the Vercel KVM zero-day that escaped agent sandboxes. If your Dockerfile runs untrusted build steps, review them as you would any CI job.
More from the official FAQ: eligibility, attribution, feedback and verification
The OSS Scanner page's FAQ adds several practical details.
Eligibility factors. Beyond the OSS-Fuzz-style test of exposure to remote attacks and the number of dependents, Anthropic says it considers a project's age and update frequency, its OpenSSF criticality score, whether it uses a commonly accepted open-source license, stars and forks, usage statistics, how security-critical it is and to which sectors, and how complete the required fields are. It asks maintainers to add a short sentence on why the project is critical to security where that is not obvious. Brand-new projects typically do not qualify, and forks are not scanned unless they are distinctly unique and qualify independently.
Verification of who gets reports. A human reviews every sign-up and tries to confirm that the request comes from a GitHub account or email belonging to a core maintainer, and that the contact is a real security contact, for example one listed in SECURITY.md. Anthropic says it verifies again before sending results. Dockerfiles are checked at sign-up for scope, and any change to a Dockerfile between runs is reviewed before the next run. A harness also checks that each report concerns the target project and not one of its dependencies.
Attribution. It is optional, but Anthropic asks that a patch commit message credit the scanner with the report ID, in the style "Discovered by Anthropic's OSS Scanner, as vulnerability ANT-2026-ABCD1234," so it can track which findings were right and got fixed.
Feedback. Enrolled maintainers can reply directly to the emailed reports. Non-enrolled projects can write to oss-scanner-questions@anthropic.com, a mailbox monitored by a human.
Disclosure policy details. If Anthropic later validates a report through its standard process, the 90-day disclosure period can start from the date the maintainer is told a human validated it. Anthropic says it may eventually apply a disclosure period to some high-severity reports as confidence grows, with notice and a chance to opt out.
Other support. Maintainers can also apply to Claude for OSS, which offers free Claude Max 20x subscriptions to help fix vulnerabilities, and qualifying security professionals can use the Cyber Verification Program, which reduces blocking classifiers for advanced cyber work. The project is a collaboration between Anthropic's Frontier Red Team and Safeguards Research team.
Why this matters beyond Anthropic
Three trends meet in this launch:
- AI-found bugs are now routine. Model-driven discovery has moved from demo to service. The question for maintainers is no longer whether AI will find bugs in their code, but who gets the findings first.
- Attackers have the same tools. Our coverage of AI-linked bank breaches in South Korea shows the offensive side; a free defensive scan for critical libraries narrows the gap.
- Disclosure norms are bending. A 90-day clock was designed for human-discovered bugs and human reviewers. When a model produces dozens of candidate findings, forcing maintainers onto a deadline is a recipe for burnout. Anthropic's choice to drop it for unvalidated reports may become a template.
What we could not verify
Anthropic's launch post reports that it checked 97 critical and high-severity findings across 48 projects: 85 (88%) met the bar for its disclosure process, 11 were real but duplicated known issues or other scan findings, and one was a false positive. Anthropic says it cannot guarantee the scanner will be perfect. That is the company's own sample, not an independent audit. We do not know how many projects have enrolled or which models are used beyond "our strongest models." Maintainer reports from the field will be the real test of signal versus noise, so check the repository for updates to the terms.
Details are accurate as of October 8, 2026; Anthropic says it may adjust acceptance criteria and policies as the service evolves.
Related reading
-
PHP2Shell: AI-found PHP RCE, what happened and what to do now (October 2026)
-
Claude attack surface reduction: 493 issues in 25 projects, the methodology Anthropic says it is folding into OSS-Scanner
-
Anthropic Cyber Mission and the Critical Infrastructure Defense Program