The Volunteer DDoS: Why AI Security Tools Are Breaking the Infrastructure They’re Meant to Protect

digitado ⋅ 21 de April de 2026

Three pieces in this series covered how open source trust infrastructure gets degraded from outside: by corporate extraction, government neglect, and funding failures. This one is about what happens when AI enters that same stressed infrastructure, and what the community is building in response.

This is the fourth piece in a series on open source sustainability and security infrastructure. The first covered the HashiCorp licensing controversy and what it revealed about the open source social contract. The second covered why forking was the right community response. The third covered the near-collapse of the CVE program and what it means for global vulnerability coordination. This piece is about what happens when AI enters the same stressed infrastructure.

At FOSDEM this year, I had the same conversation four or five times. The specifics changed. The shape did not. Someone building or shipping AI security tooling wanted to talk about adoption. Why are maintainers not using this? Why does the pull request get ignored? Why does the issue sit unanswered? The answer I kept giving at FOSDEM was the same one I have been giving for two years. The tools are aimed at the wrong problem, and this is about to change.

Most AI security tooling is designed to find more vulnerabilities. More findings, faster, at lower cost. What it is not designed for is the human being on the other end of that pipeline who has to decide what to do with the output. That human is usually a volunteer. They have a day job. They have fifteen other PRs pending. They did not ask to become a triage queue for AI-generated noise.

That is where the adoption failure lives.

Infrastructure: A $12.5 Million USD Problem

In March 2026, the Linux Foundation announced $12.5 million in grant funding from a coalition including Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft, and OpenAI. The money flows through Alpha-Omega and the OpenSSF. The goal is open source software security.

Most coverage treated this as a funding story. It is not a funding story.

Michael Winser, co-founder of Alpha-Omega, laid out the actual problem in his interview with Diginomica. The friction of discovering and reporting a potential vulnerability has dropped close to zero. Any researcher who can write a prompt can generate a list of findings. What they cannot generate is the tribal knowledge a project accumulates over years of development. That knowledge lives in maintainers, not in models.

The result is a flood of AI-generated vulnerability reports that arrive without context, without awareness of project conventions, and without the judgment to know whether a finding is real, redundant, or just wrong. Steve Fernandez, General Manager of OpenSSF, has a name for it. “AI slop.” Some of it is good. A lot of it is not. All of it takes time to read.

Winser described what is happening in maintainer communities as a “tortoise shell defense strategy.” Heads down. Ignore everything. Try to survive. When a maintainer stops processing the queue, they stop seeing the real threats inside it. Signal disappears with the noise.

The tooling meant to help is actively degrading the conditions under which maintainers can respond to real problems. That is not a scanning tool failure. It is a trust architecture failure.

This pattern has a history. I wrote about the HashiCorp licensing switch in 2023 and why calling it the death of open source was the wrong frame. A corporation was extracting value from the open source trust system while degrading the conditions that made that system work. The community’s response was governance: OpenTofu, the Linux Foundation fork of Terraform, reasserted control through the mechanisms the ecosystem actually has. I covered that in the follow-up. The CVE collapse was the same shape of failure from a different direction: critical shared infrastructure treated as a budget line rather than a public utility, destabilized not by attack but by neglect. AI contribution pipelines running without governance are the same thing again. Not malicious by default. Erosive by design.

Daniel Stenberg, creator of cURL, one of the most widely deployed software components on the planet, ended his project’s bug bounty program on January 31, 2026. The valid-report rate had dropped below 5% while AI-generated submissions hit 20% of all incoming reports. He named the phenomenon “death by a thousand slops” and described the math plainly: “Not only the volume goes up, the quality goes down. So we spend more time than ever to get less out of it than ever.” The cURL security team was reviewing reports, attempting reproduction, reading code paths, writing responses, and finding nothing. That is not a security improvement. That is a volunteer DDoS.

The Acceleration Case

