International Security Journal hears exclusively from Jamie Beckland, Co-Founder of APIContext about the hidden security costs behind AI “vibe coding.”
In January 2026, Daniel Stenberg shut down curl’s bug bounty program.
The program had run since 2019, paid out over $90,000 for 81 genuine vulnerabilities and was widely regarded as a model for community-driven security research.
It was killed because a flood of AI-generated, largely fabricated vulnerability reports had made it impossible to sustain. By late 2025, less than 5% of reports were accurate.
The rest were confident-sounding noise generated by contributors who fed the codebase into a model, submitted whatever came out and moved on.
Open source maintainers are at a breaking point. Which means the code that powers every website and app on the internet (and most enterprise IT) is at risk of tipping over.
Curl runs on an estimated ten billion devices.
The AWS SDK for C++ uses libcurl as a core networking dependency.
The Azure CLI uses curl to download and run its own installation.
Docker, Kubernetes, Terraform and virtually every cloud-native tool in your environment make HTTP requests…and a significant fraction of those requests flow through curl or libraries directly derived from it.
When a vulnerability surfaces in curl, your security team scrambles to find every place it lives in your stack.
When the maintainer of curl can no longer sustain a viable security research program because vibe-coded AI reports have overwhelmed his review capacity, that is a problem for everyone, whether or not your company has ever filed a GitHub issue against the project.
The open source dependency
Iceberg Open source software is everywhere.
According to the 2024 Open Source Security and Risk Analysis (OSSRA) report, 96% of commercial codebases contain open source components.
The typical closed-source enterprise application is between 78% and 90% open source by volume.
The infrastructure your teams build on is almost entirely maintained by the open source community, overwhelmingly by individuals or small teams, almost entirely without compensation from the companies consuming it.
THat includes cloud SDKs, API clients, authentication libraries, data serialisation frameworks, container runtimes and more.
Awareness of open source dependencies is growing.
When Log4Shell disclosed a vulnerability in December 2021, enterprises scrambled to find every place it existed in their software stack.
Many couldn’t. 80% of Java packages affected by the vulnerability couldn’t be updated directly and required coordination across multiple dependent projects.
Companies found Log4j buried five and six layers deep in third-party products they’d bought and deployed years earlier, maintained by vendors who themselves had incomplete views of their own dependency trees.
So, this asymmetry between consumption and contribution has been building for decades.
What’s new is that vibe coding slows maintainers to a crawl, right as the dependency graph has become more complex and more critical than ever.
Vibe coding’s hidden toll
When Andrej Karpathy coined “vibe coding” in February 2025, the productivity framing was compelling: describe what you want, let the model write it, ship when the tests pass.
Adoption has been rapid.
What the productivity framing misses entirely is the externalised cost.
When someone uses an AI tool to generate a contribution to an open source project and submits it without deep verification, they are doing something economically distinct from a developer writing that contribution themselves.
The cost of producing the PR has been reduced to nearly zero. The cost of reviewing it has not.
A maintainer receiving a vibe-coded PR still has to read it carefully, understand what it actually does, identify what it gets wrong and write a response that is constructive enough not to damage the contributor relationship.
This typically takes 20 to 40 minutes per PR, regardless of how it was generated. The consequences are concrete. Stenberg wasn’t alone.
Steve Ruiz, creator of tldraw, auto-closed all external pull requests in January 2026 after the project was overwhelmed by AI-generated contributions — noting that when code is trivially easy to produce and low-quality submissions are nearly indistinguishable from good ones at first glance, the value of external contribution becomes “probably less than zero.”
GitHub itself is now weighing drastic interventions including turning off pull requests entirely for some projects, limiting them to trusted collaborators and deploying AI triage tooling — an extraordinary admission that the contribution model undergirding open source development is under stress.
For enterprise engineering leaders, this is the operational risk: the maintainers of foundational open source projects are facing sustained, AI-amplified review burdens at exactly the moment when understaffed, underfunded open source maintainer-ship was already at its limit.
The xz Utils backdoor discovered in March 2024 was a case study in what happens when a maintainer is burned out and has no bandwidth left to be appropriately skeptical: a coordinated two-year social engineering campaign by a bad actor nearly inserted a critical remote code execution backdoor into a core piece of Linux infrastructure.
Alex Stamos called it potentially “the most widespread and effective backdoor ever planted in any software product.”
The maintainer wasn’t careless, he was exhausted.
Build your SBOM
The first step for any enterprise engineering leader is visibility. You can’t fix what you can’t see.
A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of the open source and third-party components in your software — direct dependencies and transitive ones.
Think of it as a nutrition label for your software stack.
Executive Order 14028 from 2021 made SBOMs a requirement for software sold to the federal government; CISA published updated minimum SBOM elements in 2025, establishing the baseline for enterprise adoption.
Despite this, nearly half of organisations still don’t have a mature SBOM practice.
Tools like GitHub’s built-in dependency graph, SPDX and CycloneDX provide the formats. Snyk, Black Duck and Anchore offer enterprise tooling to generate and maintain SBOMs across complex codebases.
Knowing that you have curl as a second-order dependency of your AWS SDK integration, your Kubernetes cluster and your internal API tooling means you’re not scrambling when Stenberg’s inbox produces a real critical CVE.
Monitor what you’re running
Once you understand your dependencies, you can use that visibility to understand your performance.
Monitoring your own applications is not enough, you need to connect the dors across the entire value chain, including cloud and SaaS providers.
Often, you’ll see issues, degradations and non-conformant results before you’ll get an alert from an open source project.
Understanding what is affected helps you determine the root cause and course of action in the middle of an incident.
Putting engineers upstream
The most durable form of enterprise support is employment. Red Hat, Google, Microsoft and Meta each employ engineers whose full-time job is contributing to open source projects that those companies depend on.
For most enterprises, the full Red Hat model isn’t realistic, but a version of it is: designating a 5-10% portion of engineering bandwidth for upstream contributions to the open source projects your stack depends on most critically is an investment in your own infrastructure quality.
This has a direct bearing on the vibe coding problem.
When a project has active, engaged maintainers from major consumers, review capacity scales with contribution volume.
When all the consumers are passive and the project is maintained by one or two unpaid individuals, the vibe coding DDoS lands entirely on them.
Materialising risk
The curl bug bounty shutdown is not a footnote.
It is a concrete, measurable degradation in the security research capacity of a library embedded in your infrastructure.
Stenberg can still fix bugs he finds himself.
What he can no longer do sustainably is run the kind of open, incentivised security research program that produced 81 genuine vulnerability fixes over six years.
That gap in coverage is now part of your risk posture, whether or not your SBOM captures it.
The vibe coding wave is not going to slow down. The adoption numbers are unambiguous — 41% of all global code is now AI-generated and that percentage is rising in every category, including open source contributions.
The review burden on maintainers of foundational infrastructure is going to increase.
The question for enterprise engineering leaders is whether you’re going to wait for the next Log4Shell to discover that the maintenance capacity of a library five layers deep in your dependency graph has been quietly hollowing out or whether you’re going to act while the structure is still standing.
The infrastructure that runs your company is mostly open source. The people maintaining it are mostly doing it for free.
And right now, they’re getting buried.
That’s an engineering leadership problem, not just a community one.
