The Open Source Doomsday Paradox

Every CVE announcement makes open source stronger. And yet, for thousands of packages sitting beneath your stack, nobody is watching. Perhaps the most rational move is to stop trusting the commons and just build what you need yourself.

There is a widely held belief in engineering circles that open source software is, by its nature, more secure. Thousands of eyes on every line of code. Transparent changelogs. Rapid CVE patches. This belief deserves scrutiny. Because in 2025, there were 48,185 CVEs published in a single year. That is 133 new vulnerabilities, every single day, flooding into the ecosystems your production systems depend on.

01 / THE NUMBERS

A flood that never stops

Let us start with the raw scale of the problem. The vulnerability landscape is not stabilizing. It is accelerating. In 2024, NIST's National Vulnerability Database recorded 39,962 CVEs. In 2025, that jumped to 48,185, a year-on-year increase of 20.6%. GitHub's own security advisory pipeline grew 35% in the same period, outpacing the broader CVE Project's growth rate.

The gap between exploitation and patching is the critical attack window. Attackers reach a system in 5 days on average. Organizations patch in 32 days. That 27-day window is not a bug in the system. It is the system. And it is a window that your open source dependencies are holding open for you, involuntarily, every time a new CVE drops.

Critical signal

In November 2025, 142,256 malicious npm packages were identified in a single month, 26x the monthly average. Amazon Inspector called it "one of the largest attacks ever seen in open-source registries." These packages had no CVE identifiers. Traditional scanners were blind to all of them.

Here is what that last point means: the CVE system, the very mechanism that is supposed to make open source trustworthy, was not even covering the largest wave of open source attacks in 2025. The vulnerability map and the actual attack surface have diverged.

02 / THE DEPENDENCY PYRAMID

Nobody is watching the middle

Open source is not a flat field of well-maintained packages. It is a pyramid. A small number of flagship projects attract corporate sponsors, dedicated security teams, and intense scrutiny. Below them sits something far more precarious.

The XZ Utils attack in 2024 did not go for the top. It went for the middle, precisely where scrutiny is lowest and impact is highest. An attacker spent two years building trust with project maintainers before inserting a sophisticated backdoor into a compression library present in virtually every Linux distribution on earth. Nobody noticed until a Microsoft engineer realized his SSH logins were 500 milliseconds slower than they should have been.

The Linux Foundation's State of Global Open Source 2025 report found that 83% of enterprises consider OSS adoption valuable, yet only 29% have hired or designated full-time in-house OSS maintainers. Everyone is consuming the commons. Almost nobody is contributing to it.

03 / HALL OF CATASTROPHES

The ones that should have changed everything

The history of open source security is a history of near-misses that should have been lessons. They were not. Each incident prompted patches, blog posts, calls for reform, and then a return to the same dependency patterns.

"The XZ attack didn't exploit the top of the dependency pyramid. It exploited the middle, exactly where nobody was looking."

Cloud Odyssey analysis, February 2026

04 / THE PARADOX

CVEs make open source safer. They also prove it wasn't.

Here is the argument for open source security: every CVE that gets disclosed is evidence the system is working. The bug was found. It was documented. It was patched. Compare that to closed-source software where vulnerabilities hide in vendor-controlled codebases with no external scrutiny. In that framing, CVE volume is a health indicator, not a death sentence.

This argument is genuinely correct. And it is also dangerously incomplete.

The paradox, precisely stated

The CVE system works for the packages that have enough maintainer attention and community engagement to actually run through disclosure and patching cycles. For the thousands of under-maintained packages in the Tier 2 and Tier 3 of the dependency pyramid, CVEs are not discovered because nobody is looking. The absence of CVEs is not security. It is invisibility.

There is a second dimension to this paradox. As vibe coding accelerates software production, the human capital that maintains open source is being eroded. A January 2026 working paper by economists Koren, Békés, Hinz, and Lohmann titled "Vibe Coding Kills Open Source" modeled what happens when AI agents, rather than human developers, select and assemble packages: widespread vibe coding reduces OSS provision and lowers overall welfare, even as software output rises.