Claude Mythos Preview changed the scale of this problem. On April 7, 2026, Anthropic published a technical assessment of a frontier model that can autonomously identify zero-day vulnerabilities and construct working exploits across every major operating system and web browser. The performance gap from its predecessor is not incremental. When researchers ran both models against the same Firefox 147 JavaScript engine vulnerabilities, Claude Opus 4.6 produced two working exploits out of several hundred attempts. Mythos Preview succeeded 181 times.

The specific findings are worth stating plainly. A 27-year-old denial-of-service vulnerability in OpenBSD’s TCP SACK implementation. A 16-year-old flaw in FFmpeg’s H.264 codec, introduced in a 2003 commit and exposed by a 2010 refactor, missed by every fuzzer and human reviewer since. CVE-2026-4747, a 17-year-old remote code execution vulnerability in FreeBSD’s NFS server granting unauthenticated root access, exploited fully autonomously after a single prompt. The model chained four separate vulnerabilities to escape browser sandboxes using JIT heap spraying. On 100 Linux kernel CVEs from 2024 and 2025, it built privilege escalation exploits for more than half of the 40 it assessed as viable targets.

Anthropic’s own red team was direct about what produced these capabilities: “We did not explicitly train Mythos Preview to have these capabilities. Rather, they emerged as a downstream consequence of general improvements in code, reasoning, and autonomy.”

That sentence is the thing to sit with. Nobody designed this. It arrived.

Anthropic’s response was Project Glasswing: a gated program with named launch partners including Amazon, Apple, Broadcom, Cisco, CrowdStrike, the Linux Foundation, Microsoft, and Palo Alto Networks, plus approximately 40 additional organizations responsible for critical software infrastructure. Anthropic is committing up to $100 million in usage credits for the effort, with $4 million in direct donations to open-source security. Access is restricted. Findings flow through vetted channels. The Linux Foundation is explicitly in the room.

That governance structure is the correct response to a capability at this level. It is also a template for what every AI security pipeline should look like but currently does not.

On April 15, 2026, UK Secretary of State for Science, Innovation and Technology Liz Kendall and Security Minister Dan Jarvis co-signed an open letter to British business leaders. The UK’s AI Security Institute had independently tested Mythos and found it substantially more capable at cyber offense than any previous model. The AISI now assesses that frontier model cyber capabilities are doubling every four months, up from every eight months previously.

Glasswing is proof the governance model works. Restricted access, vetted partners, the Linux Foundation at the table, $100 million in usage credits directed at defensive work. That is not an accident. It is a deliberate architecture choice, and it shows exactly what responsible deployment of Mythos-class capability looks like in practice.

Glasswing built that architecture in weeks. The question is whether the broader ecosystem builds it before ungoverned Mythos-class pipelines proliferate. Models at this capability level do not stay restricted forever. The window to get governance right is open. The community knows how to build governance. It has done it before. The work is already underway.

What Reputation Farming Actually Looks Like

In February 2026, developer Nolan Lawson received a cold outreach email from an entity calling itself “Kai Gritun.” The entity offered to submit pull requests to PouchDB, the JavaScript database Lawson maintains. The email mentioned six merged PRs on another project and a willingness to “start small to prove quality.”

A background check revealed the Kai Gritun GitHub profile had been created at the start of February. Within days, it had opened 103 pull requests across 95 repositories. Twenty-three commits had landed across projects including Nx, the ESLint Unicorn plugin, Clack, and the Cloudflare Workers SDK. The account did not identify itself as an AI anywhere on its profile. Lawson only found out because he got the email.

Security researchers at Socket named what they were seeing: reputation farming. An AI agent building provenance and association with well-known projects at a speed no human actor could match, in order to be perceived as trustworthy.

The code contributions were mostly non-malicious. That is not the point.

Socket noted that trust can be accumulated quickly and converted into influence or access. The XZ-Utils supply chain attack took a nation-state-level actor years of slow, careful reputation-building to execute. The same mechanics can now be replicated in days. The next version, Socket warned, might not leave the same obvious traces.

Eugene Neelou at Wallarm named the structural shift: “Once contribution and reputation building can be automated, the attack surface moves from the code to the governance process around it.” Projects that rely on informal trust and maintainer intuition will struggle. Projects with enforceable governance will hold.

