Anthropic’s OSS Scanner: Free AI Security Scans for Open Source Projects — How to Enroll

Anthropic just launched something that every open source maintainer should know about: OSS Scanner, a free service that uses their strongest AI models to find security vulnerabilities in critical open source projects. It went live yesterday as part of their new Cyber Mission initiative, and it’s already generating buzz in the security community — reminiscent of when AI coding assistants started triggering security alerts and we had to rethink how we handle automated tools.

The pitch is simple. You enroll your project, Anthropic’s models scan it periodically, and you get emailed a report with a proof-of-concept exploit, an explanation of the bug, and a suggested patch. No cost. No human review of the reports — which is both the selling point and the caveat.

I spent the morning going through the enrollment docs and the GitHub repo. Here’s what you need to know if you’re running a project that qualifies.

What OSS Scanner Actually Does

Think of it as Google’s OSS-Fuzz but powered by large language models instead of fuzzers — similar to how I approach locking down your supply chain when AI writes your code. Your project gets built inside an isolated VM with network access, then the VM is moved to a network-isolated environment where Anthropic’s models — including Claude Mythos — comb through the code looking for vulnerabilities.

Each finding comes with a self-contained reproducer, an explanation of the bug (including a bisection to the commit that introduced it, where possible), and a candidate patch when one is available. The reports are model-generated and sent without human review, which means faster delivery but also the possibility of false positives or incorrect severity ratings.

Anthropic says their expected true-positive rate is above 90%. In their early testing, expert penetration testers reviewed 97 critical and high-severity findings across 48 projects — 85 of them (88%) met the bar for Anthropic’s disclosure process. They found over 29,000 candidate vulnerabilities in six months and manually reviewed about 6,000 of them.

Who’s Eligible

This isn’t for every GitHub repo with a README. Eligibility follows criteria similar to OSS-Fuzz: your project should have a “critical impact on infrastructure and user security.” Anthropic decides on a case-by-case basis. If you’re maintaining a widely-used library, framework, or tool that sits in the dependency chain of critical systems, you’re the target audience.

The service is meant for projects with the capacity to keep up with findings. If you’re a solo maintainer who can’t triage reports, Anthropic recommends sticking with their coordinated vulnerability disclosure process instead.

How to Enroll: Step by Step

Enrollment happens through a pull request to the anthropics/oss-scanner GitHub repo. You add one directory:

projects/your-project-name/

Inside that directory, you need two required files and one optional file:

1. project.yaml

This is your scanner configuration. Start from the template in the repo:

repo: https://github.com/your-org/your-project
primary_contact: [email protected]
auto_ccs:
  - [email protected]
homepage: https://yourproject.org
dockerfile: .oss-scanner/Dockerfile
threat_model: .oss-scanner/threat_model.md

The repo and primary_contact fields are required. The dockerfile field is required unless you place your Dockerfile directly in the oss-scanner repo next to your project.yaml. The threat_model field is optional but strongly recommended.

One thing to note: the email addresses in project.yaml are public. Use a security alias or a dedicated address, not your personal email.

2. Dockerfile

The Dockerfile tells the scanner how to build your project. It sets up the environment, installs every dependency, and compiles the code. The initial build runs with network access, but the security audit runs without it — so everything your build or tests need must be fetched during the Dockerfile setup.

You have two options for where to put it:

• In your own repository (preferred): Set the dockerfile: field to its path, like .oss-scanner/Dockerfile. This lets you update the build without opening a new PR to the oss-scanner repo.
• In the oss-scanner repo: Place it at projects/your-project-name/Dockerfile with no dockerfile: key in your project.yaml.

Either way, the scanner builds your project exactly as the Dockerfile specifies. If your tests pass inside the built image, the scanner will likely work with your project.

3. threat_model.md (Optional but Recommended)

This is where you tell the scanner what matters. You can document your security goals, rate severity (is post-auth SQLi high or critical? are buffer overflows without demonstrated exploits capped at high?), describe what the project does, where untrusted input enters, which components matter, and which are out of scope.

Anthropic has found this file is most useful for calibrating severity ratings to your specific project. It can also state how you’d like reports and patches to look.

Validating Your Enrollment

Before you open that pull request, run two commands:

# Validate your project structure
python3 tools/validate.py projects/your-project-name/

# Build your project the way the scanner will
python3 tools/check your-project-name

The first checks your directory against the rules. The second builds your project in a container with network access, then opens a shell in the finished image with no network — exactly like the scanner does. If your tests pass in that container, you’re good to go.

There’s also a --qemu flag that runs the build inside a virtual machine laid out like the scanner’s. This needs Linux on x86-64 with QEMU instead of Docker.

Both tools need git, Docker, and Python 3 with PyYAML (pip install pyyaml) on your host.

What Happens After You Merge

Once your PR is merged, the scanner imports your project and builds it online in an isolated VM. Then it moves the VM to a network with no Internet access and starts scanning. If the build fails, you get an email at your primary_contact with an error message.

Findings are emailed to your primary_contact and any additional CCs, with reproduction steps and a proposed patch where available. You can edit your project at any time with a PR. To unenroll, set disabled: true to pause reports or remove your projects/your-project-name/ directory entirely.

The No-Human-Review Tradeoff

This is the part that gives me pause, and it’s worth thinking about before you enroll. The reports are fully model-generated. No human triages them before they land in your inbox. Anthropic is transparent about this — they say it enables faster and more frequent scanning, but it means some reports will be incorrect or invalid.

They don’t place a 90-day disclosure period on these findings, and they won’t make them public. That’s actually a relief for maintainers — you’re not racing a disclosure clock. But it also means you’re the first line of defense against false positives.

If you want encrypted reports, you can add your armored OpenPGP public key to project.yaml. Reports then go to primary_contact only — PGP can’t be combined with auto_ccs.

My Take

This is a genuinely useful service for the open source ecosystem. The fact that it’s free and uses some of the most capable models available makes it accessible to projects that couldn’t afford enterprise security tooling — similar to how Cisco Antares brought open source security AI models to the masses at pennies per run. The no-human-review model is a calculated tradeoff — faster delivery at the cost of some noise.

If you’re maintaining a project that qualifies, it’s worth enrolling. The enrollment process is straightforward, the validation tools are solid, and the worst case is you get some false positives to triage. The best case is you catch a critical vulnerability before someone else does.

For projects that don’t meet the eligibility bar, Anthropic’s existing coordinated vulnerability disclosure process is still there — and for those of us who just consume open source software, guides like detecting compromised npm packages remain essential reading. And for those of us who just consume open source software, services like this are a reminder that the ecosystem is slowly getting the security investment it deserves — something I thought about when I covered Destructive Command Guard and the broader movement to rein in autonomous tools.