🔐 Anthropic OSS Scanner: a technical deep dive

OSS Scanner is a free, opt-in service that Anthropic launched on 8 October 2026. It runs periodic vulnerability scans of critical open-source projects with Anthropic's strongest models, including Claude Mythos, and emails the findings straight to the maintainers.

The trade-off is explicit: reports are fully model-generated and are sent without human review. Maintainers get findings faster, but they also take on the triage. Anthropic expects a true-positive rate above 90%. In an early validation, pen testers confirmed 85 of 97 high/critical findings.


🧭 Context: from Glasswing to the Cyber Mission

OSS Scanner is the open-source half of the Anthropic Cyber Mission, announced the same day. It grows out of six months of vulnerability hunting under Project Glasswing.

Two technical differences from Claude Security stand out in the FAQ. OSS Scanner uses a variety of harnesses, including additional "token-hungry" experimental ones aimed at deeper bugs, and Anthropic pays for all of it.

Two neighbouring programmes complete the picture for maintainers. Claude for Open Source offers free Claude Max 20x subscriptions to help fix vulnerabilities. The Cyber Verification Program gives vetted security professionals, open-source maintainers included, access to advanced cyber capabilities with reduced blocking classifiers.


🛠️ Enrollment: what a maintainer actually submits

Enrollment is one pull request to anthropics/oss-scanner that adds a projects/<name>/ directory. The project's own code can live on any git host; only the PR goes to GitHub.

Eligibility. Anthropic applies criteria similar to OSS-Fuzz: established projects with a critical impact on infrastructure and user security, judged case by case. Exposure to remote attacks (e.g. libraries that parse untrusted input) and the number of dependants count. Each core maintainer is verified manually, and Anthropic may contact the project through other channels if unsure. The FAQ is blunt that the service is built for projects that already keep up with verified high/critical reports.

The config starts from templates/project.yaml in the repo:

repo: https://github.com/example/project    # required: the git repository to scan; add #branch to pin one
primary_contact: security@example.org       # required: reports and build problems go here (one address)
auto_ccs:                                   # optional: more addresses on every mail
  - maintainer@example.org
homepage: https://example.org               # optional
disabled: false                             # optional: true pauses reports without removing the enrolment
dockerfile: .oss-scanner/Dockerfile         # required unless a Dockerfile sits in this repo next to your project.yaml
threat_model: .oss-scanner/threat_model.md  # optional; also supports placing the file in this repository


Before opening the PR, the README suggests two checks. tools/validate.py lints the projects/<name>/ directory. tools/check <name> builds the image the way the scanner will and opens a shell in it with no network; --qemu does the same in VMs laid out like the scanner's. They need git, Docker and Python 3 with PyYAML (--qemu: Linux x86-64 with QEMU).

⚠️ Three practical gotchas from the README:

  • The email addresses in project.yaml are public. Use a security alias.

  • tools/check runs your Dockerfile with network access. It can reach services on your machine and LAN, so only check projects you trust.

  • tools/check installs Claude Code into the image, as the scanner does. Claude Code has its own terms.

By signing up, maintainers accept the OSS Scanner terms.


⚙️ How the pipeline works

The project is built with network access, then audited with none; the result is an email, not a code change.

After the merge, the scanner imports the project and builds it online in an isolated VM. The VM then moves to a network with no Internet access for the audit. If the build fails, primary_contact gets an email with the error. The pipeline uses agents to double-check bugs, propose patches and do root-cause analysis. After the first full scan, rescans look for bugs introduced since the last scan and ones missed earlier. Their frequency is not published; it depends on the number of projects in the pipeline, how widely a project is used and other factors.


📄 What a report contains

OSS Scanner reports themselves are private, so no real one is public. Anthropic does publish its human-verified CVD reports once their disclosure window closes, and they use the same ANT-2026- IDs. The table compares a published one with what the OSS Scanner documentation promises.

That PostgreSQL finding also shows a typical CVD timeline: discovered on 2 April 2026, sent to the maintainers on 8 May, acknowledged on 9 May, patched on 14 May (CVE-2026-6479) and made public on 21 July. It was found by Claude Opus 4.6. Every ledger entry also carries a SHA-3-512 hash commitment, published before the details, so the later disclosure can be checked against it.

👀 Who sees the reports, and when they become public

Reports go to the project's own contacts and a restricted Anthropic team, and nobody else. Anthropic does not publish OSS Scanner findings.

Why no 90-day clock? Anthropic's reasoning in the FAQ: since the findings may contain false positives, it will not force maintainers to read each one carefully when Anthropic has not done so itself.

One consequence matters for downstream users. An OSS Scanner fix may ship without a CVE or a GitHub advisory, so dependency scanners may never flag it. Even on the human-verified side, Anthropic's CVD dashboard notes that some maintainers ship a fix without publishing an advisory.


🩹 Does it fix bugs by itself? No, it proposes

OSS Scanner suggests fixes but never applies them. Inside the pipeline, agents double-check each bug, run root-cause analysis and propose a patch; the output is an email. The config only asks for a URL to clone and an email address, and the documentation describes no commit, PR or write access to your repository.

What the maintainer controls is the shape of the patch. In threat_model.md you can ask for a minimal patch that just demonstrates the issue, or a maximal, merge-ready one, and you can change that file between scans.

