OSS Scanner: 88% of critical findings passed the pentesters' validation

On 8 October 2026, Anthropic launched the OSS Scanner, a free vulnerability scanning service for open source repositories. In the first version, 85 of 97 critical and high findings cleared the company's coordinated vulnerability disclosure (CVD) bar, which gives 88%. The sample was chosen by Anthropic itself, and the review belonged to its pentesters.

Independent validation does not exist here, and the caveat follows the number to the end of this text.

The number matters because it reorders the list, not because it replaces it. Due diligence already asks whether a vendor scans the code it ships, and that still holds. What the first version adds, with 88% of the 97 critical and high findings clearing the CVD bar, is an earlier axis: who absorbs the triage of what the scan produces, and how fast the critical finding becomes a patch.

Anthropic answers that without detour. In the six months before the announcement, it reviewed about 6,000 of the more than 29,000 candidate findings the scanner produced. Almost 5,000 went out raw, to maintainers who asked to receive everything. The triage missing on its side is absorbed by the maintainer of the open project, and the software buyer inherits that debt without seeing it. That bridge is this text's reading, not what the source measures: none of the three sources addresses a buyer or a vendor questionnaire, and adoption by vendors is not measured.

What the OSS Scanner is and what Anthropic opened

The OSS Scanner is an opt-in service that scans open source repositories for vulnerabilities. Accepted projects get periodic scans by Anthropic's strongest models, at no cost. All output is model-generated, with no human review or triage, and the company warns that reports may be incorrect.

The service grew out of Anthropic's experience with Claude finding vulnerabilities in Project Glasswing, and the models include Claude Mythos. Enrollment is a pull request to the anthropics/oss-scanner repository that adds projects/<project>/project.yaml with the repository, the primary contact and a Dockerfile that prepares the environment for an offline agent to run the audit.

Eligibility follows criteria similar to those of OSS-Fuzz: critical impact on infrastructure and security, exposure to remote attack, dependents, OpenSSF criticality score, license, stars and forks. New projects normally do not get in. Forks do not either, unless they are distinct from the original and eligible on their own.

The filter is conservative on purpose.

The OSS Scanner is not Claude Security, the commercial offering that brings Claude Mythos into companies' development cycle. The open service covers the entire cost of the project and applies additional harnesses, more expensive in tokens and experimental, to reach deeper bugs.

Anthropic also offers Claude for OSS, with free Claude Max 20x subscriptions for project maintenance.

88%: the OSS Scanner hit rate as measured by Anthropic's CVD

Anthropic submitted 97 critical and high findings from the scanner, from 48 projects, to the pentesters who already review the company's CVD. Of those, 85 reached the bar of the process. Of the remaining 12, 11 were real but duplicated and only one was invalid. The source does not state which criteria selected the 97 within what the scanner produced. Without them, the 88% measures the precision of a chosen set, not that of the raw output that reaches the maintainer.

The distinction matters more than the percentage. The 11 are not hallucination: the source describes them as real, but duplicates of known problems or of another finding from the same scan. And part of that redundancy is configurable: the optional threat_model.md accepts instruction on the degree of deduplication granularity, and without it the scanner makes assumptions. A slice of the duplicates is a choice of whoever receives, not unavoidable model noise. A single invalid in 97 critical and high findings is a strong result, and the source compares it to the company's own earlier work, without a series on an equal denominator.

The curve that wraps the announcement comes from outside. In CyberGym, an academic vulnerability discovery benchmark, language models went from under 20% at the beginning of last year to more than 85% this year, and the company cites that curve when explaining the quality of the reports.

The caveat sits in the same source. Some maintainers said the severity classification may be inflated, or that the scanner misread the threat model. Inflated severity changes the fix queue, not the fact that the bug exists.

It is the same reading discipline as the security research with frontier models: the number measures what the lab chose to measure.

The bottleneck is human, and Anthropic says so out loud

In the six months before the announcement, Anthropic scanned important projects, found more than 29,000 candidate vulnerabilities and manually reviewed about 6,000. The company states that the bottleneck is human capacity to validate findings. Almost 5,000 reports were sent raw to maintainers who asked for everything.

The difference between 29,000 and 6,000 is what went unreviewed. Speed is the stated argument: exploits can be developed in minutes, so handing the maintainer what has not been read yet is better than holding the finding in the queue until someone opens it.

There is no 90-day CVD window over an unvalidated finding. The company says it does not feel comfortable forcing the maintainer to read every finding it has not read itself, and the 90-day count only starts when a human validates the report. The policy is provisional: Anthropic says it may impose a disclosure window on some high-severity findings once it gains confidence in the scanner's performance, with prior notice and an opt-out for projects. The cost the source names there is attention, not queue time. Almost 5,000 reports nobody read arrive at whoever has to decide, one by one, whether to read, with no human review between what the model wrote and the maintainer's inbox. An alert already triaged is discarded by its signal; this one arrives with no signal.

The cost of validation lives in the attachment. Each report carries a self-contained reproducer, the explanation of the failure with bisection when possible and a candidate patch when available, according to the launch post. The reproducer is what lets a pentester turn the model's claim into fact in minutes, and that is what separates reading from verification.

What the table measures is not a difference of tool, it is the distance between a report that went through a human and one that did not: in the raw one, there is automatic scope verification and double checking, and no human; in the CVD one, the pentester read before disclosure.

Two products, the same model: the free one gets an extra harness, the paid one enters the SDLC

The OSS Scanner does not replace the CVD, which still applies to everyone, open source included. It is an optional fast track, with no human review and no cost to the project. Claude Security is the commercial offering that puts Claude Mythos into companies' development cycle.

