AI Made Finding Bugs Cheap. Fixing Them Is the New Bottleneck.

Anthropic's public ledger shows 217 fixes and 1,654 duplicates. The fix for open source isn't a better model. It's a better inbox.

Security teams spent twenty years wishing they could find bugs faster. That wish has been granted, and it turns out to be a strange gift.

Anthropic's own disclosure ledger, a public record its Frontier Red Team keeps of the bug reports it has committed to, showed 7,349 published entries in its November 2 snapshot. Of those, 217 are marked fixed. Another 1,654 are marked duplicate, and 419 were withdrawn (Anthropic ledger). Discovery has stopped being the slow part. The slow part is a person reading the report and deciding what to do with it.

This means the question every open source maintainer, and every team pointing an AI scanner at someone else's code, should ask has changed. It used to be "how many bugs can we find?" Now it is "how many fixes do we get per hour of a human's attention?" The answer is intake control: a severity floor, a pause switch, and a rule that every report arrives with proof. Those tools already exist. Most people haven't switched them on.

What the numbers actually say

Some background first. Project Glasswing is Anthropic's effort, launched April 7, 2026, to use its strongest models to find vulnerabilities in widely used software (Anthropic). Its open source arm is OSS Scanner, a free service that sends model-written bug reports straight to project maintainers (Anthropic research).

On November 9, Patrick Garrity of VulnCheck, a vulnerability intelligence company, published a tally of what all that scanning has produced. He counts 442 CVEs (the public IDs assigned to confirmed vulnerabilities) attributable to Anthropic this year, about 0.5% of the 93,450 CVEs published so far, and two of them are already exploited in the wild (VulnCheck). By his reading, only 7,349 of the 37,966 findings Anthropic reports have been made public.

The most useful data point comes from curl, the widely used command-line tool and library for moving data over the internet. According to Garrity's summary of a post by curl maintainer Daniel Stenberg, curl has published 34 of its Glasswing reports. Nineteen were "not a vulnerability." Six were confirmed low severity. Nine were still waiting for assessment. Stenberg is pacing the reports, in Garrity's words, "to soften the impact for the team."

Now hold that against Anthropic's own numbers. When Anthropic launched OSS Scanner on October 8, it said its models had found over 29,000 candidate vulnerabilities, about 6,000 had been reviewed by people, and in a validation set of 97 critical and high severity findings across 48 projects, 85 (88%) met the bar for coordinated vulnerability disclosure (CVD, the standard practice of telling maintainers privately and giving them time to fix before going public) (Anthropic research). The post also quotes wolfSSL's Todd Ouska: of 74 reports his project received, "all but two were valid."

Both sets of numbers can be true at once. Anthropic's 88% comes from critical and high findings. curl's pile was almost all low severity: per Garrity, Anthropic rated one of the 45 reports curl received as medium and the rest as low. A low-severity finding can be technically correct and still not worth an afternoon of a volunteer's time.

Be careful with the critic, too

Garrity is not a neutral narrator. His headline calls the findings "underwhelming," and his post has rough edges. His text says 1,654 duplicates while his own table says 1,670. He suspects a bug in Anthropic's ledger inflates the "disclosed" count, and he invites readers to check it themselves. He also writes, plainly, that AI "is a valuable tool for finding vulnerabilities."

So don't read this as "AI bug hunting is broken." Read it as a capacity problem. Anthropic says so itself, in the launch post: "While 6,000 vulnerabilities is significant, we remain bottlenecked on our human capacity to validate these findings." And the same post says the OSS Scanner reports "will be fully model-generated, without human review or triage."

That sentence is the whole story. The triage step that used to happen at the sender now happens at the receiver. For a big company with a security team, that's a cost. For a project run by three volunteers, it can be the week.

The shift: from finding bugs to filtering them

Here is the mental model worth keeping.

Think of AI vulnerability reports like a firehose pointed at a garden. More water is good, up to the point where the garden floods. Nobody fixes that by asking for a weaker hose. You fit a valve.

For security reports, the valve is intake control: rules about what reaches a human, when, and in what shape. Three of them do most of the work.

A severity floor. Only reports at or above a chosen severity reach a person right away. Everything else waits in a queue you review on your schedule.
A pause switch. When a release is shipping or the team is out, reports stop arriving without you leaving the program.
A shape requirement. A report must arrive with a working reproducer (a small script that triggers the bug) and, ideally, a candidate patch. If it can't be reproduced, it doesn't take priority.

None of this is new to security people. What's new is that the volume makes it mandatory, and that the AI vendors are starting to ship these valves themselves.

Put this into practice: if you maintain open source

