# Anthropic OSS Scanner explained: how the free AI vulnerability scans work, what the accuracy numbers really say, and what changes for IT teams

> Source: <https://theainewsreport.com/2026-10-09-anthropic-oss-scanner-free-ai-vulnerability-scans-explained.html>
> Published: 2026-10-09 14:49:54+00:00

# Anthropic OSS Scanner explained: how the free AI vulnerability scans work, what the accuracy numbers really say, and what changes for IT teams

On October 8, Anthropic opened a free, opt-in service that runs its strongest models over critical open-source projects and emails maintainers unreviewed bug reports. This page walks through how enrollment and scanning work, separates the five different numbers in the announcement, compares the approach with OSS-Fuzz and with the AI-written bug reports curl complained about, and says what IT teams should do about the patches that follow.

**This explains reporting by**

[Anthropic, "Launching an opt-in vulnerability finding service for open source" (October 8, 2026)](https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source).
Read the original first:

[https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source](https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source)

## In one minute

- OSS Scanner is free and opt-in. Core maintainers of critical open-source projects enroll with a pull request to anthropics/oss-scanner, and Anthropic accepts projects case by case.
- Reports come by email with a reproducer, an explanation, a bisection where possible, and a candidate patch. No human at Anthropic reviews them before they go out.
- Of 97 critical and high findings checked by expert penetration testers, 85 (88%) were new and worth disclosing, 11 were real duplicates and 1 was invalid. That sample excludes low and medium findings.
- Anthropic's models flagged more than 29,000 candidate flaws in six months, but people reviewed only about 6,000. Finding bugs is no longer the slow step. Fixing them is.
- If you only run open-source software, expect more security releases in common components and make sure you hear about them and can patch fast.

## What Anthropic launched on October 8

Anthropic announced the Anthropic Cyber Mission on October 8, 2026, with two parts to start. The first is OSS Scanner, a free, opt-in service that runs Anthropic's strongest models over important open-source projects and emails the maintainers what it finds. The research post names Claude Mythos among the models used.

The second is the Critical Infrastructure Defense Program. It gives 11 founding partners, including CrowdStrike, Dragos, Palo Alto Networks, Rockwell Automation and Booz Allen, access to frontier Claude models, threat research and on-site Anthropic engineers, aimed at power grids, water systems and transportation. SiliconANGLE reports the commercial terms were not disclosed.

This page is about OSS Scanner, because it is the part that will reach almost every software stack, including yours.

## How enrollment and scanning work

Only core maintainers can enroll a project, and Anthropic decides case by case. The bar is borrowed from Google's OSS-Fuzz: the project should have critical impact on infrastructure or user security, judged by things like exposure to remote attacks and how many people or projects depend on it.

Enrollment is a pull request to the anthropics/oss-scanner repository on GitHub. The pull request adds one folder, projects/<name>/, with a config file and a Dockerfile that builds the project. The template in the repo looks like this (an optional pgp field takes a public key):

```
repo: https://github.com/example/project
primary_contact: security@example.org
auto_ccs:
  - maintainer@example.org
homepage: https://example.org
disabled: false
dockerfile: .oss-scanner/Dockerfile
threat_model: .oss-scanner/threat_model.md
```

Two details matter. First, the email addresses in that file are public, so the repo tells you to use a security alias. Second, the Dockerfile setup step has internet access, but the audit itself runs with no internet, so every dependency and test input must be fetched during setup. The repo ships tools/check, which builds the project the same way and opens a networkless shell, so you can see what the scanner will see.

The optional threat_model.md tells the scanner what your project counts as a real security bug. Maintainers told Anthropic the most common problems were inflated severity and a misread threat model, so this file is how you cut that noise.

Reports arrive by email, bundled after the first scan. Each has a self-contained reproducer, an explanation, a bisection showing when the bug came in where possible, and a candidate patch when one exists. Projects are rescanned on no fixed schedule. You pause with disabled: true, or leave by deleting your folder.

## The numbers, read carefully

The announcement carries several numbers that are easy to blur together. They measure different things:

- More than 29,000 candidate vulnerabilities, found by Anthropic's models in major open-source projects over six months. These are model outputs, not confirmed bugs.
- About 6,000 of those were reviewed and triaged by people. That is roughly one in five.
- Nearly 5,000 unvalidated reports with proposed patches already went straight to maintainers who asked for everything.
- 97 critical and high-severity findings across 48 projects were checked by expert penetration testers. 85 of them (88%) met the bar for coordinated disclosure. 11 were real but duplicated a known issue or another finding. 1 was invalid.
- One early tester, wolfSSL, got 74 reports. All but 2 were valid, and 5 became CVEs.