Early users say the patches are usable. wolfSSL reported that, with patches attached, the reports fitted straight into its existing verify-and-fix process. PostgreSQL's Noah Misch said several reports came with fixes the project could use nearly as-is.

Automated fixing is on the roadmap, not in the product. The Cyber Mission post lists three next steps for open source: get findings to maintainers faster, automate triage and patching (still mostly manual) for projects that want it, and research new secure architectures and coding practices. No dates are given.

Today, the closest thing to automated remediation is to hand the report to an agent yourself. Claude for Open Source gives eligible maintainers free Claude Max 20x subscriptions for exactly that kind of work.


📊 Numbers and accuracy

The models find far more than people can review, and maintainers fix far less than they receive. The chart uses Anthropic's own CVD dashboard, the human-verified track that runs alongside OSS Scanner.

The fixing gap is narrowing but still large. On 22 May 2026 the dashboard showed 1,596 findings reported and 97 patched, a ratio the Cloud Security Alliance highlighted in June. Separately, 584 CVE or GHSA identifiers have been issued across all findings (219 CVEs, 365 GHSAs), whether or not a patch has shipped.


✅ How accurate are the models?

  • OSS Scanner, early version: pen testers checked 97 critical/high findings across 48 projects. 85 (88%) met the CVD bar, 11 were real but duplicates, and 1 was a false positive.

  • CVD track: external firms confirmed 5,674 of 6,123 reviewed findings, a 92.7% true-positive rate. That rate includes duplicates and "won't fix" bugs, so Anthropic calls it only one proxy for impact.

  • Anthropic's expectation for OSS Scanner: a true-positive rate above 90%.

  • Benchmark trend: on the academic CyberGym benchmark, LLMs went from finding under 20% of vulnerabilities at the start of 2025 to over 85% in 2026, per the launch post.


⚖️ Severity: Claude rates higher than human reviewers

Claude's initial severity matched the external firm's rating in 83.0% of 1,337 triaged findings, and fell within one band in 97.1%. The misses lean one way: of 259 findings Claude called critical, the firms rated 116 critical and 121 high.

Anthropic's explanation: maintainers often apply project-specific severity rules that Claude does not see, and the firms take that context into account. For OSS Scanner, this is exactly what the severity rubric in threat_model.md is for.


🗣️ Reception: praise from maintainers, scepticism about volume

Early maintainers are positive; the open question is volume, not quality.

What early users said (quoted in Anthropic's launch post):

These are vendor-selected quotes. Independent coverage (Help Net Security, Security Affairs, BetaNews) repeats them and focuses on the trade-off: triage work moves from Anthropic's reviewers to the maintainers.

Why volume is a sore point. 2026 has been the year of AI "slop" reports:

  • January 2026: curl ended its HackerOne bug bounty after a flood of low-quality AI reports (BleepingComputer).

  • May 2026: Linus Torvalds wrote that AI reports had made the kernel's private security list almost unmanageable, as reported by BetaNews.

  • Mid-September 2026: Intel removed financial rewards from its Intigriti bug bounty (BleepingComputer, same article).

  • 1 October 2026: Google paused product-vulnerability submissions to its OSS VRP, citing a rise in automated submissions, most of them invalid. An update is promised for Q1 2027 (SecurityWeek).

Anthropic's design answers this with three guardrails: the service is opt-in, each report is meant to carry a reproducer, and there is no forced disclosure deadline. What it cannot change is maintainer capacity, which is why the FAQ steers projects without triage bandwidth to the human-verified route.

Known weaknesses, in Anthropic's own words: severity ratings can be inflated, and the scanner sometimes misreads a project's threat model. The CVD data in the numbers section above quantifies the severity gap.


🏢 What it means if you are not a maintainer

For most companies, OSS Scanner changes the speed of upstream fixes, not their own scanning. It only covers opted-in, accepted projects, and results go to those projects, not to their users.

Three facts from the sources shape the practical picture:

  • Exploits are fast now. Anthropic's launch post says exploits can now be developed in minutes, so a fix that sits unapplied is a growing risk.

  • "Patched upstream" is not "patched in production". The CVD dashboard counts upstream fixes and states plainly that this does not mean the patches are widely installed.

  • Fixes can be silent. Some upstream fixes ship without a CVE or GHSA, and OSS Scanner findings are not published at all. Tooling that only matches advisories will miss those.

Practical takeaways (our reading of the above, not Anthropic guidance):

  • Shorten the dependency-update cycle for internet-facing components. Your patch cadence, not discovery, is now the slow step.

  • Track upstream releases of critical libraries, not only CVE feeds.

  • If your engineers maintain an open-source project your business relies on, decide whether it has the capacity to enroll, or should stay on the human-verified route.

Options for your own code and systems:

CVP requires data retention so Anthropic can monitor for misuse. It is available on the Claude Platform, Google Cloud Vertex AI and Microsoft Foundry; on Amazon Bedrock only for customers eligible for Enterprise Frontier Safeguards.


📚 Sources

Anthropic's pages, the GitHub README and The Hacker News article were read in full on 12 October 2026. The other independent articles were checked through their published excerpts.

Primary (Anthropic)

Independent coverage