The Algorithmic Siege: Defending Open Source Against AI-Discovered Vulnerabilities

Open source has always counted on its readers outnumbering its attackers. The next sections show why that count no longer holds, follow a report from the scanner that files it to the maintainer who has to read it, and then turn to the defenses that can keep up.

01 Linus's Law, Reversed

Eric Raymond's The Cathedral and the Bazaar (Raymond, 1999) gave open source its founding security assumption: given enough eyeballs, all bugs are shallow. For three decades, that arithmetic favored the defense.

A vulnerability was a latent defect waiting to be found by a large, benevolent crowd of developers, administrators, and researchers whose combined attention would outpace the fragmented efforts of attackers.

Researchers have put numbers to that claim. Alhazmi and Malaiya fitted discovery curves to operating systems and servers, relating cumulative reported vulnerabilities to time in the field and to usage, which turns the number of undiscovered bugs into something you can extrapolate from (Alhazmi & Malaiya, 2005). Ozment and Schechter asked the harder question of whether age makes code safer. Across 7.5 years and 15 OpenBSD releases (Figure 1), the reporting rate for foundational vulnerabilities did fall, but only slowly: the median lifetime of one is at least 2.6 years, and 62% of all the vulnerabilities reported were already present when the study began (Ozment & Schechter, 2006).

Both are measurements of a human-paced process, and both were read as good news about it. Neither says what happens when the same curves are refitted to a search that never sleeps or tires.

Those curves describe a world that no longer exists. The eyeballs are no longer all biological, and they are no longer evenly split between defenders and adversaries. Large language models, agentic reasoning loops, neuro-symbolic program analysis, and AI-directed fuzzing now find bugs at machine speed. Anderson's classic argument that security failures are largely economic (Anderson, 2001) applies with full force: the economics of discovery have been inverted.

OpenSSF and CNCF concede the flip in their own maintainer guidance: the ecosystem finally has the "multiple eyes" Linus's Law promised, except that a dozen of them find the same bug at the same time and file it separately, which creates useless duplicates and doesn't improve safety (Aniszczyk et al., 2026).

The first defections from that assumption are commercial rather than ideological. In April 2026 Cal.com closed the source of its production codebase after five years under AGPL-3.0 and moved to a proprietary license.

A month later, NHS England went the other way, and harder. Internal guidance reported by The Register and codified as "SDLC-8" ordered the health service's technology leads to set its GitHub repositories from public to private by May 11, on the grounds that public repositories "materially increase the risk of unintended disclosure of source code, architectural decisions, configuration detail, and contextual information that may be exploited," particularly given frontier models like Anthropic's Mythos that can ingest and reason over code at scale.

Repositories were to stay private "unless there is an explicit and exceptional need." The organization's own service standard says the opposite: new source code for public services should be open and reusable, because "public services are built with public money" (The Register, 2026a).

Is retreating behind a private repository even the right move, or just the most visible one?

NHS England called the move temporary, to be revisited while it assesses the impact of AI models, and said it would still publish code "where there is a clear need." By early May, an open letter was pressing it to keep the repositories open (FSFE, 2026).

The UK government's own digital and science departments came down against closure in guidance published that May: code stays open by default, and a private repository needs a short, time-bound threat model, because privacy is not a mitigation for missing patching capacity (GDS & DSIT, 2026).

What closing the source buys is the contested part. It does not close the binary, and Anthropic reports that Mythos Preview can (1) take a stripped closed-source binary, (2) reconstruct plausible source code from it, and (3) find exploitable vulnerabilities in that code (Anthropic, 2026a), so the move may withdraw the audit without withdrawing the scanner's ability to scan.

The counterargument is that the economics now run the other way: if finding an exploit is a matter of spending tokens, open code lets every user share one auditing budget that closed code must fund alone, which is Linus's Law restated for rented eyeballs, given enough tokens, all bugs are shallow. Drew Breunig states the equation bluntly: "to harden a system you need to spend more tokens discovering exploits than attackers will spend exploiting them" (The Register, 2026b). The two readings agree on the one thing that changed: the crowd that reads open code is no longer reliably on the defense's side.

Put together, the argument of this post fits on one page: the economics tilt toward the attacker, and the defense has to be automated end to end.

The sections below take the argument in turn, starting with the arithmetic that now favors the attacker.

02 The Asymmetric Siege

Historically, finding a non-trivial vulnerability, such as a race condition in the kernel's memory subsystem or a logic flaw spanning several layers of an HTTP/2 parser, took world-class expertise. A researcher spent weeks decompiling binaries, building mental models of state machines, and hand-tuning fuzzers with custom input dictionaries. Discovery was an art form limited by human bandwidth, fatigue, and scarcity of talent. The table below contrasts that regime with the one that is arriving.

Machines That Reason About Code

Models trained on large corpora of source code, patch histories, commit messages, and weakness enumerations (CWEs) do not read code linearly. They build semantic representations of execution paths, taint flows, and control-flow graphs.

Coupled with reinforcement learning and sandbox feedback, as in Google's Project Naptime (later Big Sleep) and DARPA's multi-year AI Cyber Challenge (DARPA, 2023–2025), these systems do more than match known bug patterns. They (1) reason through dynamic state spaces, (2) hypothesize exploitation invariants, (3) synthesize inputs that get past sanitization, and (4) emit deterministic proof-of-concept exploits without human help.

The same architecture is what the defense side has to run to keep pace. Microsoft's MDASH, a multi-model agentic scanning harness of more than a hundred specialized agents drawn from an ensemble of frontier and distilled models, splits the work between auditor agents that propose findings, debater agents that try to refute them, and a proof stage that has to execute a triggering input before a finding counts.

Against five years of confirmed Microsoft Security Response Center cases it recovered 96% of them in clfs.sys and 100% in tcpip.sys, and its May 2026 Patch Tuesday cohort carried sixteen previously unknown vulnerabilities across the Windows networking and authentication stack, four of them Critical remote-code-execution flaws (Microsoft Security Blog, 2026).

Nor does discovery require a frontier model. In a Cisco comparison I cover in a separate post on small language models, a 3-billion-parameter model localized a disclosed flaw in an unfamiliar codebase in 14 terminal calls, while a model reportedly thousands of times larger ran out of budget one layer short. That makes the cost floor lower still: the attacker's scanner can run cheaply and locally, with no API quota to throttle it and no vendor to refuse the request.

The Three-Part Asymmetry

Offense and defense now run on the same kind of machinery, but only one side pays for it in human time. The result is a three-part economic asymmetry in the open source supply chain:

• Cheap discovery: the marginal cost of scanning a million lines for zero-days has fallen from months of dedicated security engineering to dollars per finding in the cheapest reported cases.
• Expensive triage: the cost for an unpaid maintainer to review, verify, and safely remediate one report is still bound by human cognition: hours or days of focused work per valid report.
• Unbounded scale: one threat actor, bounty farmer, or state-sponsored unit can deploy thousands of agents across GitHub, GitLab, crates.io, PyPI, and npm at once, while individual projects rely on small, often solitary maintainers working in their spare time.

Small models make all three legs worse at once. If discovery needed a frontier model, the attacker would pay per token, queue behind a vendor's rate limits, and risk a refusal or an account ban. A small model on commodity hardware has none of those brakes, so the cost floor drops, the number of actors who can afford to scan rises, and the volume of reports that lands on a maintainer's desk grows with both. The defender's side of the ledger does not move: a human still has to read every one.

What the Numbers Show

