← All articles

Mikhail Polyakov

Anthropic scans open-source code for vulnerabilities at no cost: what was announced and what it means for your company

Level: BeginnerReading time: 11 min

Topics: AI, Security, Small business

A translucent shield made of glowing lines and nodes, a scanning beam passing through it, a few nodes highlighted in orange, blurred server racks behind

Short answer: on 8 October 2026 Anthropic announced a service called OSS Scanner. An open-source project can apply, and if it is accepted into the programme, its code will be scanned periodically by the company's strongest models, with vulnerability reports going free of charge to the people who run the project (they are called maintainers). Anthropic writes that the decision to accept is made case by case. The main caveat is in the announcement itself: the reports are fully model-generated, without human review or triage, so some of them may be incorrect. For a company that does not run open-source libraries but simply uses them, one sentence from the announcement matters: according to Anthropic, exploits can now be developed in minutes. An exploit is a ready way to make use of a vulnerability, that is, not just a description of the flaw, but a working way to exploit it. So speed is what has value: how much time passes between a fix being released and being installed at your end. Below: what exactly was announced, which numbers the company gave and with which caveats, what the maintainers said, and what to do about it.

What was announced

Anthropic launched OSS Scanner, an opt-in vulnerability scanner for the open-source world. The post puts it this way: projects that join will receive thorough, periodic security scans by the company's strongest models at no cost. The experience behind it, the company says, comes from its work called Project Glasswing, the details of which the post does not disclose.

Google's OSS-Fuzz is named as the model to follow: that is a project which scans open-source code with fuzzers, that is, programs that feed in random and deliberately malformed data in the hope of causing a failure. The difference is the instrument: language models work here instead of fuzzers.

A vulnerability is a flaw an attacker can make use of: for example, by supplying data after which the program executes someone else's command. A scanner report, as Anthropic describes it, contains a self-contained reproducer (that is, a ready way to repeat the failure), an explanation of the vulnerability and, where possible, a determination of when the flaw entered the code, as well as a candidate patch when one is available.

The numbers from the original source

All the numbers below were given by Anthropic itself in its post of 8 October 2026.

What How many
Candidate vulnerabilities found by the company's models over the last six months over 29,000
Of those, reviewed manually approximately 6,000
Reports sent to maintainers directly at their request, including unvalidated ones nearly 5,000
Critical and high-severity findings handed to experts for a sample check 97 across 48 projects
Of those, met the bar of the coordinated disclosure process 85, that is 88%

The post addresses the remaining 12 findings separately: 11 were real but duplicated known issues or other findings from the same scan, and only one turned out to be a false positive. The check was done by the experts who review the company's findings anyway, and only critical and high-severity findings went into the sample, so these 88% describe that sample specifically, not all of the scanner's reports.

Anthropic also refers to an academic benchmark called CyberGym: according to the company, language models have gone from finding under 20% of vulnerabilities at the beginning of last year to over 85% this year. That is one benchmark, and the reference to it comes from the interested party itself.

Why there is no human review in this stream

The company describes the bottleneck directly: there are far more findings than there are people able to check them. Out of over 29,000 candidate vulnerabilities, approximately 6,000 were reviewed manually, and beyond that, it says, the limit is human capacity.

At the same time, Anthropic writes, maintainers themselves ask for everything to be handed over, including unvalidated material: nearly 5,000 such reports have been sent to date. Hence the design of the new service. Human-verified disclosures continue through the previous coordinated vulnerability disclosure process, especially for projects that do not have the resources to triage reports themselves. OSS Scanner is an optional fast track for those who want findings as soon as they appear.

The price of that speed is named in the same paragraph: the output is fully model-generated, without human review or triage, which means reports may be incorrect or invalid. They are produced, the company says, by its strongest models, including Claude Mythos.

What the maintainers say

The post includes feedback from four projects that tested early versions of the service. Each piece of feedback is signed by a maintainer's name; here I give them by organisation, with a link to the post. These comments are published by an interested party, so they should be read as testimonials rather than as an independent assessment.

  • wolfSSL: of the 74 reports received, two turned out to be invalid, and five became CVEs, that is, entries in the public vulnerability catalogue. The patches attached to the reports, according to the feedback, slotted into the existing process for verifying and fixing issues.
  • OpenSSL: early AI reports about 18 months ago are called appalling, while Anthropic's reports, raw model output included, are rated as good as and sometimes better than what comes from people.
  • PostgreSQL: an unusually high fraction of the scanner's findings pointed to PostgreSQL defects, and several reports came with fixes that can be used nearly as they are.
  • HotCRP: the reports are described in the feedback as thorough and clear, with a strong understanding of the complex permission model in that system.

In the same place Anthropic gives the other side as well: some maintainers said that severity ratings can be inflated, or that the scanner misunderstood the project's threat model. The company writes that it cannot guarantee the scanner will be perfect and that it will keep refining it.

Who can join

Core maintainers of eligible projects can apply, that is, the people who run a project and are responsible for its code. This is done through a pull request to a repository on GitHub, following a standard template. A repository is the storage for a project's code, and a pull request is a proposed change to it which the owners of that storage accept or reject. The criteria are similar to those of OSS-Fuzz: a project should have, as the post puts it, critical importance to infrastructure and user security, and decisions are made case by case.

