Anthropic's OSS Scanner and Bitcoin Core's dilemma: AI vulnerability discovery just got institutional

Two announcements this month mark the point where AI-assisted vulnerability discovery stopped being an experiment and became infrastructure. Anthropic launched OSS Scanner (October 8), offering free periodic scans of open-source projects by its strongest models with reports generated end-to-end without human triage. Two days later, Bitcoin Core opened issue #36493 debating whether to enroll — a discussion that became the clearest public articulation yet of why automated AI-scanning programs collide with legacy embargo calendars.

The numbers behind the launch

From Anthropic's announcement and pilot feedback, published October 8:

• 29,000+ candidate vulnerabilities discovered in the last six months across major projects; humans triaged ~6,000
• ~5,000 unvalidated reports sent directly to maintainers who asked for bulk submissions
• Validation quality: of 97 critical/high findings reviewed by expert pentesters across 48 projects, 88% met the CVD bar; exactly one was a false positive
• Maintainer quotes: wolfSSL received 74 reports, "all but two were valid, and five became CVEs"; curl's Daniel Stenberg credits it with "one of the worst curl vulnerabilities reported in the last few years"
• The capability trendline: on CyberGym, LLMs went from finding under 20% of vulnerabilities early last year to over 85% this year

Read those together and the "LLM security reports are slop" era is formally over. The bottleneck has moved from finding to triaging — which is why Anthropic is offloading unvalidated bulk reports to projects that ask for them.

The Bitcoin Core dilemma, precisely

A maintainer opened the discussion on October 10 with an unusually careful framing. Bitcoin Core is already being scanned by external AI efforts (Project Loupe's automated scanner and the informal "Bitcoin Red Team"), and the maintainer explicitly notes he cannot assess their impact because he is not on the receiving end of those reports.

The sticking point with joining OSS Scanner is disclosure policy. Bitcoin Core's current policy: medium and high severity vulnerabilities are disclosed two weeks after the last affected release goes end-of-life — roughly a year after the fix first ships. Anthropic's CVD: 90 days from validation, compressing to a 7-day target when a vulnerability is actively exploited, with 45 days from patch to full technical details.

Both positions reflect their operational history. A year-long embargo made sense when peer-to-peer node upgrades took quarters and exploit development was the expensive bottleneck. When exploit chains can be built in hours and a frontier model adapts them across memory layouts the same day, a year-long embargo leaves unpatched operators exposed to attackers who rediscover the bug independently — which, per Cloudflare's network telemetry, increasingly happens before official advisories drop.

The two policies, side by side:

The last row is the quietly radical part: OSS Scanner offers a stream of unvalidated, model-generated vulnerability reports, with no embargo clock running unless a human later validates one. Bitcoin Core's whole policy architecture assumes every report a maintainer receives deserves an embargo. Those two governance models collide directly — which is why the maintainer's conclusion focuses on process compatibility rather than scanner quality.

Worth calibrating against the social-media version of this story: framing it as "Bitcoin Core changed its disclosure policy because of AI" overstates it. The SECURITY.md update is unmerged, the issue is open, and the maintainer's stated position is that AI scanning as a whole is "a nuanced topic" he deliberately stays out of. What actually happened: the flagship Bitcoin project is publicly weighing whether frontier-model scanning is worth adopting a foreign disclosure timeline. That is more interesting than the headline.

What an OSS Scanner report contains

Each report is self-contained, which is why the pilot validation rate held up: a reproducer, an explanation of the vulnerability including a bisection to when it was introduced where possible, and a candidate patch when available. The pilot disclosures chained multiple bugs into unauthenticated RCE exploits against participating projects. Early adopters' assessments, from the announcement:

• PostgreSQL (Noah Misch): "an unusually high fraction of findings uncovered PostgreSQL defects; several reports came with fixes we can use nearly as-is"
• OpenSSL Corporation (Anton Arapov): early AI reports 18 months ago were "appalling"; the recent ones were "as good and sometimes better than what we get from people"
• wolfSSL (Todd Ouska): 74 reports, all but two valid, five became CVEs
• curl (Daniel Stenberg): helped find "one of the worst curl vulnerabilities reported in the last few years"

The OpenSSL quote captures the trajectory in one sentence. The 2024-era complaint about AI security reports was noise volume; the 2026 operational question is which disclosure calendar to adopt. The underlying capability crossed from pattern-matching known bug classes to synthesizing multi-step exploit chains — the same shift Wiz demonstrated in finding PHP2Shell against a decade of core PHP code.

What it means for red-team operators

One: the discovery half of your job is being productized. Free, opt-in, strongest-model scanning for critical infrastructure projects. If your value proposition is "we run an LLM against your repo and report CVEs", the commodity wave is arriving. The durable work is on the other side: triage, reachability analysis in your codebase, and adversarial testing of systems that don't enroll in scanners — internal tools, multi-agent pipelines, anything with a trust boundary.

Two: disclosure timelines are converging on attacker speed. Seven-day targets for actively exploited bugs and 45-day detail publication after patch are becoming the baseline. If your remediation SLA assumes a multi-quarter calendar, the window has compressed. The php2shell exploitation curve (thousands of exploitation attempts before public announcement and millions within days) shows what that compressed timeline looks like on the wire.

Three: automated triage is the capability to build now. Anthropic's own bottleneck is human triage capacity (6,000 of 29,000 candidates reviewed). Maintainers and security teams need their own machine-triage pipeline: normalize bulk findings on unst33r-flash, verify reachable call paths and candidate patches on unst33r-deepseek, and route only verified clusters to human engineers. See our worked guide to triaging 5,000 bulk vulnerability reports for about $50 and the cve.now MCP triage workflow for copy-pasteable implementations, or check tier pricing to estimate batch costs.

Four: if you maintain an eligible open-source project, enrollment hinges on governance fit. The pilot validation data (88% on critical/high findings) settles the capability question. The practical governance question is whether your release engineering can support a 90-day (or 7-day active-exploitation) disclosure clock on validated findings when downstream users expect a longer upgrade window. Read the OSS Scanner FAQ and terms alongside your project's SECURITY.md before opening an enrollment PR. Bitcoin Core's issue thread is the best public worked example of that trade-off analysis.

Method note

All figures above come directly from the two primary sources linked at the top (Anthropic's October 8 announcement and Bitcoin Core issue #36493 opened October 10), rather than secondary social-media summaries that conflated an open governance discussion with a merged policy change.

AI-assisted vulnerability discovery and triage remain subject to explicit authorization — ours is governed by the acceptable-use policy, and the same boundary applies to every automated scanner in your pipeline.