The numbers are now measured, with a caveat about what each one counts. A working proof-of-concept for a published CVE takes an agent ten to fifteen minutes and roughly a dollar of inference, and one reproduction framework averages $2.77 per CVE at a 51% success rate (Cloud Security Alliance, 2026a). That is n-day reproduction: the vulnerability is already public, with a CVE entry and usually a patch, and the agent's job is to turn the description into a working exploit. It is not discovery, which means finding a flaw nobody has reported (a zero-day, or 0-day). The figure shows how cheap exploitation has become once a bug is known, not how cheap it is to find new ones.

It still matters here, because every unpatched downstream project is exposed in the window between disclosure and update.

• Heelan: agents generated forty working exploits against a single QuickJS zero-day across six mitigation scenarios, the hardest run costing about fifty dollars, on a target far smaller than a browser engine (Heelan, 2026).
• Dinkin and Kraft: a kernel-driver swarm flagged 521 candidate vulnerabilities, about a hundred of which survived manual triage as exploitable, at roughly four dollars per exploitable bug and $600 in total, a figure that leaves out the human triage (Dinkin & Kraft, 2026).

Figure 4 puts those three figures on one linear scale, where the first two barely register next to the third, but they measure different things.

Where researchers measured the capability itself, it improved just as fast. In DARPA's AI Cyber Challenge, the autonomous systems found 37% of the planted vulnerabilities at the 2024 semifinals and 86% at the 2025 finals (DARPA, 2023–2025), a gain of nearly fifty points in a single year. Finding bugs got that much better in twelve months, while fixing and reviewing them still takes the same hours of human maintainer time.

The economics behind that gap are older than the models. As early as 2002, Gordon and Loeb modelled security investment as a function of how much vulnerability information a defender holds, and showed that optimal spending never approaches full protection: past a point, an extra dollar buys less exposure reduction than it costs (Gordon & Loeb, 2002).

The same human validation bottleneck shows up across AI usage generally, not just in security. Catalini, Hui, and Wu model the transition as a collision between a Cost to Automate decaying exponentially and a Cost to Verify bounded by biology, concluding that the binding constraint stops being intelligence and becomes verification bandwidth (Catalini et al., 2026). Machine search moves the first curve. The second is still measured in maintainer hours, which is the whole problem.

The same two clocks run on the enterprise side of the supply chain. Figure 5 plots them together. J.P. Morgan's Patchmageddon report has attacker time-to-exploit falling to about a day while enterprise remediation drifts past ninety days, and in roughly 60% of breaches a vendor patch already existed at the moment of compromise. This blog's reading of that report draws the other lesson from the same data: fewer than 2% of disclosed vulnerabilities ever drive real-world risk, so the answer is prioritizing the reachable few, not patching everything faster. Maintainers face the same problem from the other end, since an unfiltered report queue gives no sign of which report is the one that matters.

This is an algorithmic siege. Projects are facing more than a rise in report volume; the way vulnerabilities are surfaced, reported, and weaponized has changed qualitatively. The workflows that sustained open source security for a quarter century, ad hoc security email aliases, manual bug trackers, informal peer review, and human-mediated CVE assignment, are failing under the load.

Imploring volunteers to work faster will not fix that. It takes automated defensive tooling, verification gates, architectural memory safety, institutional compute subsidies, and an overhaul of the disclosure ecosystem.

03 Anatomy of the Onslaught

To mount a defense, communities first need to understand how modern automated discovery works. Early machine learning for static analysis relied on shallow pattern matching: searching for banned C calls like strcpy() and gets(), matching regular expressions against syntax trees, or computing token-level similarity against vulnerability databases. Those tools had enormous false-positive rates and no semantic grasp of program logic. The current wave converges four distinct methodologies, shown in the figure below and taken in turn in this section.

Semantic Program Comprehension and Taint Modeling

Modern foundation models treat source code as a structured, executable medium rather than as text. Working over unified representations that combine abstract syntax trees, control-flow graphs, and program dependence graphs, they can trace data flows across translation units and architectural boundaries.

Consider an asynchronous C++ network service. A traditional analyzer may miss an uninitialized or dangling access when a pointer passes through template wrappers, sits in an event-loop context, and is dereferenced in a lambda on another thread. An LLM-driven agent can infer the developer's implicit assumptions instead.

// Subtly flawed asynchronous context hand-off
void Session::on_packet_received(const uint8_t* data, size_t len) {
    auto ctx = std::make_shared<RequestContext>(data, len);

    // the agent traces object lifetimes across dispatch queues
    EventLoop::get_current()->post_task([ctx]() {
        if (!ctx->validate_header()) {
            // implicit assumption: ctx is safely dropped here
            Logger::log_error(ctx->get_id());
            return;
        }
        process_payload(ctx->get_buffer());
    });
}

Suppose RequestContext keeps the raw data pointer instead of copying the bytes. The agent connects three facts: the buffer's lifetime, the asynchronous scheduling mechanism, and the logging subsystem. It then flags the scenario in which an early socket close invalidates the transport's memory while the queued task still reads from it. Spotting that needs a mental model of how APIs tend to be misused, which the model gets from its training data, not from a rule.

Neural-Augmented Dynamic Fuzzing

Reading code finds candidates; running it tests them. Fuzz testing has been the most effective dynamic technique for finding memory corruption in C and C++ (Zalewski, 2014; Fioraldi et al., 2020). Conventional coverage-guided fuzzers such as AFL++, LibFuzzer, and Honggfuzz hit two structural bottlenecks.

1. Harness scarcity: a fuzzer needs an entry-point driver that maps raw bytes onto a target API's types and state sequences. Writing robust, fast harnesses for deep library internals takes real manual effort.
2. The roadblock problem: mutation engines flip bits and splice bytes at random. Against cryptographic handshakes, checksummed packets, compressed streams, or nested JSON and XML, random mutations fail basic parsing validation and strand the fuzzer at the outer perimeter of the codebase.

AI systems break both. Tools built for DARPA's AI Cyber Challenge use LLM agents to read library source, analyze public API contracts, and synthesize hundreds of syntactically valid, high-coverage harnesses. Generative models also act as grammar-aware seed generators.

When the fuzzer hits a checksum or a complex parser, an agent reads the validation function, infers the structural invariants it enforces, and generates seed inputs that pass it. The coverage engine can then reach execution states that previously required human guidance. I take the idea further in a separate post on neurosymbolic auditing, where the model writes down the invariants it is relying on and the fuzzer then tests those assumptions directly.

Agentic Reasoning and Hypothesis Refinement

Comprehension and fuzzing are components, and the real leap comes from wrapping them in agentic loops instead of single-prompt queries. An offensive agent is not an LLM asked to "find bugs." It is an iterative, tool-using loop equipped with a compiler and build system (Make, CMake, Ninja, Cargo), a debugger and instrumentation framework (GDB, LLDB, Valgrind, AddressSanitizer), a terminal to run commands and read core dumps, and a code-search index for finding references and tracing symbols.

When such an agent spots suspicious pointer manipulation, it does not stop at flagging the line. It writes a small reproduction, compiles it with AddressSanitizer (Serebryany et al., 2012), runs it, and reads the report:

==184920==ERROR: AddressSanitizer: heap-use-after-free
    on address 0x603000000048
    at pc 0x000000517823 bp 0x7fff5c0d29b0 sp 0x7fff5c0d29a8
READ of size 8 at 0x603000000048 thread T0
    #0 0x517822 in parse_extensions /src/libnetwork/src/parser.c:412:12
    #1 0x519d14 in process_handshake /src/libnetwork/src/handshake.c:89:5
    #2 0x515108 in main /src/repro.c:24:5

If the run does not crash, the agent keeps the hypothesis alive. It reads the output, adjusts the memory layout in its script, changes input lengths, recomputes struct alignment offsets, and runs again. That cycle of hypothesize, compile, execute, observe, refine mirrors the workflow of an elite human exploit developer, but it runs at machine speed, around the clock, across thousands of repositories at once.

