On October 8, 2026, Anthropic announced OSS Scanner, a new service that regularly audits open-source software (OSS) for vulnerabilities at no cost. It uses Anthropic's advanced AI models, including Claude Mythos, to look for vulnerabilities and reports the results to the maintainers of participating projects. Its defining feature is that it delivers reproduction steps and proposed patches without waiting for human verification first. AI is finding vulnerabilities faster than humans can verify and fix them. The service is meant to help projects that have the capacity to respond start investigating earlier.
29,000+ Findings in Six Months, but Only About 6,000 Verified by Humans
According to Anthropic, audits over the past six months turned up more than 29,000 vulnerability candidates, but humans were able to review and prioritize only about 6,000. Not every unverified candidate is a real vulnerability, but it is clear that human verification has not kept pace with the speed of AI discovery.
According to the official announcement, maintainers who received the initial reports increasingly asked to be sent unverified candidates as well. Anthropic responded to these requests and says it has already provided nearly 5,000 reports.
OSS Scanner turns this effort into an ongoing service. Reports include test cases and explanations for reproducing the problem and, where possible, a proposed patch. Some also include the result of narrowing down the change history to identify which change introduced the issue. According to the official FAQ, the audits also use agents that re-check discovered issues and agents that investigate root causes.
Sending large volumes of unverified reports carries risks, however.
Daniel Stenberg, the developer of curl, explained in a July 2025 blog post that handling low-quality AI-generated vulnerability reports had become a heavy burden on maintainers. He wrote that three to four people get involved in checking a single report, each spending 30 minutes and sometimes several hours. For developers with limited time to devote to OSS maintenance, a growing number of false reports is a serious problem.
In a comment included in Anthropic's announcement, by contrast, Stenberg credited OSS Scanner with finding several issues in curl that were worth fixing.
The reports that caused problems in 2025 and OSS Scanner are different in scope, so their accuracy cannot be compared directly. Even so, what matters to maintainers is not whether a report was written by AI, but whether the problem can be reproduced and turned into an actual fix.
Are Over 90% of Reports Correct? What the Initial Check Showed About Accuracy and Challenges
In its Cyber Mission announcement, Anthropic says it expects OSS Scanner's true positive rate, meaning the share of reports that correctly identify real problems, to exceed 90%. This is the company's projection, however, not a measured value or accuracy guarantee for the service as a whole.
A separately published check of the initial version offers a reference point.
Anthropic had penetration-testing experts, who also handle verification in regular coordinated vulnerability disclosure (CVD), review 97 reports of "Critical" and "High" severity vulnerabilities found in 48 projects.
Of these, 85 met the CVD criteria. Of the remaining 12, 11 were real issues but duplicated known problems or other reports, and one was a false positive.
| Classification in the initial check | Count | Share of total |
|---|---|---|
| Reports meeting CVD criteria | 85 | 87.6% |
| Real, but duplicating a known issue or another report | 11 | 11.3% |
| False positive | 1 | 1.0% |
| Total | 97 | 100% |
Source: Anthropic's October 8, 2026 announcement. Percentages are calculated with 97 as the denominator and rounded to one decimal place. Because of rounding, the individual percentages do not sum exactly to 100%.
Including duplicates, the share of reports that pointed to a real problem reaches 99.0%. The share that met CVD criteria as new reports was 87.6%. The 88% figure Anthropic cites is the latter rounded to a whole number.
A problem being real is not the same as its being a new vulnerability report that leads to a fix. Even known issues and duplicate reports require maintainers to spend time cross-checking.
The check was also limited to 97 critical and high-severity reports from the initial version. It is unclear whether the same results would hold across all projects and severity levels, or how many real vulnerabilities the tool misses. While the verification was done by experts, the results were published by Anthropic, and this is not an independent evaluation of the service as a whole.
The company also says maintainers have pointed out cases of overestimated severity and misunderstood threat models. Even when a vulnerability is real, how dangerous it is in an actual deployment must be judged in light of each project's specific conditions.
Registration Requires a Dockerfile; Providing a Threat Model Is Recommended
OSS Scanner targets critical OSS that has a major impact on infrastructure and user safety. Anthropic decides individually whether to accept a project, considering factors such as exposure to external attack and the scale of users and projects that depend on it.
To participate, a lead maintainer adds a configuration file to the registration GitHub repository and submits a pull request. Anthropic also verifies the applicant's maintainer authority, so not every public repository is automatically subject to auditing.
Registration requires the Git repository to be audited, a contact email address, and a Dockerfile for building the execution environment.
Fetching dependencies and building are done in an environment with network access, after which the vulnerability investigation runs in an isolated environment cut off from the internet. Projects therefore need to have all required dependencies in place during the initial build and confirm that tests run in the finished environment.
Reports arrive by email. The email address listed in the registration configuration file is made public, so the official instructions advise using a security contact that is fine to expose. Registering an OpenPGP public key allows reports to be encrypted, but in that case additional CC recipients cannot be specified. Even if registration information is published on GitHub, the vulnerability reports themselves are not made public.
To improve audit accuracy, Anthropic strongly recommends an optional "threat model."
A threat model can describe anticipated attacks, paths for untrusted input, features to focus on, and areas to exclude from inspection. Maintainers can also state their preferences on the criteria for judging severity, the report format, the level of detail of proposed fixes, and the handling of duplicate reports.
For example, how severe an issue exploitable only by authenticated users, or a buffer overflow with no confirmed real-world exploitation, should be rated varies by project. Without these assumptions, the AI has to guess at unclear conditions, which can lead to excessive warnings.
OSS Scanner draws inspiration from Google's OSS-Fuzz. Whereas OSS-Fuzz does large-scale fuzzing, running software with a variety of inputs to find crashes and abnormal behavior, OSS Scanner uses a language model to examine code and reports reproduction steps and even proposed fixes.
Because the approaches differ, combining it with existing fuzzing may widen the scope of inspection. However, this announcement does not demonstrate that it outperforms OSS-Fuzz or can replace conventional testing.
The 90-Day Disclosure Deadline Does Not Apply to Reports Not Yet Verified by Humans
OSS Scanner's vulnerability disclosure policy states explicitly that the 90-day coordinated vulnerability disclosure deadline does not apply to reports that have not been verified by humans.
The reason is that maintainers are not required to verify within a deadline issues that Anthropic itself has not confirmed. Anthropic will also not publish such unverified reports.
The treatment changes, however, if a human later confirms the vulnerability through the regular CVD process. In that case, Anthropic may disclose the information under its regular CVD policy, counting from the date it notifies the maintainer that verification is complete.
Under Anthropic's regular CVD policy, information is in principle disclosed at the earlier of 90 days elapsing or a patch being released. There are exceptions, including deadline extensions and earlier disclosure for vulnerabilities already being exploited. For publishing full technical details, the policy generally waits 45 days after a patch is available to give users time to apply the fix.
In other words, a 90-day clock does not automatically start the moment an unverified report arrives.
Anthropic indicates it may in the future set disclosure deadlines for some critical OSS Scanner reports as well. If so, it says it will give advance notice and offer the option of withdrawing from participation.
Maintainers can currently pause reports through a configuration change and leave the service by deleting their registration. After leaving, they return to receiving only CVD reports that humans have verified, as before.
Can Free Audits Be Turned Into Actual Vulnerability Fixes?
Anthropic positions OSS Scanner as a service for projects that can already handle verified critical and high-severity vulnerability reports and want to improve their security further. For projects short on staff or time, it says it will continue providing human-verified reports.
Unlike Claude Security, its commercial service for enterprises, OSS Scanner has Anthropic cover the full cost of auditing. The company says it will also deploy experimental audit methods that use more computing resources, which lets even small maintainer teams tap compute they would find hard to secure on their own.
Even when a proposed patch arrives, however, maintainers still need to check whether it is correct and whether it harms existing functionality. Decisions about which versions to apply the fix to and how to deliver it to users also remain with them.
Continuous auditing investigates not only newly introduced vulnerabilities but also problems missed in past audits. The run frequency, however, varies with factors such as the number of participating projects and usage levels, and projects will not necessarily be scanned daily or on every code change. Maintainers need to keep their existing tests and security checks running while building the capacity to handle the additional reports.
In evaluating OSS Scanner's practical value going forward, the number of vulnerabilities found is not the only thing that matters. How many duplicate reports are included, how many hours maintainers spend on verification, and how many days pass between a report and a completed fix will be more important indicators.
Now that AI can find vulnerabilities in large numbers, the challenge has shifted to whether humans can verify that information without undue strain and turn it into fixes. Whether OSS Scanner contributes to real security gains depends not only on its discovery ability but also on whether it can move fixes forward while keeping the burden on maintainers low.