AI trust needs to be anchored in verifiable controls. Not in assumptions about contributor intent.

Frederick Kautz, the SAFE-MCP SIG maintainer, has a specific name for this. The attacks live in changed assumptions. Kai Gritun did not inject malicious code. It exploited the assumption that a contributor with merged PRs and an active profile is a trustworthy human. Once that assumption can be manufactured in days rather than years, the governance process becomes the attack surface. SAFE-MCP exists to name that class of threat so defenses can be built against it.

What the OpenSSF Is Actually Building

Open source communities have a specific response to infrastructure failures. They build. While most of the industry has been writing blog posts about AI security risks, the OpenSSF AI/ML Security Working Group has been building the vocabulary and tooling to address them.

SAFE-MCP is a threat catalog for tool-based large language models, modeled on the MITRE ATT&CK framework. It catalogs over 80 attack techniques specific to LLM-and-tool systems, assigns each a persistent identifier, and gives security teams a shared vocabulary for verifying whether their architecture mitigates specific known risks. The MCP Rugpull Attack is SAFE-T1201. Context exfiltration and lateral movement have their own entries. You cannot defend against threats you cannot name, and until SAFE-MCP, this class of threat had no names.

OSS-CRS (Cyber Reasoning Systems) arrived at OpenSSF in April 2026, graduated out of DARPA’s AI Cyber Challenge. It is a standard orchestration framework for LLM-based autonomous vulnerability discovery and patch generation. Team Atlanta used it to find 25 vulnerabilities across 16 projects covering PHP, U-Boot, memcached, and Apache Ignite 3.

The number that matters more than that: the OSS-CRS team manually reviewed 630 AI-generated patches and found that 20 to 40 percent were semantically incorrect. Every one of those incorrect patches passed automated validation. They were wrong in ways that only a human reviewer with project context could catch.

OSS-CRS sits between the AI output and the maintainer. It filters and triages. OpenSSF is building human connectors between the CRS tools and open source communities to make sure findings are accurate, actionable, and respectful of maintainer time before they land in anyone’s inbox. Human review is not optional in this design. It is load-bearing.

OSS-CRS finds real vulnerabilities and generates patches. But those findings land in a reporting ecosystem that is itself fragile. In April 2025 I wrote about the near-collapse of the CVE program, when MITRE’s contract expired with hours to spare and the entire global vulnerability-tracking infrastructure almost went dark, not by a cyberattack but by budgetary neglect. I said at the time I would write a more detailed protocol for what comes next. OSS-CRS is part of that answer, but not the whole answer.

The AI noise crisis and the CVE fragility crisis compound each other. AI-generated slop floods the reporting channels at the moment those channels have the least capacity to absorb it. NIST’s NVD was already overwhelmed by backlog before AI tooling began generating vulnerability reports at scale. For maintainers working on EU-facing products, the CRA’s vulnerability disclosure obligations depend on CVE IDs existing and being trustworthy. OSS-CRS is valuable precisely because it filters before anything reaches a maintainer. The foundation it builds on also needs structural repair, and the community knows it.

The Trust Stack

“Secure-by-design AI” means almost nothing without a concrete definition for the context you are operating in. For open source maintainers, here is the stack.

If you can do one thing this week, start with OMS model signing in your CI/CD pipeline. It is additive. It does not require changing your review process or your contributor agreements. It gives you a verifiable provenance record that everything else in this stack builds on. The other four controls matter, but they all assume you can answer the question “where did this artifact come from?” OMS is how you answer it.

Cryptographic provenance for models and artifacts. The OpenSSF Model Signing specification (OMS) is a PKI-agnostic standard for signing ML artifacts. It covers model weights, configuration files, tokenizers, and datasets as a single verifiable unit under one signature. It uses the Sigstore Bundle Format, which maintainers in the Python, Go, and container ecosystems already encounter. Signing does not prevent a bad model from being built. It creates a verifiable record of origin and integrity that makes tampering detectable. That is the first gate.