The same execution filter works on the defense side. Microsoft's MDASH, described in its launch post, counts a finding only once a triggering input has run, so a crash is the filter and a plausible-sounding report is not enough. The last subsection returns to how it does that.

Automated Exploit Generation

The end point of this capability is automated exploit synthesis. For infrastructure software, finding a memory fault is only the first step. Whether the flaw is an existential threat or a minor denial of service depends on turning it into a controlled primitive: arbitrary read or write, control-flow hijacking, or an authentication bypass.

Offensive frameworks pair constraint solvers such as Z3 with generative models to solve complex path conditions. Given an out-of-bounds heap write, an agent can analyze adjacent allocations, model the target's allocator (glibc ptmalloc, musl, jemalloc), and construct the allocation and deallocation sequence, known as heap feng shui, that places a function pointer or vtable next to the overflowing buffer.

Production systems wrap these steps in a pipeline rather than a single prompt. MDASH is a defensive system, but its stages are the ones an offensive harness needs. Its prove stage constructs triggering inputs wherever the bug class admits it, and a dynamic run confirms the precondition. Domain knowledge enters through plugins: the CLFS proving plugin understands the common log file system driver's on-disk container layout and in-memory state machines well enough to construct triggering log files. Encoding the target's layout and state machine once, then searching over inputs, is the same move heap feng shui makes against an allocator (Microsoft Security Blog, 2026).

Exploitability is argued, not assumed. MDASH's debater agents argue for and against each finding's exploitability and reachability, and disagreement between models is treated as a signal: when an auditor flags something and the debater cannot refute it, the finding's credibility rises. Patch-based grouping then collapses equivalent findings, which matters because many crashes share one root cause. The system reports 88.45% on 1,507 real-world vulnerability tasks on the CyberGym benchmark, roughly five points above the next leaderboard entry. Its authors stress that the harness does the work and the model is one input, so the capability does not hinge on any single model release (Microsoft Security Blog, 2026).

The barrier between a theoretical bug and a weaponized exploit has dissolved. Maintainers are no longer receiving only crash traces; they are receiving working proofs of concept for subtle memory-safety flaws.

04 Case Studies

The pressure on maintainers is no longer a forecast. Over the past year, four of the most heavily used open source projects have each been forced to change how they accept vulnerability reports, and each chose a different lever: removing the incentive, redirecting the channel, raising the barrier, or formalizing the intake. The four cases below are taken in order.

Case Study 1: curl and the End of Its Bug Bounty

Trigger. On January 31, 2026, curl lead maintainer Daniel Stenberg officially shut down the project's six-year-old HackerOne bug bounty program.

Impact. The bounty had paid out over $100,000 and resolved 87 genuine vulnerabilities since 2019. Automated, AI-generated submissions then collapsed the valid finding rate to approximately 5%, about 1 in 20 submissions. Volunteer maintainers were overwhelmed triaging convincing but invalid reports, and described the workload as "death by a thousand slops."

Mitigation. Rather than keep exhausting volunteer triage capacity on unverified reports, curl eliminated monetary incentives entirely. That removed the financial motive for low-effort, LLM-generated submissions.

Case Study 2: The Linux Kernel's Saturated Security Queue

Trigger. On May 17, 2026, Linus Torvalds stated in the Linux 7.1-rc4 release announcement that the kernel's private security mailing list had become "almost entirely unmanageable."

Impact. Intake surged from 2 to 3 reports per week two years earlier to 5 to 10 reports per day by early 2026. The influx consisted largely of duplicate, AI-assisted findings that surfaced the same code issues simultaneously, without contextual validation or demonstrated exploitability.

Mitigation. Linux 7.1 introduced official kernel documentation, authored by Willy Tarreau, that redirects AI-assisted findings away from the private security channel and into public trackers. Maintainers also asked researchers to submit verified, tested patches alongside any vulnerability report.

Case Study 3: Node.js and Reputation Gating

Trigger. Node.js maintainers faced a wave of low-quality security reports over the winter maintainer holidays.

Impact. The absolute volume was small, and it was still enough to overwhelm the project's intake. The 19,000-line AI-assisted pull request that drew a developer petition is a separate dispute over contribution policy, not security intake, and this comparison leaves it out.

Mitigation. To filter out automated noise without closing community contribution pathways entirely, Node.js raised its HackerOne intake threshold by enforcing stricter researcher reputation requirements.

Case Study 4: Chromium and Formalized Intake SLAs

Trigger. Anticipating a large influx of AI-generated vulnerability submissions into its internal queues and its Vulnerability Rewards Program (VRP), the Chrome Security Team published dedicated operational guidance and an FAQ.

Impact. Triage teams increasingly saw submissions that looked technically plausible but cited nonexistent functions, commits, or attack paths, with no reproducible evidence.

Mitigation. Rather than bar submissions, Chromium absorbed them into formal workflows with rigid remediation targets: fixes within one week for S0 bugs and four weeks for S1 bugs.

Triage teams were told to initially handle reports that lack a proof of concept as security bugs.

The project also defined explicit security boundaries in its documentation and replaced renderer-reachable DCHECK assertions with CHECK assertions.

It kept the standard 30-day post-fix disclosure timeline, and it reused rejected or invalid reports as training and evaluation data for its AI triage tooling.

The table below sets the four responses side by side. They differ in mechanism, but not in direction:

The four differ by more than an order of magnitude in contributor base and by almost two decades in age, and none of that exempted any of them. Taken together, they show the same pattern from different angles: unverified volume is the failure mode, and every response either raises the cost of a report or moves verification onto the reporter. All four change who pays rather than what verification costs.

The next section follows the reports upstream, to see why the queue fills and why the cost lands where it does.

05 The Maintainer's Dilemma

The four cases above share one cause. Capable exploitation agents may keep improving, but maintainers already face an immediate operational crisis: the weaponized mass production of automated vulnerability reports, many of them low quality. The flow is simple, as the figure below shows. Scanners and bounty bots produce plausible-sounding reports in bulk, and they all land on one frequently unprepared defender.

Commercial bounty programs, gamified security platforms, and the low marginal cost of LLM queries have produced what the community calls AI slop security reports. Technical and nontechnical actors alike mass-scan public GitHub repositories, paste raw code into generic prompts such as "find all security vulnerabilities in this code and write a professional report," and submit the output unread through private disclosure channels, issue trackers, and security contact addresses.

The Anatomy of Hallucinated Vulnerability Reports

The insidious part is how competent these reports look. Traditional spam was easy to dismiss: broken English, vague descriptions, no reproduction steps. An LLM-generated report carries every surface hallmark of an elite disclosure:

• Authoritative formatting: impeccable Markdown with CWE classifications, CVSS v3.1 vectors, executive summaries, and impact assessments.
• Plausible mechanics: it describes complex failure modes such as time-of-check to time-of-use races, blind SSRF, format-string bugs, or integer truncation leading to buffer overflow.
• Fabricated exploits: a clean Python or Bash script that purports to demonstrate the flaw but fails to run, or targets code paths that cannot be reached in production.

An unpaid maintainer cannot simply ignore a submission titled "Critical Memory Corruption Vulnerability in Session Deserialization (CVSS 9.8)." Professional responsibility compels review.

That means loading the subsystem into working memory, tracing the call graph, cross-checking synchronization primitives, checking whether the buffer can ever receive unsanitized input, and usually writing a test script. OpenSSF's own maintainer guidance prices a single report at one to eight hours of that work (Aniszczyk et al., 2026).

After two to four hours of scarce personal time, the maintainer finds that the model hallucinated the accessibility of a private variable, or assumed an input was unvalidated when middleware three calls upstream had already sanitized it.