Read OSS Scanner's config before you enroll, or before you complain. OSS Scanner enrollment happens through a pull request to the anthropics/oss-scanner repo, which is Apache-2.0 licensed. You add a folder under projects/<name>/ with a project.yaml file. Two keys are required, repo and primary_contact, and your project also needs a Dockerfile so the scanner can build it (README). Eligibility is decided case by case, aimed at projects with "critical impact on infrastructure and user security," so enrolling is a request, not a guarantee of scans or reports.

The controls that matter live in that same file:

repo: https://github.com/your-org/your-project
primary_contact: security@your-project.org
disabled: true   # pauses reports without removing the enrollment

The README also documents an output_format setting with a minimum severity per delivery channel (low, medium, high, critical, or none, where none switches that channel off), and a report that clears both thresholds goes to both channels. Email defaults to low, which means everything, so raise it if your team is small. GitHub security advisory delivery is off by default and only works if you turn on private vulnerability reporting and add the oss-scanner account as a trusted reporter (an account GitHub lets file private security reports to your repo). One more thing before you commit the file: the README warns that email addresses in project.yaml are public, so use a project alias, not a personal inbox. Using the hosted service also means agreeing to Anthropic's separate OSS Scanner terms, linked from the README. The README also lists optional threat_model, report_guidelines and patch_guidelines keys. Fill those in. A scanner that knows what your project considers out of scope sends fewer reports you'll reject.

To check your entry before opening the PR, the repo includes local validation:

pip install pyyaml
python3 tools/validate.py
tools/check <name>

Expect it to need git, Docker and Python 3, and tools/check --qemu needs Linux on x86-64.

Write a report policy, even a short one. curl's vulnerability disclosure page is a good model. It asks reporters to "explain your issues or improvements briefly and clearly in your own human voice" and not to "lazily paste massive, AI-generated explanations." It also states that every report, valid or not, gets made public once handled. That last rule is quiet pressure on senders: a junk report becomes a public junk report.

Some projects have gone further. The "Open Source Says No" tracker lists 22 projects that ban or restrict AI-generated contributions, including QEMU, the open source machine emulator, which will "DECLINE any contributions which are believed to include or derive from AI generated content" (osssaysno.com). That is a blunt valve. It works, at the cost of also turning away good reports.

Count the right thing. Keep a simple tally per month: reports received, hours spent, fixes shipped. If fixes per hour is falling, tighten the severity floor. If it's rising, you can afford more.

Put this into practice: if you run an AI scanner

Plenty of teams now point Claude, Codex or a homegrown agent at dependencies they rely on. Before you file anything upstream:

Triage your own output. Run the reproducer yourself. If you can't trigger it, don't send it.
Search for duplicates. Check the project's issue tracker and advisories first. Anthropic's ledger marks 1,654 entries duplicate. Yours shouldn't add to that.
Send the shape maintainers can act on. Anthropic's reports include "a self-contained reproducer, explanation of the vulnerability (including a bisection to determine when the bug was introduced, where possible), and candidate patch (when available)." Bisection means finding the exact commit that introduced the bug. That's a good minimum for anyone's reports.
Rate-limit yourself. Batch low-severity findings into one message instead of twenty. Respect whatever the project's policy says.
Write it like a person. Short, specific, in your own words. curl's policy says as much, and most maintainers feel the same.

The goal is simple. Every report you send should cost the maintainer less time than it saves them.

Honest limitations

This framing has holes, and you should know where they are.

The headline numbers come from a critic and a vendor, and they don't line up cleanly. VulnCheck's total of 37,966 findings doesn't appear on the ledger page itself, and Garrity flags his own suspicion that the ledger's "disclosed" count is off. Anthropic's 88% validation figure covers a curated set of critical and high findings, not the whole stream.

curl is one project. It is also unusually well run, with strict policies and a maintainer who publishes everything. A smaller project might see a better hit rate, or a much worse one, and nobody has published that comparison.

Severity floors cut both ways. A low-severity bug today can chain with another bug into something serious tomorrow. Raising the floor protects your time at the cost of some risk, and that's a judgment call only you can make.

And the fix count is lagging by nature. A finding filed in October might be fixed in January. The 217 will grow. The question is whether it grows as fast as the queue.

What to do this week

If you maintain a project that's enrolled in OSS Scanner, open your project.yaml and check your severity settings and your pause switch. If you're not enrolled, read the README before deciding. If you run a scanner of your own, add a "reproduce it yourself" step before anything leaves your machine.

Finding bugs has gotten cheap. A maintainer's afternoon hasn't. Spend it where it buys a fix.

Sources: Anthropic disclosure ledger, Nov 2, 2026 snapshot; VulnCheck, "After 7-months, Glasswing Overwelms Maintainers with Underwhelming Findings," Nov 9, 2026; Anthropic, OSS Scanner launch post, Oct 8, 2026; anthropics/oss-scanner README, main branch as of Nov 11, 2026; Anthropic, Project Glasswing; curl vulnerability disclosure policy; Open Source Says No.