Scoped permissions for agent actions. Angela McNeal of Thread AI put the clearest example on the table at the April 2026 OpenSSF tech talk. Without explicit scope boundaries, an AI agent follows the path of least resistance. An agent handling one insurance claim read records for an entire family plan because nothing told it to stop. In a repository context, the same behavior means reading configuration files, environment variables, commit history, or secrets the agent was never meant to access. Least privilege for AI agents is an architectural requirement. You cannot patch it in after the fact.

Human approval as a hard gate for patch merging. The 20 to 40 percent semantic error rate in OSS-CRS patches is not a temporary problem waiting for models to improve. It reflects a structural gap between syntactic correctness and architectural coherence. A model does not know your project’s undocumented conventions. Automated tests do not test for those either. The human reviewer who understands why a particular abstraction exists is the only reliable check. Treat that review as a hard gate, not a fallback.

Sandboxed execution for generated code. Any pipeline that executes AI-generated code before review needs isolation. The Linux kernel’s Landlock API gives you process-level filesystem access controls without requiring elevated privilege. Seccomp filters limit available syscalls. Both are production-ready on any modern Linux distribution. They are not exotic. They are just underused.

Structured logging for the reasoning chain. Context integrity means being able to reconstruct why an agent took a particular action. Logging only the final output is insufficient for incident review and insufficient for regulatory requirements. An agentic pipeline that cannot explain its own decisions is a liability you have chosen to carry.

If you need to make this case to enterprise contributors or compliance teams, the NIST AI RMF and SSDF give you the vocabulary. Provenance and signing map to GOVERN and MEASURE. Human review gates and scoped permissions map to MANAGE. Structured logging makes all of it auditable. The OMS specification directly extends SSDF’s software integrity controls to ML artifacts. Those mappings are at nist.gov when you need them for a procurement conversation.

There are Three Layers Most Tools Collapse Into One

One reason AI security tooling for open source keeps missing the maintainer problem is that it conflates three distinct layers and tries to address all of them with one product.

The first layer is the AI artifact itself. Models can be poisoned during training. Weights can be tampered with in transit. A model modified to produce subtly wrong outputs is not detectable by the application that runs it. OMS addresses this layer. Verifiable provenance for the model is necessary before you trust anything it does.

The second layer is agent runtime behavior. Agents are non-deterministic by design. They do not follow the same execution path for the same input. They discover their access surface at runtime. They do not natively distinguish between data and instructions, which is the structural precondition for prompt injection. SAFE-MCP names the attack surface at this layer. Runtime controls like Landlock enforce the scope boundaries.

The third layer is the contribution pipeline itself. AI-generated code and AI-generated security reports arrive through the same channels as human contributions. A maintainer looking at a GitHub profile cannot tell from the interface whether they are looking at a human or an agent. Reputation farming exploits exactly that gap. The fix is machine-verifiable governance: signed artifacts, disclosed authorship, policy-enforced review gates.

Treating these as one problem produces tools that are too broad to be useful and too complex to be adopted by a volunteer with limited time. Treating them as three separate problems produces the layered, maintainer-legible architecture that OSS-CRS and OMS are actually building toward.

The Community Has Done This Before

Open source is not a side project of the software industry. It is the substrate that enterprise software runs on. And the people maintaining it have been here before. We are going to be ok.

HashiCorp changed its license. The community forked Terraform and gave the Linux Foundation the result. CVE funding almost collapsed. Distributed alternatives, OSV.dev, the GitHub Advisory Database, SPDX security advisories, accelerated. Every time the open source trust infrastructure has been stressed from outside, the response has been the same: governance built by the people who depend on it.

AI contribution pipelines are the next version of this challenge. The difference is that this time, the governance model already exists before the crisis peaks. Glasswing built it at scale within weeks of Mythos going live. OSS-CRS is filtering findings before they reach maintainers. OMS is giving ML artifacts the same cryptographic provenance that Sigstore gave code. SAFE-MCP is naming an attack surface that previously had no shared vocabulary.