Multiply that by ten, twenty, or fifty submissions a week and the damage to sustainability is severe: acute burnout, resentment, and cynicism. Maintainers of widely used projects such as curl, systemd, and the Linux kernel have publicly described the flood, and some have threatened to close their issue trackers or step back from stewardship altogether.

"AI slop PRs are becoming increasingly draining and demoralizing for #Godot maintainers... I don't know how long we can keep it up." — Rémi Verschelde, Godot maintainer

The cost is not only personal. Real, high-impact vulnerabilities are buried under a growing volume of noise, which makes it harder for system administrators and operations teams to prioritize the updates that matter.

How the CVE System Rewards the Flood

The flood keeps coming because the system pays for it. Broken incentives in CVE issuance make this worse. The system, run by MITRE through a network of CVE Numbering Authorities (CNAs), was designed when discovery was rare, human-mediated, and deliberate. Today many automated platforms and third-party security vendors act as CNAs, and some assign identifiers automatically or with minimal independent verification of a plausible-sounding submission. That has bred a predatory ecosystem:

1. Reputational inflation: individuals run AI scanners across thousands of repositories to collect CVE credits for résumés and bounty profiles.
2. Automated extortion: maintainers get emails threatening public disclosure within 90 days unless a flaw, often a hallucinated one, is acknowledged and patched.
3. False dependency alerts: downstream users receive "High" or "Critical" findings from supply chain tools such as Dependabot, Snyk, and Black Duck. When enterprises demand emergency fixes for flaws that do not exist, the maintainer is dragged into an unpaid support spiral.

The severity labels are worth even less than the reports. No external party, human or model, knows how a given deployment is configured or what sits next to it, so a third-party score of your risk is at best an honest guess and at worst drama (Aniszczyk et al., 2026).

The public record shows how far that goes. Open WebUI keeps a registry of withdrawn identifiers that third-party databases still publish as active, nine of them, each still carrying a vendor identifier, a severity, and a remediation section. One, CVE-2025-29446, scored 3.3 Low and advised restricting access to a function "until a patch is available," though the identifier was rejected in June 2026 and no patch is coming. A wrong severity misinforms a reader; a wrong recommendation changes what they run (Open WebUI, 2026).

The same incentive logic works outside the CVE feed, through package managers. Because models recommend nonexistent dependencies with surprising consistency across providers, attackers now pre-register those imaginary package names, an attack OpenSSF has named slopsquatting: typosquatting replayed against hallucinated names.

Bounty Platforms Throttle the Flood

Incentives are the lever the platforms can actually reach, and the marketplaces that carry this traffic have started to pull it. HackerOne paused new submissions to its Internet Bug Bounty, which pays for vulnerabilities in open source, from March 27, 2026, saying that AI-assisted research was expanding discovery faster than the ecosystem could remediate (HackerOne, 2026). In one three-week stretch of March 2026, Bugcrowd's triage queue grew by 334%, almost entirely from low-quality submissions, and it answered with permanent bans for submission farming and 30-day suspensions after ten consecutive invalid reports (Bugcrowd, 2026a).

By May, Bugcrowd also required identity verification for its managed programs and capped how many reports a low-performing account could have in flight (Bugcrowd, 2026b). From July 27, 2026, GitHub's public program has required a HackerOne Signal threshold, and researchers below it get up to four initial submissions (GitHub, 2026). None of these moves is a proof-of-concept rule: each gates the submitter or the queue, not the evidence in the report. The PoC principle appears only as guidance, with Bugcrowd telling researchers that a report without a reproducible PoC, or one that cannot be validated automatically, should not consume human attention (Bugcrowd, 2026a).

China's State-First Disclosure Model

Whether the flood lands on unpaid volunteers at all is a governance choice, and China made the opposite one. Its 2021 vulnerability provisions route discovery into the state: every vulnerability reporting platform must register with the Ministry of Industry and Information Technology, vendors must relay each report they receive within two days, and publishing details before the vendor has had a reasonable chance to patch is prohibited unless MIIT approves the exception (Cyberspace Administration of China, 2021). The practical reading of that pipeline is state-first: the finding arrives before the vendor does.

The rulebook has since gotten steeper. The Cybersecurity Law amendment that took effect on January 1, 2026, the first revision since 2017, put money on both sides of the trade. Releasing vulnerability information to the public now draws a fine of RMB 10,000 to 100,000, rising to RMB 1 million with licence revocation, and inherits the aggravated tiers that run from RMB 500,000 to 10 million when the disclosure causes serious consequences. Vendors that fail to remediate defects and vulnerabilities, and to notify users and report them to the authorities, fall under that same regime, with personal fines of up to RMB 1 million for those responsible (China Briefing, 2025).

The maintainers are different too. Chinese open source is mostly firm-led rather than volunteer-led: the OpenAtom Foundation, founded in 2020 with MIIT backing by Alibaba, Baidu, Huawei, and Tencent, hosts OpenHarmony and openEuler, and openEuler took 57.3% of newly installed Chinese server operating systems in 2025 (CHINA POLICY, 2026). Those projects are staffed by employees whose job includes the intake, which is why the slop wave that ended curl's bug bounty arrives there as work rather than as burnout.

What that arrangement buys in capacity it pays for in disclosure. CNNVD still logged 111 vulnerabilities in OpenClaw in a single fortnight, so the intake has not gotten quieter, only less visible (Xinhua, 2026). The AI wave sharpens the trade. Qihoo 360's Tulongfeng, a multi-agent swarm presented in June as China's counterpart to Mythos, had flagged 3,432 vulnerabilities and seen 105 confirmed by government authorities, each one passing through the state pipeline before the vendor hears about it (Parham, 2026). The dilemma does not disappear under this model; it is relocated, and the bill is settled in transparency instead of unpaid hours.

06 Technical Defenses

The maintainer's problem is volume, and the answer starts at the moment a report arrives. Human-scale manual review cannot keep pace with machine-scale report generation, and maintainers cannot act as manual filters for automated scanners. Incoming reports have to pass through strict, machine-enforced verification gates before any human spends cognitive effort on them. The rest of this section follows a report through such an intake pipeline in three stages: a gate that filters at the door, triage agents that hand over a finished dossier, and patch synthesis that arrives with the fix.

The Mandatory Deterministic Proof-of-Concept Gate

The first structural defense is operational: no report without an automated, deterministic reproduction harness shall be prioritized for human review. A text description of a bug, however formal, is insufficient. Projects should update their SECURITY.md to require a containerized, automated reproduction script that reliably triggers the fault against the latest stable or development branch.

Intake platforms can enforce this programmatically. When a report arrives through a private disclosure channel such as GitHub Private Vulnerability Reporting:

1. The submission webhook starts an ephemeral, sandboxed runner, such as an isolated Firecracker microVM or a hardened Docker container.
2. The target repository is built from source with several compiler instrumentation flags, listed in the table below.
3. The submitted PoC runs inside the sandbox under strict resource and network isolation.
4. If execution produces no sanitizer fault, core dump, or unhandled assertion within a bounded time, the report moves to a "Verification Staging" queue and the reporter is notified automatically.

The automated message to the reporter is blunt:

Your vulnerability submission could not be deterministically reproduced in our automated instrumentation environment. The AddressSanitizer/UBSan run completed with exit code 0 and no memory faults were detected. Please provide an updated, self-contained reproduction script that triggers the fault within our standard container environment. Human maintainer triage will not commence until an automated reproduction is verified. — the project's automated intake reply

This single mechanism screens out reports that cannot reproduce a crash, which covers the fabricated, low-effort, and non-exploitable static-analysis kind, before any maintainer reads them.

