Curated Open Source: What Replaces Reactive SCA Scanning in the AI-CVE Era

For about a decade, the dominant model for managing open source risk in the enterprise has been a variant of the same loop: ingest dependencies freely, run an SCA scanner against them, get a list of CVEs, triage by severity, file tickets for engineering, repeat. Software composition analysis tools made it possible to manage open source at scale by treating the security problem as a downstream alerting problem.

That model was already strained before AI vulnerability discovery hit. Now it's breaking, and security leaders are starting to think hard about what comes next.

This is a piece about what replaces it. Specifically: a shift from reactive scanning toward what we'll call curated open source — a posture where enterprises consume from a deliberately narrowed set of libraries, each with explicit ownership, support, and SLAs attached. It's not a new idea, but the AI-CVE surge is accelerating it from a niche practice into something every CISO is going to have to take seriously over the next eighteen months.

‍

Why the reactive model is breaking

Three things have changed at once, and any one of them would have stressed the reactive model. Together, they're breaking it.

CVE volume has decoupled from real risk. The total number of CVEs disclosed has roughly doubled in five years. The number of unscored CVEs has grown 37x, according to Sonatype's 2026 State of the Software Supply Chain report. AI-assisted vulnerability research, including the recent release of Claude Mythos, will accelerate that trend. The signal-to-noise ratio in your CVE feed is getting worse, not better.

Maintainer capacity hasn't scaled. Most of the libraries running in your stack are maintained by one or two people, often unpaid. Their attention is now being eaten by triage of inbound AI-generated reports — much of which is what the security community has started calling "AI slop." We covered this in detail in our explainer on AI slop and the verification bottleneck post.

Scanners can't see what they aren't told to look for. SCA tools depend on the upstream CVE record. When a CVE doesn't list your version in the affected range — common for end-of-life versions — your scanner shows green even though you're vulnerable. Our Principal Product Manager Isaac Wuest covered this in detail in The EOL Blind Spot in Your CVE Feed. HeroDevs research suggests roughly 80% of CVEs disclosed on supported versions also affect EOL versions that aren't formally listed.

Stack those three together and the reactive model produces a lot of motion without producing much security. Teams spend more time triaging false positives, miss real exposure that scanners can't see, and operate downstream of a maintainer ecosystem that's getting less reliable, not more.

‍

What curated open source means in practice

Curated open source is the inverse of the reactive model. Instead of consuming any library that solves a problem and managing risk after the fact, the enterprise narrows what it consumes upfront, with explicit security criteria attached.

This isn't about banning open source. Open source remains the foundation of modern software, and that's not going to change. It's about being deliberate about which open source you depend on, and what your fallback is when something goes wrong.

A curated approach generally includes some combination of:

An approved-libraries list with explicit ownership. For each library in your stack, who's on the hook to verify, patch, and support it? "The community" is not a sufficient answer for libraries that are critical to your business. Either the community has demonstrated capacity (a foundation behind it, multiple paid maintainers, a track record of timely security response) or the library needs commercial backing.

SLAs on critical dependencies. For libraries that, if compromised, would materially affect your business, treat them like any other vendor relationship. There should be a defined response time for security issues, a defined patch delivery mechanism, and a contractual fallback. That generally means commercial support — either from the project's foundation, a vendor offering long-term support, or a specialist provider for end-of-life libraries.

Visibility into maintainer health. This is newer and less well-developed, but increasingly important. Tools and signals that tell you whether a maintainer is active, whether the project is responding to reports, whether the bug bounty is open or closed. A library where the bug bounty just shut down because of AI slop overload is a different risk profile than one where it didn't.

A clearly defined position on EOL versions. Most enterprises run more end-of-life software than they think. Sonatype data suggests 5-15% of components in a typical enterprise stack are EOL, and on npm specifically it's 25% of all package versions. The curated approach forces the question: what's our position on EOL? Are we migrating? Are we paying for extended support? Are we accepting the risk explicitly?

‍

The objection: this sounds expensive

Yes. It is.

The honest case for curated open source isn't that it's cheaper than the reactive model — it's that the reactive model's cost has been hidden in places enterprises have stopped tracking. The cost of an unverified maintainer dependency, a 41-day median time to CVSS scoring, a false negative on an EOL package, or a critical patch that lands six weeks late because the upstream maintainer is buried in slop — these are real costs. They show up in incident response, breach disclosures, regulatory exposure, and customer trust. They just don't show up on the same line item as your SCA tool subscription.

The CISOs who are ahead of this shift are already making the calculation. The question they're asking isn't how do I scan more efficiently — it's how do I narrow my dependency footprint to libraries I can actually defend, and how do I pay for the support I need on the ones I can't replace?

‍

Where this goes

Over the next eighteen months, we expect to see:

• More enterprise procurement processes adding security-support criteria to open source consumption, alongside the license and CVE checks they already run.
• Foundations and commercial vendors filling more of the support gap, as it becomes clear that volunteer maintainer capacity can't scale to AI-era CVE volume.
• Insurance and regulatory pressure moving in the same direction. Cyber insurance underwriters are already asking harder questions about open source dependency support. Expect that trend to intensify.
• A bifurcation of the open source ecosystem into "well-supported, suitable for enterprise dependence" and "use at your own risk." The libraries in each category will move around, and tracking that movement will become a real security function.

This is the strategic shift our CEO Aaron Mitchell talked through with Mike Vizard on Techstrong TV. If you're a security leader trying to figure out what your open source risk posture should look like in the AI era, the full interview is worth your time.

‍

In short

The reactive SCA-and-triage model for managing open source risk is breaking under the combined weight of AI-driven CVE volume, degrading maintainer capacity, and scanner blind spots. The replacement is curated open source: a deliberate posture where enterprises consume from a narrowed set of libraries with explicit ownership, SLAs, and commercial backing where it's needed. It costs more on the line item. It costs less in incident response, exposure windows, and 2 AM phone calls.

If you want our weekly read on what's actually moving in open source security — and the maintainer signals, CVEs, and shifts your team should be tracking — subscribe to the OSS Security Brief.