So this is not a service any project can walk into. Whether your open-source library fits the criterion of critical importance to infrastructure and user security cannot be worked out from the announcement in advance: Anthropic writes that it decides case by case.

Alongside this, Anthropic announced two more things: the Cyber Verification Program, which gives qualifying security professionals advanced capabilities and relaxed model safeguards, and Claude for OSS, with free Claude Max 20x subscriptions for remediating vulnerabilities in open-source projects.

What this means for a company that only uses libraries

If your website, application or internal service is built using open-source libraries (a web server, a database, an encryption library and other ready-made parts), what follows is about you. Which libraries you actually have in play and how many of them there are is something to find out from your developer, and if no such list exists, to compile. You have no direct part in the new service. But one thing in the announcement does concern you: according to Anthropic, exploits can now be developed in minutes, which means the speed of installing fixes is what counts. Whether more fixes themselves will be released in libraries is not something the announcement says, and I am not claiming it: one can only speculate about that based on the numbers of findings and reports sent.

Four steps that follow from this. Each is verifiable, and each has someone responsible.

  1. Know what your product is built from. You need a list of libraries and their versions, not the developer's memory.
    • Who does it: the developer or the contractor who builds your product.
    • How to check: ask for a list of libraries with versions as a file, and the date it was compiled. How exactly it is obtained depends on what your product is built with, and that is a question for the developer. If there is no list, that is the first task.
  2. Receive notifications about vulnerabilities in your libraries. Some of the platforms where code is stored have such warnings among their built-in features, and then they simply need to be turned on. If your platform does not have them, or your code is not on a platform, there is a second route: subscribe to vulnerability mailings from the libraries you use.
    • Who does it: whoever administers the code storage, together with whoever is responsible for updates.
    • How to check: name the person to whose address such letters come, and show the last warning received, with its date. An absence of letters over a month proves nothing in itself, and an ordinary test message does not prove that a vulnerability warning specifically will arrive: the reliable sign is a real warning that someone in the company has already received and worked through. If you have neither built-in warnings nor a library mailing, there is a temporary measure: once a month, go through your list of libraries and look at vulnerability notices in the public databases where such notices are collected, and record the date of the check. The limit of that measure is clear: between checks a critical finding will go unnoticed, so it is kept until notifications appear, not instead of them. For a critical finding the order is this: first assess whether your version is affected; then, if a fix has been released, test it on a test copy and install it out of turn. If there is no fix yet, or the test did not pass, the decision is taken by whoever is responsible for keeping your service running: usually it is a temporary measure, such as turning off the affected feature or closing external access to it until a fix appears.
  3. Agree on a deadline for critical updates. A fast fix is only of use when it reaches your server.
    • Who does it: you together with the developer, in writing, in the contract or in internal rules.
    • How to check: take the last critical library update and look through the change history to see how many days passed between its release and its installation at your end.
  4. Test updates on a copy, not on the live service. An update to a security library sometimes breaks how the application works.
    • Who does it: the developer.
    • How to check: there is a test copy, not reachable from the internet, the update is installed there first, and only after that does it go out to the live service.

Separately about reports: if you run an open-source project and have received a model-generated vulnerability report, it is worth treating it as a claim rather than a verdict. The announcement itself says that a report may be incorrect and a severity rating inflated. The reproducer from the report is run on a test copy, disconnected from the internet and from live data. If the flaw repeats, that is confirmation of reproducibility. How dangerous it is in your particular setting is a separate question: the scanner, as Anthropic writes, may misunderstand a project's threat model, so a security specialist assesses what the finding leads to. If the flaw does not repeat, the report is not closed either: conditions on a copy may differ from the live ones, and such a report goes to the same specialist.

What neural networks can actually do in break-ins and where they stumble, I went through in the article Can AI break into a server or a website. Cases where an AI agent works around the rules it was given have a separate piece: When an AI agent works around the rules.

What not to expect from this news

  • That open-source code will become secure. The service looks for vulnerabilities in individual projects that have applied. The announcement says nothing about the overall level of protection of open-source code.
  • That all reports are correct. The company itself writes that there is no human review in this stream and that reports may be incorrect or invalid.
  • That your project will be accepted. The selection criterion in the announcement is critical importance to infrastructure and user security, and the decision is made case by case.
  • That this replaces your own defences. A scan of someone else's library says nothing about your own code, your server settings and your employees' passwords.

In summary

On 8 October 2026 Anthropic launched OSS Scanner: opt-in, free scans of open-source projects by its strongest models, with reports that include a reproducer and sometimes a candidate patch. The price of the speed is stated plainly: a human does not check these reports, and some may be incorrect. By the company's numbers, over six months its models found over 29,000 candidate vulnerabilities, approximately 6,000 were reviewed manually, and in a sample check 85 of 97 critical and high-severity findings met the bar of its disclosure process. For a company that only uses libraries there is one practical conclusion: at the speed the company itself describes, the winner is whoever has the shortest path from a fix being released to it being installed on their own server.

I work on AI agents and automation. If you would like to look at my projects or discuss a task of your own, drop by the portfolio.

Sources