The marketplaces are moving toward the same logic from the other side, though not as a reproduction rule. In the cases above, Bugcrowd, GitHub, and HackerOne gate on identity, track record, or queue size, and only Bugcrowd's guidance says a report without a reproducible PoC should never reach a human (Bugcrowd, 2026a). A project that wants the gate above has to build it, which is why the pipeline sits in front of the maintainer rather than in front of the marketplace.

The gate does not address the second flood, which is made of real findings. Glasswing's open-source reports were mostly valid, yet patching still lagged, and a reproduction gate admits a valid duplicate as readily as a unique bug. The gate also depends on sanitizer signal: logic errors, authorization flaws, cryptographic mistakes, and many race conditions raise no sanitizer fault, so an honest report of one of those fails a gate built for memory errors, while a crash can reproduce without being exploitable.

Verification has its own costs and attack surface. Someone has to build and run the sandboxes, and a triage agent that reads attacker-written text can be steered by it. The gate shrinks the first flood and leaves the second to the stages below and to the institutional defenses after them.

The figure below puts the stages together: schema pre-screening, sandboxed reproduction under sanitizers, and then either the maintainer-side analysis described next or a challenge back to the reporter.

Maintainer-Side Triage Agents

A gate decides what reaches a human, not how costly it is to review once it does. Beyond running scripts, projects can deploy defensive AI agents on incoming submissions. Where offensive agents focus on breaking invariants, defensive triage agents focus on validation, deduplication, and root-cause localization. When a valid crash occurs, such an agent:

• Parses stack traces, correlating the crash address with recent commits and open or closed pull requests to catch duplicates immediately.
• Minimizes the input, using delta debugging (such as AFL-tmin or LLM-driven minimization) to shrink a multi-megabyte payload to the minimal byte sequence that reproduces the fault.
• Explains root causes, analyzing the faulting instruction, tracing the upstream call stack, and writing a precise technical summary.

[Defensive Triage Summary - Auto-Generated]
- Status: VERIFIED MEMORY CORRUPTION (Heap-Buffer-Overflow Write)
- Subsystem: /src/codec/flac_decoder.c:382
- Cause: Missing bounds check on 'sample_size'
  when processing custom metadata blocks.
- Impact: Writes up to 64 bytes beyond the allocated buffer on line 380.
- Minimization: Input reduced from 14.2 KB to 48 bytes
  (attached: min_repro.bin).
- Duplicate Check: No matching closed CVEs; distinct from Issue #492.
- Proposed Action: Review attached auto-generated patch and test case.

Handing the maintainer a verified, localized, minimized report with a draft patch cuts the cognitive burden of triage dramatically.

The maintainer stops being an exhausted detective sifting through speculative noise and becomes an executive reviewing a pre-processed technical dossier.

Automated Patch Synthesis and Verification

The triage summary above ends with an auto-generated patch, and producing one that is safe to merge is a problem of its own. Patching security bugs in systems software is hazardous: a hurried fix often creates a secondary vulnerability.

An incomplete bounds check introduces an off-by-one error, a naïve deallocation to fix a leak creates a use-after-free on an alternate error path, and a broad lock added to stop a data race creates a deadlock under thread contention. A closed-loop pipeline guards against all three:

1. Fault ingestion: the agent takes the verified reproduction and the surrounding source context.
2. Candidate generation: the model proposes multiple patches, guided by static-analysis rules and semantic invariants, such as freeing every allocated resource on every error branch.
3. Differential testing: each candidate is compiled and run against the full test suite, including the PoC. A valid patch must eliminate the sanitizer violation, introduce zero regressions, and keep binary and source compatibility for public APIs unless a break is explicitly required for security.
4. Side-effect auditing: the agent checks that the patch does not introduce catastrophic algorithmic complexity, such as turning an O(N) lookup into an O(N²) loop that opens an algorithmic denial-of-service vector.

When the maintainer opens the pull request, they see a regression-tested patch plus the minimized test case that proves both the original bug and the fix, not an open, unmitigated vulnerability.

A merged fix is also not a deployed one, and for bugs already under exploitation that gap is where users get hurt. Project Zero's Natalie Silvanovich argues that vendors should plan emergency mitigations before they need them, and lists four: feature flags that switch a vulnerable feature off remotely, filtering rules that block known malicious input, alternate update channels that ship smaller changes faster than a full release, and hotpatching that replaces code in a running process (Silvanovich, 2026). Most of that machinery sits with vendors that run their own update infrastructure, such as Android and Windows, and few volunteer-run projects are likely to have any of it; Linux's livepatch is one open-source exception. Synthesizing a patch faster does little for users if the project cannot get it, or a stopgap, to them while the exploit is in the wild.

Together, the gate, the triage agents, and patch synthesis move the first pass off the maintainer. They also cost sandboxes, inference, and runner time that few volunteer projects can fund alone, which is where the institutional defenses in the next section begin.

07 Institutional Defenses

This is not only a computer science problem for individual maintainers to solve with better code and smarter CI bots. Open source underpins global financial systems, telecommunications grids, supply chains, healthcare technology, and defense networks. It is neither economically nor ethically viable to ask volunteers to defend that infrastructure against well-funded, automated, nation-state scanners and commercial exploitation rings. The chart at right, from Bono's model, is why the answer has to be collective.

There is now a formal case for dividing the work this way. Bono's contest-theoretic model of AI-augmented attack and defense finds that when threat intelligence cross-correlates across attack surfaces, an attacker's structural advantage from widening the surface is fully neutralised, while defenders systematically overinvest in private defense and underinvest in shared signal correlation, which behaves as a public good (Bono, 2026). RAND's accounting of the winning economics of cybersecurity under advanced AI arrives at the same conclusion from the budget side (Heitzenrater, 2025).

The remedy is institutional, and the figure below maps the two levers it has: compute and tooling subsidies on one side, governance reform on the other.

Free Enterprise-Grade Compute for Open Source

Offensive AI agents run on cloud compute. Neural-directed fuzzing and agentic reasoning loops need substantial GPU inference bandwidth and CPU compilation cycles. Enterprises and state-sponsored units have effectively limitless budgets, while maintainers live inside free-tier GitHub Actions allowances that cap runner concurrency, memory, and runtime.

Foundations such as the Linux Foundation, the Open Source Security Foundation (OpenSSF), and sovereign programs such as Germany's Sovereign Tech Fund must establish permanent compute reserves dedicated to automated defense of critical projects (OpenSSF, 2022).

Repositories should get unrestricted access to containerized runners with dedicated sanitizer hardware, fuzzing farms, and local LLM inference, and no maintainer should have to pay a cloud provider out of pocket to run the triage bots that protect enterprise supply chains. Initiatives like OpenSSF's Alpha-Omega, which funds security audits and infrastructure engineering for critical libraries, must scale by an order of magnitude, with mandatory contributions from enterprises that build multi-billion-dollar businesses on open source.

The divide runs the other way too. Every layer of this defense costs tokens, and OpenSSF's guidance is unusually blunt that the cost is rarely discussed: models, context, and infrastructure are not free, a smaller model is the cheaper and lower-carbon choice for a well-scoped task, and there is a real gap between the projects that can fund the usage and those that cannot.

Training is part of the same budget, which makes free courses on secure development and AI-driven security work the cheapest of these levers to pull (Aniszczyk et al., 2026).

Structural Reform of the CVE and Bug Bounty Ecosystem

The CVE architecture needs regulatory and operational reform to dismantle the incentives that drive automated submission of low-quality reports. The table below sets out three levers, who controls each, and the change each one calls for.

