Anthropic Offers Free Vulnerability Scanning for Open-Source Projects

Anthropic Turns AI Vulnerability Scanning into an Ongoing Service

On October 8 local time, Anthropic launched OSS Scanner, an opt-in vulnerability detection service for open-source software.

According to Anthropic, eligible open-source projects can sign up for regular scans using its “most capable models,” including Claude Mythos. The service is free for now. Project maintainers do not need to purchase security tools or deploy scanning infrastructure; they only need to submit a pull request using the standard template in the OSS Scanner GitHub repository and wait for review.

The significance is not that Anthropic has released yet another vulnerability scanner. It is that the company is trying to turn large models’ code-auditing capabilities into an ongoing service for public open-source infrastructure.

Until now, AI-powered vulnerability discovery has mostly taken the form of one-off research projects, features in commercial security products, or internal tools for security teams. OSS Scanner is closer to Google OSS-Fuzz in its approach: prioritize critical open-source components that many projects depend on but that lack sufficient maintenance resources, and make scanning ongoing infrastructure rather than a one-time demonstration.

29,000 Candidate Vulnerabilities Found in Six Months, but Not Enough People to Review Them

The figures Anthropic has published make the problem clear.

Over the past six months, the company used its latest models to scan several core software projects around the world and found more than 29,000 candidate vulnerabilities. But because of the limited number of human security researchers available, Anthropic was able to complete manual review and severity assessment for only about 6,000 of them.

In other words, AI can rapidly scale up the process of finding problems. What is truly scarce is the work that follows: confirming whether a vulnerability is real, assessing its scope, removing duplicate reports, evaluating severity, and coordinating fixes and disclosure timelines with project maintainers.

This is one of the biggest differences between OSS Scanner and traditional security scanning products. Traditional tools often have limited coverage, require complex rule configuration, or struggle to detect novel logic flaws. Large models have an advantage in understanding longer call chains, cross-file data flows, and security issues that depend on contextual details.

But large models can create another bottleneck: they can quickly generate large numbers of plausible-looking reports, yet someone still has to determine whether each one is actually a vulnerability. When the number of candidate reports grows from hundreds to tens of thousands, manual review becomes the limiting step in the process.

Anthropic’s current approach is to separate these two stages. It will continue submitting manually verified vulnerability reports through its existing coordinated vulnerability disclosure (CVD) process, while OSS Scanner provides automated scan results directly to participating projects.

That makes OSS Scanner more like a large-scale early-warning system than a security audit team that delivers “confirmed vulnerabilities.”

88% of High-Severity Findings Passed Review, but That Is Not the Same as an Accuracy Rate

To validate an early version, Anthropic commissioned senior penetration-testing experts responsible for CVD audits to manually review 97 critical and high-severity vulnerabilities that OSS Scanner had found across 48 projects.

The results were:

• 85 vulnerabilities met the criteria for entering the CVD disclosure process, or about 88%;
• Of the remaining 12 findings, 11 were real issues but were either known defects or duplicates of other scan results;
• Only 1 was judged to be an invalid report—that is, a false positive.

That is a strong result, at least insofar as it shows that OSS Scanner is not simply turning suspicious code fragments into vulnerability reports in bulk. For critical and high-severity issues, it can identify a substantial share of findings worth further investigation by security teams.

But developers should not interpret 88% as “the scanner is 88% accurate.” The figures cover only 97 critical and high-severity findings across 48 projects. The sample was selected and does not represent all candidate vulnerabilities, nor does it indicate how the scanner performs on issues of ordinary severity.

More importantly, 11 of the other 12 findings were not pure false positives; they were existing defects or duplicate results. These reports may still be useful to security researchers, but they still take time for open-source maintainers to assess, deduplicate, compare against historical issues, and decide whether to act.

For now, the most reasonable way to think of OSS Scanner is as a service that can significantly expand the range of security issues found, but cannot replace manual security audits, project testing, or maintainers’ judgment.

“Fully Automated” Is Both a Selling Point and a Risk

Anthropic has emphasized that OSS Scanner’s results are generated entirely by large models, with no human review or severity-triage process. Over the past few weeks, Anthropic has tested this automated detection workflow on dozens of open-source projects.

The benefits are straightforward: low cost, high speed, and broad scale.

If Anthropic security researchers had to confirm every report first, the service would quickly revert to the traditional security-team model: limited project coverage, constrained response times, and an inability to handle the huge volume of candidate findings models can produce each day. Giving raw results directly to project maintainers at least lets them see potential issues sooner.

But the tradeoffs are just as clear. Maintainers are not receiving vulnerabilities confirmed by a security team; they are receiving potential issues identified by a model. Reports may involve several kinds of risk:

1. False positives: the model interprets a normal code path as an exploitable vulnerability;
2. Duplicate reports: a single root cause is split into multiple findings, increasing the cost of triage;
3. Re-reporting known issues: the project already has an issue, patch, or public vulnerability record, but the model does not fully recognize it;
4. Inaccurate impact assessments: a code-level flaw exists, but the conditions for exploiting it are demanding, so its severity is overstated;
5. Incomplete remediation advice: the model identifies a problem without fully understanding compatibility, performance, or version-maintenance constraints.

Large commercial software teams may be able to absorb these issues through security operations teams. For an open-source project with only one or two core maintainers, AI reports without structured evidence can become yet another source of work.

The open-source community has already encountered this tension repeatedly: AI rapidly increases the volume of vulnerability reports, but the number of maintainers does not grow along with it. More reports do not necessarily mean better security. If a flood of low-quality reports obscures genuinely serious issues, projects may suffer from alert fatigue.