The asymmetry the source supports is one of capacity, not of price. The bill changes hands. In the open service, Anthropic covers the entire cost and applies experimental harnesses, more expensive in tokens, to reach deeper bugs. What separates the two is who keeps the work after the report arrives.

The testimonials Anthropic gathered show that the raw report serves whoever has an engineer to validate it. At wolfSSL, there were 74 reports, all but two valid, and five became CVEs, according to Todd Ouska, while at curl the scanner helped find one of the worst vulnerabilities of recent years, according to Daniel Stenberg. At PostgreSQL, an unusually high fraction of findings pointed to defects, with fixes usable almost as they were, according to Noah Misch. At OpenSSL, the raw model report was as good as or better than the one from people, with a real exploit attached, according to Anton Arapov.

The wolfSSL number neither confirms nor denies the 88%, because it measures something else. The 74 are all the reports the company received, and "valid" there is the maintainer's judgment; the 88% is the CVD bar applied to 97 critical and high findings chosen by Anthropic. They are different rulers.

The four cases have something in common, and the source says why: the service is "built for projects that are already able to keep up with verified high/critical vulnerability reports and are now looking to further secure their code". The service is declaredly designed for whoever can already absorb verified reports, and the decision to accept a project is holistic, case by case.

The operational end follows the same design: security and incident response agents only reduce risk with a decision queue.

The other side: the volume nobody asked for

Open source projects have been struggling to keep up with the flood of AI-generated bug reports. The coverage cites Linus Torvalds and Google among those affected. It points to a second story, about the pause of Google's bug bounty program for open source.

The pause is a separate fact, and this text separates it too. Nothing links the two in public source. The problem described is low-quality AI-generated submissions.

The point that matters is the distance between finding and fixing. A scanner that produces more than 29,000 candidates in six months changes nobody's risk if the triage on the other side stays the same.

The same holds for the rest of the defense chain: when AI agents escape containment, the cost is rarely in the alert that was missing.

A finding with no owner is noise with a severity stamp.

Four questions for the next vendor

Due diligence already knows how to ask whether scanning exists. What it does not ask yet is who answers for the findings. The next question changes hands. The four questions below serve any vendor that claims to use AI in vulnerability discovery; each item carries the answer that serves and the one that does not.

1. Who triages the findings, and by what criteria. What serves: the name of the responsible function, the severity criterion and the destination of a finding nobody confirms. What does not serve: "the scanner prioritizes automatically."
2. What is the record of criticals fixed, and how fast. What serves: the count per quarter with the fix date. What does not serve: the number of vulnerabilities found.
3. Does the scan run on the version delivered to me or on the upstream repository. What serves: an answer that distinguishes the contracted artifact from the public tree. What does not serve: "we always use the latest version." The distinction decides: the service FAQ says it normally does not scan forks, unless they are distinct from the original and eligible on their own. A vendor that delivers a fork with backported patches delivers, by the declared rule, a tree outside the reach of the scan.
4. What happens to the unvalidated report. What serves: knowing who reads it, within what deadline and whether it enters the queue. What does not serve: "nothing is lost."

For whoever contracts international software, they join the same table as risks and hidden costs in software imports, because vendor and contract assessment rarely happen apart.

Frequently Asked Questions

What is the OSS Scanner and who is it for? The OSS Scanner is an Anthropic opt-in service that scans open source repositories for vulnerabilities, with periodic scans by the company's strongest models and no cost to the project. It serves the maintainers of established projects, not companies that consume software.

Was the 88% figure independently validated? No. The sample of 97 critical and high findings was chosen by Anthropic, and the review belonged to the pentesters of the company's own CVD. It is the hit rate measured by the company's own CVD, on a sample it chose, not an external audit.

Can an unvalidated report be treated as a confirmed vulnerability? No. The output is entirely model-generated, with no human review or triage, and Anthropic warns that reports may be incorrect or invalid. The company also reports maintainers pointing to inflated severity. With no 90-day window over the raw finding, the CVD clock only starts at human validation.

How do you use this data in software due diligence? By adding a process question to the volume question. Ask who triages the findings, the record of criticals fixed and how fast, whether the scan covers the version delivered to the client and what happens to the unvalidated report.

References and Further Reading

• Anthropic, An opt-in vulnerability-finding service for open-source software, 8 October 2026: anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source
• Anthropic Frontier Red Team, OSS Scanner, changelog with the 8 October 2026 launch: red.anthropic.com/oss-scanner
• The Verge, Anthropic launches free AI security scans for open-source projects, 8 October 2026: theverge.com
• Security research with frontier models
• Security and incident response agents
• When AI agents escape containment
• Risks and hidden costs in software imports
• Buying software on a cloud marketplace

What to do with this

Due diligence does not change its question, it gains an axis. If the vendor scans the code it ships, that stays on the list. What this text adds is who absorbs the triage upstream and how fast the critical one is fixed. The three actions below follow the order in which the risk appears. None of them depends on the published number.

1. Ask for the number of critical findings fixed in the last twelve months, with dates, not the number found.
2. Ask who triages, by what criteria and on what deadline, and ask for the name of the function, not the name of the tool.
3. Treat the unvalidated report as the vendor's internal input, never as evidence delivered to you.

That does not waive the scan.

The honest limit: no public data says how many vendors operate this way. What exists is the 85 of 97 in the first version of the OSS Scanner and the company's own statement, read on 21 October 2026, that the bottleneck is human.

The Nexforce Marketplace brings together global software and AI solutions in local currency, with a tax invoice and centralized purchasing. It organizes procurement, it does not replace technical security assessment, and the four questions fit into the conversation of whoever is going to buy software on a cloud marketplace.