Bug Bounty

Anthropic opens fast lane for unreviewed AI bug reports to open source

Anthropic’s OSS Scanner sends unreviewed AI vulnerability reports straight to open-source maintainers. What it means for disclosure and UK patching.

Illustration of a bug icon over code representing AI-generated vulnerability reports sent to open-source maintainers

Anthropic has launched OSS Scanner, a free opt-in service that sends raw, machine-generated vulnerability reports straight to open-source maintainers without any human checking them first. It changes how disclosure works for the code UK organisations depend on, and it moves the triage burden squarely onto the projects themselves.

What happened

On 8 October 2026 Anthropic announced OSS Scanner, a programme that runs periodic security audits of enrolled open-source projects using its most capable models, Claude Mythos among them, at no cost to the project. The headline difference from conventional disclosure is that output from the scanner is entirely model-generated. Nobody at Anthropic reviews or triages a finding before it lands in a maintainer’s inbox.

The company frames this as an optional fast track sitting alongside its existing coordinated vulnerability disclosure (CVD) process, which will keep handling human-verified reports, particularly for projects without the people to sift findings themselves. The reasoning is capacity. Anthropic says six months of scanning major projects produced more than 29,000 candidate vulnerabilities, of which its staff have managed to review roughly 6,000. Many maintainers, it says, had already asked for everything in bulk, validated or not, and nearly 5,000 such reports have gone out on that basis. The Hacker News reported that 584 advisories had resulted as of 2 October, and that 116 enrolment requests had been submitted by the time it published.

The launch arrived barely a week after Google stopped paying for product vulnerability reports in its Open Source Software Vulnerability Reward Program (OSS VRP), citing a rise in automated submissions that were mostly invalid. Two major players have reached opposite conclusions about machine-found bugs within a fortnight.

How it works

Enrolment is deliberately narrow. Core maintainers open a pull request against Anthropic’s oss-scanner repository on GitHub, supplying a configuration file that points to a Dockerfile. That container must build the project and install its dependencies, because the auditing agent works without internet access. Maintainers can optionally add a threat model file describing what should be tested, which inputs count as hostile and how severity should be judged. Eligibility follows criteria similar to Google’s OSS-Fuzz: the project needs a significant bearing on infrastructure and user security, and Anthropic decides case by case.

Each report carries a self-contained reproducer, an explanation of the flaw, a bisection showing when it was introduced where that is possible, and often a candidate patch. According to Help Net Security, the first scan produces a bundle of reports by email, later scans hunt for newly introduced issues, and projects can pause the feed or drop back to standard CVD at any time.

The disclosure terms are the part researchers will scrutinise. Unvalidated findings carry no 90-day deadline. If a human later confirms one through the CVD route, a 90-day clock may start when the maintainer is told of that validation. Anthropic has signalled it could impose deadlines on some high-severity reports once it trusts the pipeline more.

On accuracy, Anthropic says its expert penetration testers checked 97 critical and high-severity findings across 48 projects: 85 met its CVD bar, 11 were genuine but duplicates, and one was a false positive. It concedes that severity can be overstated and that the model sometimes misreads a project’s threat model. Feedback quoted from wolfSSL, PostgreSQL, OpenSSL and curl is broadly positive.

Key figures for Anthropic's OSS Scanner: 29,000 candidate vulnerabilities, about 6,000 reviewed, nearly 5,000 unverified reports sent, 584 advisories, 85 of 97 sampled findings valid for disclosure

Why it matters for UK organisations

Almost every UK business runs open-source components it did not write and does not monitor closely: TLS libraries, databases, HTTP clients and language runtimes buried inside commercial products and internal applications. When the rate of discovery in those components jumps, the knock-on effect reaches UK patch queues within weeks, whether or not anyone in the organisation has heard of OSS Scanner.

There is also an uncomfortable asymmetry. Anthropic itself notes that exploits can now be written in minutes. If well-resourced projects such as PostgreSQL or curl absorb a high volume of findings and ship fixes quickly, the published patches become a map for attackers, and the window between upstream fix and exploitation shrinks. Slow patchers will feel that most.

Smaller projects are the other concern. Anthropic says the fast track suits teams that can already keep pace with verified reports. Many critical libraries are maintained by one or two volunteers, and those are exactly the projects UK firms tend to forget sit in their dependency trees. The Google pause shows what happens when volume outstrips triage capacity.

Expert view

In my experience, the hardest part of any vulnerability programme has never been finding bugs. It is deciding which ones matter, in what order, and who fixes them. OSS Scanner is a candid admission that machine discovery has overtaken human validation, and rather than hold findings back, Anthropic is passing the triage job to the people best placed to judge their own code. That is defensible for a mature project with a security team. It is a heavy ask for a volunteer.

The quality figures are notably better than the low-grade automated output that pushed Google to suspend rewards, and the inclusion of reproducers and patches matters enormously. When we test, a finding with a working proof of concept is resolved in a fraction of the time of a vague description. Still, the 97-finding sample was drawn from critical and high-severity results, and the real test will be the noise level across lower-severity reports at scale.

The absence of a fixed disclosure deadline for unreviewed findings is sensible, but it creates ambiguity. Maintainers will sit on reports of uncertain validity with no public timetable, while others may be finding the same bugs. For the bug bounty community, the bigger question is economic: if vendors can scan their own dependencies for free, rewards for routine memory-safety and logic flaws in open source are likely to fall further, and human researchers will need to compete on depth, chaining and business logic rather than volume.

What to do now

  1. Know what you run. Maintain a software bill of materials for key applications to match upstream advisories to your estate. This underpins the Cyber Essentials security update management control.
  2. Shorten library patch cycles. Treat high-severity fixes in widely used open-source components within the 14-day window Cyber Essentials sets for high and critical updates, and ask suppliers how fast they pull upstream fixes.
  3. Watch the busy projects. Subscribe to security advisories for the major libraries in your stack, since a rise in fixes is likely where scanning is heaviest.
  4. If you maintain open source, enrol only if you have triage capacity, write a clear threat model file, and keep a documented process for rejecting invalid findings.
  5. Review your own disclosure policy. Decide how you will handle AI-generated reports to your vulnerability disclosure programme, including proof-of-concept requirements, before volume forces the decision.
  6. Support your dependencies. Where a small project is critical to your business, consider funding or contributing engineering time to its security work.

Bottom line

OSS Scanner marks a shift from AI-assisted disclosure to AI-originated disclosure, with humans moved to the receiving end. Early results look strong, but the cost is a heavier triage load on maintainers and faster patch churn downstream. UK organisations should assume more open-source fixes are coming, and get quicker at applying them.

Sources