So the honest summary is two numbers, not one. About 99% of the sampled serious findings were real bugs (96 of 97). About 88% were new and worth a disclosure. Anthropic's own forward-looking figure, on the Cyber Mission page, is a true-positive rate above 90%.

The sample is the catch. Those 97 were critical and high findings only, checked for Anthropic. Low and medium findings, usually the noisiest, are not in it. The wolfSSL numbers show the other gap, between valid and important: 72 valid reports, 5 CVEs.

## Why this is not the AI slop curl complained about

Maintainers have reason to be wary. In January 2024, curl lead developer Daniel Stenberg wrote about AI-written bug reports that looked polished, were wrong, and still took human time to close. At that point curl's bug bounty had received 415 vulnerability reports and confirmed 64 security problems, and about two thirds of reports were neither a security issue nor a normal bug.

Three things make OSS Scanner different on paper. It is opt-in, so reports only go to projects that asked. Every report carries a reproducer, so a maintainer can run it and know in minutes instead of arguing with a reporter. And it comes from one accountable sender with a feedback channel, not from strangers chasing a bounty.

The risk does not go away. A maintainer still has to read, run and judge every report, and Anthropic's own numbers say finding now outruns human review by about five to one. A project with one volunteer maintainer can be buried by valid bugs as easily as by fake ones. That is why the fast track is optional, and why human-verified disclosure stays in place for projects that cannot keep up.

## How it compares with OSS-Fuzz

OSS-Fuzz is the model Anthropic names. Fuzzers throw huge numbers of mutated inputs at code and watch for crashes. As of August 2023, Google said OSS-Fuzz had helped find and fix over 10,000 vulnerabilities and 36,000 bugs across 1,000 projects.

Fuzzing is very good at memory errors that make a program crash, and it needs someone to write a harness for each entry point. A language model reads the code and reasons about it, so it can also find logic bugs, broken permission checks and injection paths that never crash anything. That is also why it can be wrong in ways a fuzzer cannot: a crash is proof, while a model's claim needs the reproducer to become proof.

The jump in model skill is recent. Anthropic cites the CyberGym benchmark, where models went from finding under 20% of vulnerabilities at the start of last year to over 85% this year.

## The disclosure question

Under the FAQ, unvalidated findings carry no 90-day disclosure deadline. If a report is later validated through Anthropic's coordinated disclosure process, disclosure may follow 90 days after notification. Anthropic says it may add deadlines for some high-severity reports later, with notice and an opt-out.

In plain terms, a maintainer who gets an unvalidated report is not on a public clock. The quieter risk is downstream. When a fix lands as a public commit, an attacker can read the change to find the bug before most users have updated. That is true of every security fix, but a program that produces many more fixes makes the gap between patch and update matter more for everyone who runs the software.

## What it means for an MSP or IT team

You will probably never enroll anything. You will feel this anyway, because the libraries, web servers, VPN clients and agents your clients run are built from exactly the kind of projects this program targets.

Expect more security releases, sooner, in common open-source components. The teams that come through well are the ones that already know what they run, hear about a fix the day it ships, and can roll it out in days instead of weeks.

## Who is affected

| Case | Status | 
|---|---|
| Core maintainers of widely used open-source projects | Can apply now with a pull request. Reports arrive by email, unreviewed, with a reproducer and often a patch. | 
| Small projects with no security staff | The raw fast track is optional. Anthropic says they can still get human-verified reports through its existing disclosure process. | 
| Companies and MSPs that run open-source software | Not enrolled directly. Expect more security releases in common dependencies and plan patch time for them. | 
| Security vendors that protect critical infrastructure | The Critical Infrastructure Defense Program starts with 11 founding partners. Others can register interest. | 

## What to do

- List the open-source components your business and your clients depend on most, starting with anything that faces the internet.
- For each one, find where it posts security advisories and subscribe, or turn on dependency alerts in your code hosting.
- Shorten your patch window for internet-facing open-source software, because a public fix can point attackers at the bug.
- If you maintain a project, set up a security email alias, write a threat_model.md, and run tools/check from the oss-scanner repo before you apply.
- When any AI-written bug report reaches you, run its reproducer first. A report that reproduces is evidence. One that does not is a claim.

## What is still unknown

- Every accuracy figure comes from Anthropic. The 97-finding check covered critical and high findings only, and we found no independent audit of the scanner's output yet.
- The FAQ says only "our strongest models". The research post names Claude Mythos, but which model scans which project is not stated.
- Anthropic has not said how many projects are enrolled, how often they are rescanned, or how many reports a typical project should expect.
- How disclosure deadlines will work for high-severity unvalidated reports is still open. The FAQ says they may be added later with notice.
- The point about public fixes guiding attackers is our analysis of how patches work generally, not something Anthropic or any maintainer has reported about this program.

## Sources

[AI News Report](https://theainewsreport.com/)· every headline, every morning.
