---
title: "OSS Scanner: a free security inspection for critical open source"
description: "Anthropic's OSS Scanner runs periodic AI security scans of critical open-source projects at no cost. What a report contains, who qualifies, how to enroll, and how to triage the results."
canonical: "https://me.consonance.fyi/en/blog/anthropic-oss-scanner/"
lang: "en"
published: "2026-11-03"
---

# OSS Scanner: a free security inspection for critical open source

> Anthropic's OSS Scanner runs periodic AI security scans of critical open-source projects at no cost. What a report contains, who qualifies, how to enroll, and how to triage the results.

By Minh-Toan Ta · 3 November 2026 · 6 min read

Think of a building the whole neighbourhood relies on: the old bridge, the water tower, the block of flats above the bakery. Someone offers a free, recurring inspection, with a note for every crack: where it is, why it formed, and a sketch of the repair. One condition: the inspector is a machine, and nobody re-reads its notes before they reach you.

That is, more or less, what Anthropic opened on October 8, 2026 under the name OSS Scanner. Here is what it is, who it is for, and how to use it without drowning in reports.

## The idea in one sentence

OSS Scanner is a free, opt-in service in which Anthropic regularly scans critical open-source projects with its strongest models and emails the maintainers what it finds, each report with a reproducer and, when possible, a proposed patch, with no human review before it is sent.

## What the program does

Once a project is enrolled, the scanner builds it from a Dockerfile you supply, inside an isolated virtual machine, then cuts Internet access and runs the analysis in a hardened sandbox. Per the service page, agents double-check bugs, propose patches and analyse root causes, using several harnesses, some costly or experimental, to reach deeper bugs. Scans repeat over time to catch newly introduced flaws and ones missed earlier; the frequency is not fixed and depends on load and on how widely the project is used.

The page speaks of "our strongest models" without naming one for this service. Some news coverage mentions Claude Mythos, but I could not confirm that on Anthropic's own pages, so I will not claim it.

## What a report contains

Reports arrive by email as a bundle (the format may change), each with an identifier such as ANT-2026-ABCD1234 for attribution. Depending on the case, a report may include:

- **A proof of concept (PoC).** A reproducer: an input or short script that actually triggers the bug. It is the difference between "this looks risky" and "watch it crash".
- **A root-cause analysis.** Why the bug exists: a missing bounds check, a wrong assumption about input length. Fixing the cause rather than the symptom also closes the variant next door.
- **A suggested patch.** A candidate fix, minimal or close to merge-ready depending on what your threat model asks for.
- **A severity rating**, following your project's own rubric if you provide one.

## Who can join

The bar resembles Google's OSS-Fuzz, the free fuzzing service launched in 2016 after Heartbleed, which accepts projects with "a significant user base" or that are critical to global IT infrastructure. Anthropic phrases it as "established projects that have a critical impact on infrastructure and user security", decided case by case. The factors it names, in plain words:

- **Exposure to remote attacks.** Code that handles input from the network or from strangers (parsers, servers, file-format libraries) is where an attacker can reach in.
- **Number of users and dependent projects.** A bug in a library used by thousands of projects is, in practice, thousands of bugs.
- **Age and update frequency.** An established, active project can act on a report; an abandoned one cannot.
- **OpenSSF Criticality Score.** A score from 0 to 1 estimating how influential a project is, computed from signals such as age, contributors, commit frequency, releases and dependents.
- **A commonly accepted open-source license.** The service is for open source in the usual sense.
- **Stars, forks and usage statistics.** Imperfect signals, but they show reach.
- **How security-critical the project is, and for which sectors.** A TLS library weighs more than a slideshow theme.
- **Completeness of the required fields.** An incomplete application simply stalls.

The list is not exhaustive; if your project's importance is not obvious, explain briefly why it matters for security.

## Who usually can't

Brand-new projects, and forks, unless a fork is clearly distinct from the original and qualifies on its own. The service also targets teams already able to keep up with verified high and critical reports: if a stream of serious findings would paralyse you, it is too early. Finally, the person enrolling must be the lead maintainer or authorized by them, and by their employer when an organization maintains the project.

## How to apply, step by step

1. **Fork anthropics/oss-scanner** and create a directory named after your project under projects/.
2. **Add a project.yaml** based on the template. Only repo and primary_contact are always required:

   ```yaml
   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
   output_format:
     email:
       min_severity: low
     github_security_advisory:
       min_severity: none
   ```

   The addresses in this file are public, so use a security alias rather than a personal inbox.