These are not future projects. They are running today.

Winser put it plainly: the most important currencies here are trust and attention. Maintainers have limited attention. But they also have two decades of practice building exactly this kind of shared governance infrastructure. This community built the Linux kernel. It built the package ecosystems and the vulnerability disclosure processes. It built the standards bodies and the license frameworks. Every time a new threat arrived without a governance layer, the community built one.

It can build the trust layer for AI contributions. The tools exist. The community needs to adopt them, and to hold any AI pipeline that wants a maintainer’s attention to the standard that Glasswing already demonstrated is achievable.

That is not an aspirational goal. The ecosystem has already proven it knows how to do this.

If you want to start now: the SAFE-MCP threat catalog is at github.com/safe-agentic-framework/safe-mcp. The OSS-CRS project is at openssf.org/projects/oss-crs. The OpenSSF’s free course on secure AI/ML software development (LFEL1012) is at training.linuxfoundation.org. All three are worth an hour of your time before your next AI tooling decision.

Go out and keep building. We’ll keep building security upstream to make it happen.

References

OpenSSF Tech Talk Recap: Securing Agentic AI (April 2026) — [https://openssf.org/blog/2026/04/08/openssf-tech-talk-recap-securing-agentic-ai/]()
From AIxCC to OpenSSF: Welcoming OSS-CRS (April 2026) — [https://openssf.org/blog/2026/04/02/from-aixcc-to-openssf-welcoming-oss-crs-to-advance-ai-driven-open-source-security/]()
An Introduction to the OpenSSF Model Signing (OMS) Specification (June 2025) — [https://openssf.org/blog/2025/06/25/an-introduction-to-the-openssf-model-signing-oms-specification/]()
Securing Agentic AI in Practice: OpenSSF Tech Talk Pre-announcement (March 2026) — [https://openssf.org/blog/2026/03/13/securing-agentic-ai-in-practice-from-openssf-guidance-to-real-world-implementation/]()
Open source maintainers are drowning in AI-generated security noise (Diginomica, March 2026) — [https://diginomica.com/open-source-maintainers-are-drowning-ai-generated-security-noise-125-million-being-deployed-throw]()
Open source maintainers targeted by AI agent as part of reputation farming (InfoWorld, February 2026) — [https://www.infoworld.com/article/4132851/open-source-maintainers-are-being-targeted-by-ai-agent-as-part-of-reputation-farming.html]()
OSS-CRS Project Page — [https://openssf.org/projects/oss-crs/]()
NIST AI Risk Management Framework — [https://www.nist.gov/itl/ai-risk-management-framework]()
NIST Secure Software Development Framework (SSDF) — [https://csrc.nist.gov/projects/ssdf]()
Launch of Model Signing v1.0 (April 2025) — [https://openssf.org/blog/2025/04/04/launch-of-model-signing-v1-0-openssf-ai-ml-working-group-secures-the-machine-learning-supply-chain/]()
Death by a Thousand Slops, Daniel Stenberg (July 2025) — [https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/]()
SAFE-MCP GitHub Repository — [https://github.com/safe-agentic-framework/safe-mcp]()
Secure AI/ML-Driven Software Development, LFEL1012 (Linux Foundation) — [https://training.linuxfoundation.org/express-learning/secure-ai-ml-driven-software-development-lfel1012/]()
Anthropic Project Glasswing — [https://www.anthropic.com/project/glasswing]()
Anthropic Claude Mythos Preview technical assessment (April 7, 2026) — [https://red.anthropic.com/2026/mythos-preview/]()
Help Net Security: Anthropic’s new AI model finds and exploits zero-days (April 8, 2026) — [https://www.helpnetsecurity.com/2026/04/08/anthropic-claude-mythos-preview-identify-vulnerabilities/]()
UK Government open letter: AI cyber threats to business leaders (April 15, 2026) — [https://www.gov.uk/government/publications/ai-cyber-threats-open-letter-to-business-leaders/ai-cyber-threats-open-letter-to-business-leaders-html]()

Like 0

Liked Liked