The first reform is a proof-of-concept requirement. MITRE and the CVE Board should revise the CNA operational rules so that no public identifier is reserved or issued for an open source vulnerability without an automated, reproducible PoC that has been independently verified, or without explicit confirmation from the project's designated security contact. The second is accountability: scanners and vendors that act as CNAs and systematically issue unverified, hallucinated, or malicious CVEs should risk revocation of their authorization.

The third concerns the bounty model. Paying only for vulnerability reports rewards mass automated scanning and noise. Platforms should move to defensive models that pay maintainers directly for reviewing and triaging disclosures, reward researchers for an end-to-end contribution (a reproduction harness, a verified memory-safe patch, and an upstream regression test), and ban accounts that submit raw, unverified LLM output without reproducing it themselves.

Some of that codification is already under way. OpenSSF's Vulnerability Disclosure Working Group is turning these practices into a shared standard for how projects and researchers use AI tools, which is the half of the problem CVE operational rules cannot reach on their own (Aniszczyk et al., 2026).

Legal and Regulatory Shields for Maintainers

Governments are adopting strict cybersecurity mandates, such as the European Union's Cyber Resilience Act (CRA) (European Parliament, 2024) and US executive orders and secure-by-design guidance (CISA et al., 2023), so liability frameworks have to be calibrated carefully.

Regulation must distinguish commercial vendors who profit from deploying code from unpaid, independent developers who release software under permissive licenses without warranty. Imposing liability or administrative penalties on maintainers for flaws that AI scanners find in public repositories would trigger mass abandonment of open source development.

Regulation should instead require commercial downstream consumers to build their own automated verification and triage infrastructure. If a Fortune 500 company ships an open source library inside its proprietary product, the responsibility for triaging, validating, and mitigating AI-discovered vulnerabilities in that dependency belongs to the enterprise that deployed it, not the volunteer who wrote it.

Underneath the liability question sits a fairness grievance. Most of the code these models learned from was published under licenses whose conditions, attribution above all, were written for human reuse, and the same model families now find and exploit bugs in that code while the resulting report queue lands on its authors.

The courts have not settled the first half. In September 2026 the Ninth Circuit affirmed the dismissal of the DMCA claim in Doe v. GitHub, holding that Copilot and Codex do not "remove or alter" attribution information because they create new works rather than copies of existing ones, and it declined to reach the plaintiffs' input theory as forfeited (Doe v. GitHub, 2026). The ruling decided one statutory theory, so whether training on licensed code breaches those licenses is still unanswered.

08 The Future Horizon

This is not a temporary surge in automated discovery but a permanent change in how software is audited, exploited, and maintained. Security will no longer be a contest between human programmers and machine algorithms; it will be an ongoing co-evolution of offensive and defensive agents, as the figure below shows.

Forecasting the transition is now its own small literature. Koch models it as agentic attack compression: autonomous pipelines erase the multi-day patch window that remediation cadences assume, so he argues autonomous defense belongs with the firewall and the identity provider as infrastructure, not bolted-on tooling (Koch, 2026).

The study is candid that its forecasts already ran late: several capabilities respondents expected after 2026 had arrived before it ended, and the benchmarks they were asked to weigh do not measure zero-day discovery, targeting, or persistence. On this subject, the forecasting has so far trailed the event.

The same panel's one agreed mitigation is release-side rather than defensive: keep the models that enable elite exploit development proprietary and hardened against jailbreaks. Nearly half expected that to at least halve the odds of a large-scale worm attack, while conceding it does little against state-level actors, exploit-as-a-service markets, or stolen weights.

A follow-up round four months later, after participants had read Anthropic's account of an AI-assisted espionage campaign, moved the median forecast not at all: the campaign read as evidence that attackers were capable, not that an AI could yet build an elite exploit (Ceppas de Castro et al., 2026).

Glasswing, Daybreak, and the Defensive Coalition

Some of this is already being built. In April 2026, Anthropic announced Project Glasswing, a defensive consortium that launched with twelve named partners, among them AWS, Apple, Cisco, Google, Microsoft, NVIDIA, and the Linux Foundation. The premise is blunt: the same frontier capability that makes autonomous discovery dangerous in the wrong hands is the capability defenders need, so it is gated behind a coalition of the parties that run critical infrastructure.

The first months produced numbers that match this post's thesis almost too well. Across its partners, the consortium's Claude Mythos Preview model surfaced more than 10,000 high- or critical-severity vulnerabilities in its first month, a vendor-reported figure that is not limited to open source. On open source alone it scanned more than 1,000 projects and reported 23,019 flaws, 6,202 of them estimated high- or critical-severity; of 1,752 high- or critical-rated findings that independent firms had assessed, 90.6% proved valid, but only 62.4% were confirmed as high or critical severity (Anthropic, 2026c). The 1,752 are a subset of the 6,202 estimates, and every figure here is Anthropic's own.

OpenAI answered a month later, announcing Daybreak on May 11, 2026. It promises the same work, secure code review, threat modeling, vulnerability triage, patch validation, and detection engineering, but ships it through a tiered trust model rather than a closed consortium: GPT-5.5 as the default, GPT-5.5 with Trusted Access for Cyber for verified defenders, and a gated, red-teamed GPT-5.5-Cyber variant.

The revealing part is the partner list. Cisco, CrowdStrike, and Palo Alto Networks signed on to both efforts (Janakiram, 2026). The figure below lays out both lists.

When the underlying capability converges and the access model does not, the access model becomes the product.

In October Anthropic folded Glasswing into a broader Cyber Mission and pointed it at the bottleneck rather than at discovery. Its open-source arm, OSS Scanner, gives enrolled projects free periodic scans, and every finding arrives as a proof of concept, an explanation, and a suggested fix. The reports are model-generated and sent without human review, on the company's estimate that more than 90% will be true positives, and enrollment is limited to projects that can keep up with the volume, which is the deterministic gate and the triage layer above written into a vendor's terms instead of a maintainer's intake.

The mission also pays for the shared layer rather than for one more project. It adds the Python Software Foundation to the foundations it funds, backs Akrites and Gold Eagle, the bodies that collect and coordinate reports from many sources so that maintainers are not overwhelmed one at a time, and keeps OSS Scanner free through a defense fund launched in August; a parallel program places frontier models and on-site engineers with the vendors who patch operational technology, where a fix can wait years for a safe maintenance window.

Anthropic's own forecast is that "in two years, AI will favor defense," because "it will be easier to catch bugs before they ship, write fundamentally secure software from scratch, and actively defend systems with models." The same passage concedes the near term: "But in the near term, that may not be true," because the cost of exploiting a vulnerability has dropped while "verifying, disclosing, and fixing them is slow and still depends on people." Under Glasswing, "we often saw months pass between a vulnerability being found and being fixed" (Anthropic, 2026b).

Handing maintainers frontier models to find bugs is necessary, not sufficient: it leaves confirmation, disclosure, and remediation where the verification gates described above were meant to move them.

The foundations are running their own half of this. The AI Cyber Challenge required its teams to donate their cyber reasoning systems as open source, and some of those systems are now moving to neutral governance under the Linux Foundation as OSS-CRS, so the tooling that won the competition stays available to maintainers instead of retiring with the program.

Alongside it, the Linux Foundation, CNCF, and OpenSSF have arranged free access to commercial-grade security tooling for qualifying projects, and published the artifacts a project needs to set its own boundaries: reporting guidelines, threat-model templates, and an AI-contribution policy of the kind Kubernetes has already adopted (Aniszczyk et al., 2026).

Glasswing and Daybreak are the template, not the endpoint. Google's Big Sleep and CodeMender, OpenSSF's Alpha-Omega, and government-funded compute programs are variations on the same move: put frontier capability, and the money to run it, in the hands of the people who maintain the infrastructure. The open question is whether they scale faster than capability proliferates, and whether they pay for the unglamorous half (triage, patching, maintainer time) and not only the discovery that generates the reports.

