30 CVEs in Two Months: What the Spring Numbers Tell Us About the Future of Open Source Security

Spring had 17 CVEs disclosed in all of 2025. In the last two months alone, it's had 30.

That's not a typo, and it's not an artifact of better detection finally catching up to old bugs. It's a leading indicator of a structural shift in how open source vulnerabilities get found, reported, and triaged — and the people most affected are the maintainers and enterprise security teams who've been operating on assumptions that no longer hold.

Our CEO Aaron Mitchell talked through what's driving this on Techstrong TV with Mike Vizard last week. The full interview is worth fifteen minutes of your time, but if you've only got five, here's the frame.

‍

The asymmetry that's breaking the system

AI-assisted vulnerability discovery is real, and in many cases it's finding real bugs. That's the good news. The harder news is that the same tools have collapsed the cost of generating a vulnerability report — without doing anything to reduce the cost of verifying one.

A maintainer still has to read the report, reproduce the issue, evaluate the actual exploitability in context, and decide what to do about it. That work hasn't changed. What's changed is the volume of inbound reports they have to do it for.

The result is a queue that grows faster than it gets processed. And the people running that queue, in most cases, are doing it on nights and weekends, unpaid, on projects they started as hobbies a decade or more ago.

‍

What this looks like for maintainers

The maintainer-side picture is the part that doesn't get enough airtime in security conversations.

A lot of the most foundational libraries in enterprise software stacks are supported by one or two people. They built something useful. It got adopted. They never signed up to be the security operations center for a Fortune 500 deployment, and yet that's effectively the role enterprise consumption has cast them in.

Add an order-of-magnitude increase in CVE reports — many of which are, charitably, AI slop — and the math stops working. Some maintainers will adapt by adopting the same AI tooling on the defensive side. Some will burn out. Some projects will be quietly abandoned without any announcement, and the consumers of those projects won't find out until a real exploit lands and there's no one to call.

That last failure mode is the one enterprise security teams should be most worried about, because it doesn't show up in any scanner. A library that's silently unmaintained looks identical to one that's actively maintained, right up until it doesn't.

‍

What this looks like for security teams

The dominant model for managing open source risk in the enterprise has been reactive: run an SCA scanner, get a list of CVEs, triage by severity, file tickets for engineering to fix. Repeat on whatever cadence your compliance regime requires.

That model was already strained. The CVE surge is going to break it.

A few things follow from that:

Triage capacity becomes the bottleneck, not patching capacity. When you're getting alerted on dozens of new CVEs per week across your dependency tree, the question isn't whether engineering can patch fast enough — it's whether security can sort signal from noise fast enough to know what to send them. False positives have always been costly; in the new volume regime, they're crippling.

Single-point-of-failure dependencies become a board-level question. "We use Library X, which is maintained by one person who hasn't pushed in six months" used to be an acceptable footnote. It's increasingly not.

The implicit social contract between enterprises and maintainers is breaking. The deal where enterprises consume open source for free and maintainers patch for free was always a bit fragile. AI-assisted CVE generation is the load test that contract was never going to pass.

‍

What comes next

Aaron's read, and ours, is that the next eighteen months will see security teams move away from reactive whack-a-mole and toward a more proactive posture: curated lists of approved libraries, with explicit SLAs attached, and a clear answer to the question who do we call when this breaks?

That's the model we've been operating under from day one. HeroDevs partners directly with open source maintainers to keep older, end-of-life versions of widely-used libraries secure for the enterprises stuck on them — Spring, Angular, Node.js, .NET, Bootstrap, Vue 2, jQuery, Drupal 7, and others. We've also put twenty million dollars into a sustainability fund for the maintainers we work with, because the long-term health of open source can't run on altruism alone.

The point isn't that every library needs a commercial backstop. The point is that if your security and uptime depend on a library, you should know who's on the hook for it — and "the open source community" is not a sufficient answer at enterprise scale.

‍

Watch the full conversation

Aaron and Mike cover a lot more than fits in a blog post: the question of what happens when adversaries get the same vulnerability discovery capabilities, what enterprises should expect (and not expect) from maintainers, and why he's cautiously optimistic about where this lands despite the short-term pain.

▶ [Watch the full interview on Techstrong TV]

If you want our weekly read on what's actually moving in open source security — the CVEs that matter, the maintainer signals worth tracking, and the patches your team should be paying attention to — subscribe to the [OSS Security Brief].

Have questions about how the CVE surge affects a specific library or framework you depend on? [Get in touch] — we're happy to talk through it, customer or not.