Blog › Sicherheit
SicherheitKICoding

OSS Scanner: Anthropic Scans Open Source for Vulnerabilities, With No Human in Between

· David Krcek · 10 min read
OSS Scanner: Anthropic Scans Open Source for Vulnerabilities, With No Human in Between

Models now find more security vulnerabilities than humans can review. Anthropic describes this bottleneck itself, and the new service OSS Scanner, available since October 8, 2026, is meant to get around it. Selected open-source projects get regular security scans by Anthropic’s strongest models, including Claude Mythos, at no cost. The reports go straight to the maintainers without a human checking them first, and they are not published.

The Bottleneck Is Human

For months, Anthropic has had its models search important open-source projects for vulnerabilities, among other things as part of Project Glasswing, the program through which selected partners get access to Mythos. The public dashboard, as of October 2, 2026, shows the scale for the period since November 2025.

Metric (Anthropic)Value
Candidate vulnerabilities29,439
reviewed by six external security firms6,123
confirmed5,674 (92.7%)
reported to maintainers6,157 in 591 projects
identifiers assigned219 CVEs and 365 GHSAs
patches landed516

A CVE is a public, globally unique identifier for a vulnerability, and a GHSA is the equivalent identifier in GitHub’s advisory database. According to the dashboard, the 6,157 reported findings consist of 1,333 reports after review by the firms and 4,824 reports sent directly by Anthropic. I am not aware of any independent analysis of these numbers.

They show the backlog nonetheless. Of almost 30,000 candidates, a human has looked at just over a fifth. The dashboard explicitly calls independent human review the rate-limiting step.

Maintainers themselves pointed to a way out. After the first reviewed reports, many asked to receive everything right away, including unreviewed findings with proposed patches. According to the announcement, Anthropic has sent almost 5,000 such reports this way. OSS Scanner turns that into a regular offering.

A Pull Request as Enrollment

Enrollment works through a pull request to the repository anthropics/oss-scanner. A project adds a directory there with a project.yaml naming the repository and a contact address, plus a Dockerfile that installs all dependencies and builds the project.

repo: https://github.com/example/project
primary_contact: security@example.org
dockerfile: .oss-scanner/Dockerfile
threat_model: .oss-scanner/threat_model.md

According to the README, Anthropic builds the project in an isolated virtual machine with network access and then moves it to a network without internet. Only then does the scan start. Results arrive by email, PGP-encrypted on request. A report contains a self-contained reproducer, meaning a program or input that triggers the bug, an explanation of the vulnerability, where possible a bisection, meaning the search for the commit that introduced the bug, and, if available, a proposed patch.

The README explicitly recommends the optional threat model in threat_model.md. In it, a project describes where untrusted input enters, what is out of scope, and how it rates severity, for example whether a post-authentication SQL injection counts as high or critical. Without this file, the scanner works with its own assumptions. According to the announcement, some maintainers told Anthropic that the scanner overrates severity or misunderstands a project’s threat model.

Hit Rate According to Anthropic, Verdict of the Maintainers

Anthropic trialled an early version with dozens of projects. According to the announcement, the penetration testers who also review Anthropic’s regular findings checked 97 findings rated critical or high from 48 projects. 85 of them (88%) met the bar for the regular disclosure process. Of the remaining twelve, eleven were real but duplicates of known bugs, and only one was a false positive.

The announcement also quotes voices from PostgreSQL, the OpenSSL Corporation, wolfSSL, and HotCRP. According to wolfSSL, all but two of 74 reports were valid, and five became CVEs. Anton Arapov of the OpenSSL Corporation writes that the reports were as good as those from people, sometimes better. Anthropic selected these quotes, and they are not a cross-section.

Another project provides the contrast. In January 2026, curl ended its bug bounty program because AI-generated reports overwhelmed its small security team. According to maintainer Daniel Stenberg, only about five percent of reports in 2025 were real vulnerabilities. The two findings come from different projects, with different models and different senders. They do suggest, however, that the quality of model-generated reports has improved considerably, at least for targeted scans.

Enrollments: 87 Pull Requests, None Accepted

Following the criteria of Google’s OSS-Fuzz, a continuous test that feeds software random input to find crashes, the service targets established projects with “critical impact on infrastructure and user security”. The enrollment repository shows how many projects sign up anyway. I counted via the GitHub API on October 9 at 9 a.m. CEST, a little over 13 hours after the repository was created.

Enrollment status (own count)Number
Pull requests in total87
open76
closed11
accepted0

The open enrollments include well-known names such as NestJS and the ABP Framework, but also MCP servers for 3D printers, hobby projects, and the static website of a coffee shop. All eleven closed enrollments got the same question: how widely is the project used? For one enrollment, the repository’s automated check found that the commits had not been authored by the person who opened the pull request, but by Claude. A single case, but a telling one.