The mechanism is straightforward. Maintainers depend on a mix of direct contributors, bug reporters, and community engagement for sustainability. Vibe-coded software consumes packages without contributing back. Bug reports from AI-generated code are often hallucinated or inaccurate. In January 2026, Daniel Stenberg shut down curl's bug bounty program, which had been running since 2019 and had paid out over $90,000 for 81 genuine vulnerabilities. It was killed because AI-generated, largely fabricated vulnerability reports had flooded the system. By late 2025, fewer than 5% of incoming reports were accurate.

curl runs on an estimated ten billion devices. The AWS SDK for C++ uses libcurl as its core networking dependency. The sustainability of a library protecting ten billion connections is being undermined by noise.

05 / THE ALTERNATIVE

Just vibe code the package you need

The heretical idea

What if the answer to open source supply chain risk is to stop using the supply chain for small, well-defined problems?

Vibe coding, the practice of describing intent to an LLM and letting it generate implementation, changes the cost equation for custom code. Writing a bespoke CSV parser, a lightweight retry mechanism, or a simple JWT validator is no longer a significant investment. The question shifts from "should I build or buy?" to "is this dependency worth the attack surface it introduces?"

The security argument for writing your own targeted implementations is not new. For years, security-conscious teams have advocated for zero-dependency or minimal-dependency approaches in critical code paths. What vibe coding changes is the cost side of the equation.

The case for this approach is strongest when the problem space is narrow and well-defined. A retry utility. An input sanitizer. A rate limiter. A simple queue. These are components where the behavior contract is small enough that a generated implementation can be read, understood, and owned by the team that ships it. There are no transitive dependencies. No maintainer burnout risk. No surprise CVEs at 2am.

The case weakens as complexity grows. Cryptographic implementations, parsers for complex formats, network stacks, database drivers. These are domains where subtle correctness matters enormously and where community-vetted implementations carry genuine value. Writing your own TLS library in an afternoon is not a security posture. It is a vulnerability in waiting.

Comparing the models honestly

Open source is not doomed. Your dependency hygiene might be.

The CVE flood does not mean open source has failed. It means the model of uncritical dependency consumption, pulling in packages without understanding their maintenance health, their transitive graph, or their update cycle, is no longer a viable default.

The engineers who built the internet on open source were right that transparency and community scrutiny improve security over the long run. What they did not fully anticipate was a world where a single attacker could spend two years building social capital in a project before inserting a backdoor in test files, or where AI tools would flood maintainer inboxes with fabricated vulnerability reports until the humans gave up.

The practical framework

For narrow, well-defined utilities: evaluate whether a vibe-coded, zero-dependency implementation is more defensible than pulling a package with an uncertain maintenance future and a transitive dependency graph you will never fully audit. For complex, domain-specific components: use battle-tested open source. Contribute back. Fund maintainers. Treat your SBOM as a living risk document, not a checkbox. Check whether a package's primary maintainer is one burnout episode away from becoming an attack surface. For everything: stop treating the absence of a CVE as evidence of security. Invisibility is not safety.

The open source doomsday is not arriving in the form of a single catastrophic vulnerability. It is arriving gradually, as the communities that maintain critical infrastructure shrink, as AI-generated noise overwhelms human reviewers, and as the dependency pyramid grows taller and less examined at its base.

The response to that is not to abandon open source. It is to become a more deliberate consumer of it, and to recognize that sometimes the most secure package is the one you wrote yourself this afternoon and can read end-to-end before you ship it.

The commons needs tending. Until more of us tend it, the smartest move for some of your code might be to step outside the commons entirely for the pieces small enough to carry yourself.

---

#OpenSource #CyberSecurity #CVE #SoftwareSecurity #SupplyChainSecurity #VibeCoding #DevSecOps #SBOM #SoftwareEngineering #AppSec #TechLeadership #DeveloperProductivity #AICode #Infraloka #IndonesiaTech #CloudSecurity #ZeroDependency #XZUtils #Log4Shel l#OpenSourceSustainability