3. **Provide a Dockerfile** that installs every dependency and builds the project. The build has network access, the audit does not, so fetch everything the build and tests need up front. Keeping it in your own repository is preferred: you can then update it without a new pull request.
4. **Write a threat_model.md** (optional, strongly recommended): what the project does, where untrusted input enters, what is out of scope, and how you rate severity.
5. **Check locally** with tools/validate.py, then tools/check followed by your project name, which builds the image like the scanner and opens a shell without network. If your tests pass there, the scanner will most likely work.
6. **Open the pull request** and accept the terms. A human reviews it and checks that the contact is a real security contact, for example the one listed in your SECURITY.md. Eligibility is rechecked before each send.

To pause, set disabled to true; to leave, delete your directory.

_From the pull request to the fix: the scanner works offline and repeats, but triage stays with you._

## What it means for maintainers

The benefit is obvious: a recurring security audit most volunteer projects could never pay for, with reproducers and patches included, steered by your threat model.

The workload is just as real, and the terms spell it out. Reports are AI-generated and "may be incomplete and inaccurate"; you are responsible for reviewing each report and its patch before changing anything. Reports are confidential until the bug is fixed or publicly disclosed. Unvalidated findings carry no 90-day public deadline, and Anthropic says it will not publish them. If a human later validates a finding through Anthropic's disclosure program, it may be disclosed 90 days after you are notified. Anthropic adds that it may, in the future, set a disclosure period for some high-severity reports, with advance notice and an opt-out. The service is provided "as is", and Anthropic's liability is capped at 1,000 dollars.

A few triage habits help:

- **Reproduce before anything else**, in a disposable environment.
- **Re-rate severity** against your own rubric, not the model's.
- **Group by root cause**: five reports can describe one bug.
- **Review the patch like an outsider's pull request**, and report false positives.

> **Get ready before you apply**
>
> Publish a SECURITY.md that explains how to report a vulnerability and which versions are supported, and point it to the same security alias you put in project.yaml. Then decide who will read the reports, and when. A free scanner is only useful if someone has the time to triage it.

> **An AI report can be wrong**
>
> A confident write-up is not proof. Run the PoC yourself and watch it fail before you touch the code. A patch for a bug that does not exist can introduce one that does, and a suggested fix may treat the symptom rather than the cause.

## What it means for everyone else

If you use software, you use open source, so a free inspection of the foundations is good news. But finding is not fixing. The New Stack summed it up in a headline: Claude found 29,000 possible bugs in open source, and only 516 have been fixed. The bottleneck moves from discovery to maintainer time.

That is why coordinated disclosure matters: the maintainer is told privately, gets time to fix, and the details go public only afterwards, so attackers do not learn about a hole before users can close it. For the rest of us: keep dependencies up to date, watch security advisories, and support maintainers with funding or review time.

## Conclusion

OSS Scanner gives critical projects something that used to be reserved for well-funded teams: a regular, thorough security look, delivered with a reproducer and a draft fix. The price is not money but attention. The model writes the report; a human still has to reproduce it, judge it and ship the fix.

*Independent summary, not affiliated with Anthropic. Facts are taken from the sources listed below.*

## Sources

- [Anthropic · OSS Scanner (service page and FAQ)](https://red.anthropic.com/oss-scanner)
- [Anthropic · OSS Scanner terms](https://red.anthropic.com/oss-scanner/terms)
- [GitHub · anthropics/oss-scanner](https://github.com/anthropics/oss-scanner)
- [Anthropic · Coordinated vulnerability disclosure for Claude-discovered vulnerabilities](https://www.anthropic.com/coordinated-vulnerability-disclosure)
- [Google · OSS-Fuzz](https://google.github.io/oss-fuzz/)
- [Google · OSS-Fuzz, accepting new projects](https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/)
- [OpenSSF · Criticality Score](https://github.com/ossf/criticality_score)
- [GitHub Docs · Adding a security policy to your repository](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository)
- [The New Stack · Claude found 29,000 possible bugs in open source](https://thenewstack.io/anthropic-oss-scanner-vulnerabilities/)

---

- HTML: https://me.consonance.fyi/en/blog/anthropic-oss-scanner/
- [Français](https://me.consonance.fyi/blog/anthropic-oss-scanner.md) · [Tiếng Việt](https://me.consonance.fyi/vi/blog/anthropic-oss-scanner.md)
- MCP: https://mcp.consonance.fyi
- Contact: tmtoan2601@gmail.com · https://www.linkedin.com/in/minhtoanta/