Anthropic gives no reasons for the narrow selection. Compute cost is an obvious candidate, since Anthropic covers it in full, but that is my assumption. The consequence is that the many small projects that large software is assembled from stay outside for now.

Confidential Reports, Missing Advisories

According to the README, the unreviewed reports carry no disclosure deadline, and Anthropic does not publish them. Only when a finding is later confirmed by a human in the regular process can it become public 90 days after that confirmation. The terms oblige participants to keep reports confidential until the vulnerability is fixed.

For everyone who runs this software, that can become a gap. Software composition analysis tools, which check dependencies for known vulnerabilities, match versions against CVE and GHSA databases. If a project fixes a finding without an advisory, meaning a public security notice, these tools stay silent. Nobody then learns that an update is urgent.

An analysis by Rajesh Beri points to this problem. The numbers so far hint at the size of the gap without proving it. 6,157 reported findings face 584 identifiers and 516 patches. How many findings were fixed quietly, how many are still open, and how many turned out to be duplicates, the dashboard does not say.

OSS-Fuzz, which Anthropic cites as its model, works differently. There, findings become public after 90 days or once a fix is released, whichever comes first. According to the FAQ, Anthropic reserves the right to introduce a deadline for highly critical findings in the future as well.

According to the terms, liability is capped at $1,000, and the reports come explicitly without warranty. Whether submitted code is used to train models, I found nothing about in either the FAQ or the terms (as of October 9).

f451 as a Test Case

To see how much work an enrollment takes and what a model finds with a threat model, I tried it on my own project, f451. A real enrollment would have had no chance, since the wiki has only been public since the end of September. The tools in the repository, however, can be used without enrolling.

f451 needed three files. The project.yaml names the repository and contact. The Dockerfile installs the dependencies of the pnpm monorepo, type-checks, builds the API, the MCP service, and the web interface, and runs the Markdown tests that need no containers. The threat model describes where untrusted input enters f451, namely in Markdown pages, uploads, the HTTP API, and the MCP service, and how to rate findings.

tools/validate.py accepted the enrollment. tools/check then built f451 the way the scanner does. First the image is built with network access, then the tool adds the scanner’s layer on top and starts the result without a network. The f451 part took just over two minutes, the whole run just under three. The scanner’s layer is revealing. It installs Claude Code, along with compilers and debuggers, into the image. That suggests the scanner works as an agent inside the built project. A practical detail on the side is that tools/check assumes Docker. With Podman, it needed a small wrapper.

Only Anthropic runs the scanner itself. As an approximation, I pointed Claude Code with Opus 5.5 and the same threat model at a fresh clone of f451. That is neither Mythos nor Anthropic’s scanning pipeline, but the same kind of tool with the same instructions. After 55 steps and just under ten minutes, a report was ready. The run cost $4.43.

Scan result (own test)Number
high severity4
medium1
low1
unconfirmed1

The four high-severity findings were an HTML injection, because the web interface split already-sanitized HTML with a regular expression, a bypass of the permission check through percent-encoded paths when the API is directly reachable, a full-text search that leaked content above a token’s classification limit through prefix queries, and a check that judged drafts by the classification of the published version instead of their own. I reproduced the first two myself. Two of the four concerned the classifications from version 1.1, of all things, a feature less than two weeks old.

All four are fixed in f451 1.2.13. That put me in front of exactly the question this article raises, and I published two advisories in GitHub’s database. GHSA-c436-86vv-rgwc combines the three findings around API tokens at high severity, GHSA-4rm8-qwpg-m3r8 describes the HTML injection. It is rated medium there, because the web interface’s Content Security Policy prevents injected scripts from running. Anyone running f451 learns through the usual tools that an update is needed.

One lesson concerned the tool itself. I had meant to restrict the agent to read-only tools with --allowedTools. The option, however, only adds to existing permissions and restricts nothing. Because my settings allow Bash, the agent reproduced two findings outside the repository with a script of its own. That was helpful, but not intended. To truly limit a scan to reading, also exclude Bash with --disallowedTools.

A Gain for Maintainers, a Gap for Users

For a large, well-staffed project, there is a lot to be said for taking part. It gets findings with reproducers and proposed patches at no cost, and earlier than via the detour of human reviewers. According to Anthropic, attackers now build exploits for known vulnerabilities in minutes, so every day of head start counts. Anyone who joins should write the threat model. According to the README, it is the way to steer how severity is rated, and it forces a project to write down its attack surface once.

For everyone who merely uses these projects, something shifts. Part of the security work on central open-source software will happen between an AI vendor and the maintainers, with no public trace. Whether a fix gets an identifier is up to each project. Anyone who wants to credit Anthropic in a commit uses, according to the FAQ, a report identifier in the format ANT-2026-…. Searching commit logs for it is a stopgap, because crediting is voluntary.

The scanner finds the vulnerability. Whether the public learns about it is not up to the scanner.

Sources

David Krcek
David Krcek
AI, Apple Silicon, coding experiments, SwiftUI, and attitude.
Read more