So OSS Scanner’s success depends not only on how many vulnerabilities its models can find, but also on whether Anthropic can make reports verifiable enough. They should include a minimal reproduction path, affected versions, exploitation prerequisites, data-flow evidence, and remediation advice, rather than simply pointing to a piece of code that looks dangerous.

Not All Projects Will Be Eligible at First

Anthropic says OSS Scanner’s review criteria are similar to those of Google OSS-Fuzz, with priority given to foundational open-source projects that “have a significant impact on critical infrastructure and user security.”

This means the service is unlikely to be open to every GitHub project. Priority will probably go to components with many downstream dependencies, those that play a critical role in internet infrastructure, or those whose vulnerabilities could have widespread effects.

That kind of screening is necessary.

On the one hand, Anthropic still needs to manage its scanning resources and disclosure workflows, so it cannot provide equally thorough, continuous scanning for millions of open-source repositories. On the other hand, fixing issues in critical projects yields greater security benefits. A vulnerability in a widely used networking library, parser, authentication component, or build tool can spread rapidly through the dependency chain. By comparison, even if an issue is found in a small personal project, it may not warrant the same level of audit investment.

But this approach raises a new question: who gets to define “critical”? Dependency counts, download volumes, deployment scale, and security impact do not always align. A component used by relatively few people but running in a highly privileged environment may deserve more attention than a popular web framework.

Project maintainers will also need to consider the sensitivity of their code and vulnerability information. How the scanning service handles private branches, undisclosed security issues, third-party dependencies, and report isolation across versions will all affect whether projects choose to participate. The information Anthropic has published so far focuses mainly on the service’s goals and validation results. Maintainers should still carefully confirm the report format, data-retention policy, scan frequency, and project exit process before signing up.

It Won’t Replace OSS-Fuzz, but It Could Fill Another Gap

It is easy to compare OSS Scanner with Google’s OSS-Fuzz, but the two are not the same kind of tool.

OSS-Fuzz focuses on continuous fuzz testing. It generates large numbers of inputs to expose crashes, memory-safety issues, and other anomalies at runtime. It is particularly well suited to parsers, codecs, and low-level C/C++ components.

OSS Scanner relies more on models’ understanding of code semantics. In theory, it can look for missing permission checks, authentication bypasses, business-logic errors, dangerous configurations, and issues spanning calls across multiple modules. Their relationship is more like “dynamic stress testing” versus “code reasoning”: the former keeps feeding inputs to a program to see when it fails; the latter reads the program’s structure to infer which paths an attacker might exploit.

An effective open-source security program is unlikely to rely on just one of these methods. Fuzz testing is good at finding reproducible runtime anomalies, large models can broaden the reach of manual auditing, and static analysis and dependency scanning are suited to deterministic rule checks. OSS Scanner’s value lies in adding large models to this toolkit, not in using one model to replace every security tool.

Anthropic May Be Trying to Solve More Than a Security Problem

From an industry perspective, OSS Scanner is also a way for Anthropic to demonstrate Claude’s capabilities.

Unlike chatbots or code completion, vulnerability research requires a model to read large codebases over time, understand complex dependencies, and produce conclusions that security researchers can verify. Even if outsiders cannot see the entire scanning process, consistently finding genuine critical vulnerabilities would further strengthen confidence in the model’s code-reasoning and security-analysis capabilities.

Providing free scans for critical open-source projects is also a relatively direct investment in the ecosystem. Large-model companies rely on a great deal of open-source infrastructure but may not contribute directly to maintaining those projects. By providing security scans, Anthropic can apply its models to the public software supply chain while reducing the risk of critical projects being undermined by vulnerabilities.

Free, however, does not mean costless. For Anthropic, the costs are model-inference resources and coordination by its security team. For maintainers, they are the time spent reading reports, confirming impact, coordinating disclosure, and preparing patches. Who ends up doing more work will determine whether this service becomes “security infrastructure” or just another source of alerts that maintainers have to handle.

What Should Developers Make of This Now?

If your project is infrastructure, has many downstream users, or handles network input, permissions, credentials, or sensitive data, OSS Scanner is worth applying to try. But once it is in place, it should be part of an existing security workflow, not a reason to treat model reports as definitive conclusions.

You could consider adopting the following practices:

• Require every report to include affected versions, triggering conditions, minimal reproduction steps, and code locations;
• Route model reports to a security issue queue first, without automatically publishing CVEs or labeling issues critical;
• Cross-check findings against existing SAST, dependency scanning, fuzz-testing, and regression-testing results;
• Create a process for deduplicating known issues and repeated reports, so the same root cause does not keep consuming maintainers’ time;
• Prioritize manual review for issues involving remote code execution, privilege escalation, authentication bypass, and supply-chain compromise;
• Define security disclosure channels, response times, and fixed versions when accepting external reports.

Ordinary developers should not expect OSS Scanner to replace code review in the short term. A more realistic way to use it is as an external security researcher that does not get tired and can repeatedly read the code: it can broaden the search, but when it says “there’s a vulnerability here,” you still need to confirm that the issue is real and that fixing it will not break existing behavior.

The real signal from Anthropic’s launch is that AI-powered vulnerability discovery is moving from one-off experiments to ongoing services. In the coming years, open-source projects will routinely receive machine-generated security reports. The focus will shift from “who can find more issues” to “who can provide less noise, stronger evidence, and smoother disclosure coordination.”

OSS Scanner has taken the first step. Its scanning capabilities look promising, but whether it can become security infrastructure that developers are willing to rely on over the long term will depend on Anthropic’s ability to manage the tension between automated scale and human trust.

Sources

• ITHome: Anthropic launches OSS Scanner, using AI to scan open-source software for vulnerabilities for free — Covers OSS Scanner’s launch date, sign-up process, scanning figures, and manual review results.