Autonomous Package Registry Immune Systems

The coalitions above protect individual projects. The same shift will reach the package registries that distribute them, such as npm, PyPI, crates.io, and Maven Central. Registries have historically been passive storage mirrors that accept wheels, tarballs, and source archives with little auditing beyond malware signature scanning.

Future registries will behave like active digital immune systems. Every new package or version will be started inside isolated microVM clusters, where agent swarms subject it to adversarial fuzzing, dynamic behavioral tracing, provenance verification (through Sigstore and SLSA), and deep semantic taint analysis.

The research record on those registries points the same way. The first large-scale benchmark of npm malware detectors evaluates 11 tools across 6,420 malicious and 7,288 benign packages; the best reaches an F1 above 95%, and the finding that matters more than the scores is that 80.3% of the malware uses no evasion at all, because there is no mandatory pre-publication scanning to evade (Guo et al., 2026). Agentic detection built on structured API knowledge already reports 96.7% precision and 99.6% recall on PyPI at well under a second per package (Pang et al., 2026).

Detectors of that kind already ship as products. I am not aware of any registry that insists on them: each of the tools below is bought by the people who install packages, not run by the registry that publishes them.

On Maven Central the dominant risk is inheritance rather than a malicious upload. A study of 14.5 million releases finds vulnerabilities reaching 31.4% of the newest artifacts through direct dependencies and 62.9% through transitive ones, which is an argument for screening at the registry rather than one project at a time (Nachuma et al., 2025).

Packages that introduce unverified memory hazards, covert command-execution paths, or unauthorized telemetry will be quarantined before a single downstream user runs npm install or pip install. Security stops being an individual project's burden and becomes a continuous, shared ecosystem defense.

The Autonomous Self-Healing Repository

Inside a single project the change goes further. Within a decade, an open source repository may shift from static code storage to an active, self-healing software organism. Code will not sit inert waiting for human eyes or periodic dependency updates. A cluster of specialized developer agents will continuously model the repository's dynamic execution surface.

When an offensive agent finds a novel attack vector, such as a subtle algorithmic-complexity flaw or a Spectre-style transient-execution issue, the defensive agents ingest the attack telemetry, generate an invariant-preserving patch, recompile the affected modules, verify that functional and performance tests pass, update the formal verification proofs, and submit a verified pull request to the human maintainers.

In that steady state, maintainers no longer spend their time writing repetitive unit tests, hunting leaks by hand, or arguing with bounty submitters. The human role rises to architectural stewardship (semantic intent, ethical constraints, business logic) while agent swarms handle validation and hardening.

The logical extreme of this loop is a repository with no human-readable source at all. If agents already regenerate, verify, and re-optimize every module, the source file is the last artifact written for people rather than for the machine, and legibility to people is the constraint that limits how far the program can restructure itself.

From Code Complete to Code Missing follows that argument to its endpoint, where an intent specification, a formally verified boundary, and the agent loop are all that remain.

09 Conclusions

This post opened with Linus's Law: given enough eyeballs, all bugs are shallow. The eyeballs are now machines. AI-discovered vulnerabilities hit open source where it is weakest: maintainer time. By driving the marginal cost of discovery toward zero while leaving the cost of human triage unchanged, autonomous analysis has fractured the traditional foundations of open source sustainability.

The vulnerabilities these systems surface were not created by the AI. They sat in the code for years or decades, waiting for someone to weaponize them. By surfacing them systematically, discovery tools force the community to confront its technical debt, which is the one upside of the crisis.

Three observations follow. The first is a premise, and the other two work as layers: each assumes the one before it will sometimes fail.

1. Human triage has a ceiling: people cannot manually triage or patch the output of automated vulnerability generation engines at the rate it arrives, and automation that reads reports is the only thing that keeps pace with automation that writes them.
2. Verification is the gate: an unverified vulnerability description costs a maintainer the same cognitive effort as a real bug, so what earns that effort is a deterministic, automated reproduction harness.
3. The cost exceeds the volunteer model: sustainable compute, reform of the CVE and bug bounty system, and cover from legal and operational exhaustion are not things individual maintainers can supply.

Read as a stack, the three are not alternatives to pick between. Triage automation still admits a report whose exploit nobody anticipated. A proof-of-concept gate still cannot tell a real bug from one that matters. And no governance regime patches anything on its own.

The four-pillar security stack reaches the same conclusion from the other direction in Zero-Day Defense: Going from 0 to 1: hardening, detection, containment, and remediation are stages of one lifecycle rather than competing bets, the backward arrows between them carry most of the value, and the lifecycle works only if you do not choose among them.

Betting on any single layer is still only a third of the job.

Open source rests on maintainers who write and review code in public, many of them unpaid. Equipped with machine-speed defenses of their own, they can keep that model working against machine-speed discovery.

References

• Anderson, R. (2001). "Why Information Security is Hard: An Economic Perspective." Proceedings of the 17th Annual Computer Security Applications Conference (ACSAC '01). IEEE Computer Society.
• Raymond, E. S. (1999). The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. O'Reilly Media.

• Cloud Security Alliance AI Safety Initiative. (2026a). "The Collapsing Exploit Window: AI-Speed Vulnerability Weaponization." CSA Labs. Available at: engage.checkpoint.com
• Cloud Security Alliance. (2026b). "Project Glasswing: AI Discovery Outpaces Open Source Patching Capacity." CSA Labs research note. Available at: labs.cloudsecurityalliance.org
• DARPA. (2023–2025). The AI Cyber Challenge (AIxCC): Unifying Generative AI and Program Analysis for Automated Software Defense. Defense Advanced Research Projects Agency.
• Dinkin, Y., & Kraft, E. (2026). "100+ Kernel Bugs in 30 Days." Available at: ydinkin.substack.com
• Heelan, S. (2026). "On the Coming Industrialisation of Exploit Generation with LLMs." Available at: sean.heelan.io
• Microsoft Security Blog. (2026). "Defense at AI Speed: Microsoft's New Multi-Model Agentic Security System Tops Leading Industry Benchmark." Available at: microsoft.com/security/blog

• Fioraldi, A., Maier, D. C., Eißfeldt, H., & Heuser, M. (2020). "AFL++: Combining Incremental Steps of Fuzzing Research." 14th USENIX Workshop on Offensive Technologies (WOOT 20).
• Serebryany, K., Bruening, D., Potapenko, A., & Vyukov, D. (2012). "AddressSanitizer: A Fast Address Sanity Checker." 2012 USENIX Annual Technical Conference (USENIX ATC 12), pp. 309–318.
• Zalewski, M. (2014). American Fuzzy Lop (AFL): Technical Details and Whitepaper. lcamtuf.coredump.cx/afl/.

• Alhazmi, O. H., & Malaiya, Y. K. (2005). "Modeling the Vulnerability Discovery Process." 16th IEEE International Symposium on Software Reliability Engineering (ISSRE '05). Available at: cs.colostate.edu
• Ozment, A., & Schechter, S. E. (2006). "Milk or Wine: Does Software Security Improve with Age?" 15th USENIX Security Symposium, pp. 93–104. Available at: usenix.org

• Aniszczyk, C., Robinson, C., & Wheeler, D. A. (2026). Securing Open Source in the Age of AI: A Practical Guide for Maintainers, Security Engineers, Researchers, and the Communities That Depend on Them. OpenSSF & CNCF. Available at: openssf.org
• Chromium Project. (2026). "Shepherding AI Reports" and "AI-Generated Security Bugs FAQ." Available at: chromium.googlesource.com
• curl project. (2023). "lib/ws.c at commit e251e85." Available at: github.com/curl/curl
• curl project. (2026). "The curl project history." Available at: curl.se
• HackerOne. (2023). "Buffer Overflow Vulnerability in WebSocket Handling," report #2298307. Available at: hackerone.com
• Stenberg, D. (2026a). "AI slop security reports submitted to curl." GitHub Gist, updated September 2026. Available at: gist.github.com/bagder
• Stenberg, D. (2026b). "The end of the curl bug-bounty." Available at: daniel.haxx.se

• gHacks. (2026). "Linus Torvalds Says AI-Generated Bug Reports Have Made Linux Security Mailing List Unmanageable." Available at: ghacks.net
• Martindale, J. (2026). "Godot Game Engine Is Drowning in Vibe-Coded AI Slop Contributions." PCMag. Reports Rémi Verschelde's Bluesky posts: bsky.app/@akien. Available at: pcmag.com
• Noze.it. (2026). "432 Linux kernel CVEs in two days: what to do when counting stops working." Available at: noze.it
• OSTechNix. (2026). "Linux Kernel 7.1 RC4 Released: Torvalds Slams 'Pointless' AI Bug Reports." Available at: ostechnix.com
• The Register. (2024). "AI-assisted bug reports make developers bear cost of cleanup." Available at: theregister.com
• The Register. (2025). "Curl takes action against time-wasting AI bug reports." Available at: theregister.com

• Bugcrowd. (2026a). "Sloptimism is breaking any system built on human validation." Available at: bugcrowd.com
• Bugcrowd. (2026b). "Continuing our work to reduce AI slop submissions and protect signal quality." Available at: bugcrowd.com
• GitHub. (2026). "Next chapter: restructuring GitHub's bug bounty program." Available at: github.blog
• HackerOne. (2026). "Internet Bug Bounty." Available at: hackerone.com
• Node.js. (2026). "New HackerOne Signal Requirement for Vulnerability Reports." Available at: nodejs.org
• Open WebUI. (2026). "Rejected CVEs in Vulnerability Databases: Positive Technologies (dbugs)." Available at: docs.openwebui.com

• Anthropic. (2026a). "Claude Mythos Preview's cybersecurity capabilities." Available at: anthropic.com
• FSFE. (2026). "NHS England should not hide public code behind closed doors." Free Software Foundation Europe. Available at: fsfe.org
• The Register. (2026a). "NHS to close-source GitHub repos over AI, security concerns." Available at: theregister.com
• The Register. (2026b). "AI's not going to kill open source code security." Available at: theregister.com
• Vaughan-Nichols, S. J. (2026). "'Like handing out the blueprint to a bank vault': Why AI led one company to abandon open source." ZDNET. Available at: zdnet.com

• China Briefing. (2025). "Revisions to China's Cybersecurity Law: Strengthened Oversight and Alignment with Emerging Technologies." Dezan Shira & Associates. Available at: china-briefing.com
• CHINA POLICY. (2026). "Institutionalising Open-Source in the PRC." Available at: chinapolicy.substack.com
• Cyberspace Administration of China. (2021). Regulations on the Management of Security Vulnerabilities in Network Products (effective September 1, 2021). Available at: cac.gov.cn
• Parham, A. (2026). "China Builds AI Vulnerability Scanner to Counter Mythos: Every Zero-Day Goes to Beijing by Law." Tech Times. Available at: techtimes.com
• Xinhua. (2026). "China Accelerates AI Agent Governance Amid Emerging Security Risks." Available at: english.news.cn

• Anthropic. (2026b). "Introducing the Anthropic Cyber Mission." Available at: anthropic.com
• Anthropic. (2026c). "Project Glasswing: An Initial Update." Available at: anthropic.com
• Anthropic. (2026d). "Project Glasswing: Securing critical software for the AI era." Available at: anthropic.com/glasswing
• Janakiram MSV. (2026). "OpenAI's Daybreak and Anthropic's Glasswing have nearly identical benchmarks — and 3 of the same partners." The New Stack. Available at: thenewstack.io
• OpenAI. (2026). Daybreak: The Defense the AI Era Demands. Available at: openai.com/daybreak. The Daybreak Defense Network partner list is at openai.com/daybreak/partners
• OpenSSF. (2022). The Open Source Software Security Mobilization Plan. The Linux Foundation & Open Source Security Foundation.

• Ceppas de Castro, R., Williams, B., Halstead, J., van der Merwe, M., & Connor, J. (2026). "Forecasting AI Cyber Risks and Capabilities: Results of a 2025 Pilot Study." Forecasting Research Institute, Working Paper #7. Available at: forecastingresearch.org
• Koch, C. (2026). "Agentic AI and the Industrialization of Cyber Offense: Forecast, Consequences, and Defensive Priorities for Enterprises and the Mittelstand." arXiv:2605.06713. Available at: arxiv.org/abs/2605.06713

• Silvanovich, N. (2026). "How to Fix a Bug in a Fix." Google Project Zero, October 6, 2026. Available at: projectzero.google

• Endor Labs. (2026). "Malicious Package Detection." Available at: endorlabs.com
• Guo, W., Chen, Z., Xu, Z., Liu, C., Kang, M., Song, S., Liu, C., Xu, Y., Sun, W., & Liu, Y. (2026). "How Effective Are NPM Malicious Package Detectors? A Large-Scale Empirical Study." arXiv:2603.27549. Available at: arxiv.org/abs/2603.27549
• Nachuma, C., Hossan, M. M., Turzo, A. K., & Zibran, M. F. (2025). "Decoding Dependency Risks: A Quantitative Study of Vulnerabilities in the Maven Ecosystem." arXiv:2503.22134. Available at: arxiv.org/abs/2503.22134
• Pang, S., Yao, Y., Jiang, Z., Fan, Z., Li, H., & Liu, B. (2026). "PYPILINE: Malicious PyPI Package Detection via Suspicious API Knowledge and Agent Workflow." arXiv:2606.19063. Available at: arxiv.org/abs/2606.19063
• ReversingLabs. (2026). "Spectra Assure: Software Supply Chain Security." Available at: reversinglabs.com
• Socket. (2026). "Secure software at AI speed." Available at: socket.dev
• Snyk. (2026). "Snyk AI Security Platform." Available at: snyk.io/platform

• CISA, NSA, FBI, & International Partners. (2023). Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and Default. Cybersecurity and Infrastructure Security Agency.
• Doe v. GitHub, Inc., No. 24-7700 (9th Cir. Sept. 16, 2026) (opinion of Judge Miller). Available at: eff.org
• European Parliament. (2024). Regulation on Horizontal Cybersecurity Requirements for Products with Digital Elements (Cyber Resilience Act). Official Journal of the European Union.
• GDS & DSIT. (2026). "AI, Open Code and Vulnerability Risk in the Public Sector." Government Digital Service & Department for Science, Innovation and Technology. Available at: gov.uk
• QEMU Project. (2026). "Code Provenance." QEMU documentation. Available at: qemu.org

• Bono, J. W. (2026). "The Adversarial Discount: AI, Signal Correlation, and the Cybersecurity Arms Race." arXiv:2605.04336. Available at: arxiv.org/abs/2605.04336
• Catalini, C., Hui, X., & Wu, J. (2026). "Some Simple Economics of AGI." arXiv:2602.20946. Available at: arxiv.org/abs/2602.20946
• Gordon, L. A., & Loeb, M. P. (2002). "The Economics of Information Security Investment." ACM Transactions on Information and System Security, 5(4), pp. 438–457.
• Heitzenrater, C. (2025). The Winning Economics of Cybersecurity in an Age of Advanced Artificial Intelligence. RAND Corporation, PE-A3691-11. Available at: rand.org