.svg)
.svg)
AI will find more software vulnerabilities than ever. The answer cannot be an endless race to the next CVE.
Imagine a maintainer receives dozens of credible security findings overnight. They fix the most important ones, publish a new release, and move on. Then a better AI model scans the same codebase and finds dozens more. The cycle begins again.
This is not a failure of open source. It is the predictable result of making vulnerability discovery dramatically cheaper while the work of changing production software remains difficult.
The next security crisis may not be a shortage of vulnerability intelligence. It may be an endless surplus of it.
AI has changed the economics of finding vulnerabilities
On October 8, Anthropic introduced OSS Scanner, an opt-in service that offers eligible open-source projects periodic vulnerability scans using its strongest models, including Claude Mythos, at no cost. Maintainers can receive model-generated findings, reproducers, and proposed fixes. Those fast-track reports are not individually reviewed by humans, a trade-off Anthropic explicitly acknowledges. [1]
Anthropic reports that its models identified more than 29,000 candidate vulnerabilities across important software projects in six months, while human reviewers were able to triage approximately 6,000. Candidate findings are not the same as confirmed vulnerabilities or assigned CVEs. Even with that caveat, the imbalance is telling: discovery capacity is outpacing review capacity. [1]
*CVEs reported through October 8, 2026; counting methods differ by tracker. Sources: Anthropic and CVEDB. [1, 3]
The public CVE count is also accelerating. One tracker recorded roughly 75,500 CVEs published by October 8, 2026, compared with about 48,000 in all of 2025. GitHub reported that CVE requests through its assigning authority approached 4,000 in May alone, nearly ten times the prior-year level. AI is not the only cause: expanding reporting and assignment systems contribute, too. But the direction is unmistakable. [2][3]
A patch is not the same as protection in production
AI can help maintainers find bugs and write patches. That is genuinely good news. But a patch released by a maintainer is not a patch running in a bank’s production environment. There are pinned dependencies, transitive packages, compatibility tests, maintenance windows, legacy workloads, and approval processes. Some organizations will accelerate this pipeline with AI. Others will still live with exposed versions for weeks or months.
A new report can start the same operational sequence: advisory, assessment, ticket, rebuild, test, deploy—and then another advisory. Making discovery faster does not automatically make remediation instantaneous. The better the scanners become, the less sustainable a defense strategy based only on finding and chasing individual CVEs becomes.
And some exploitable behavior never gets a CVE
A CVE is an identifier assigned through a disclosure process. It is not a universal definition of whether code can be abused in a particular application.
In July 2026, an Apache Log4j maintainer published AI-discovered deserialization hardening findings. The maintainer explicitly described certain filter bypasses as hardening opportunities, not Log4j security vulnerabilities, because safe deserialization of untrusted data was outside the project’s stated threat model. Under some application conditions, the same class of behavior could still form part of a code-execution path. [4]
Raven later reported reproducing one such application-dependent path in an isolated test and blocking its attempted process creation at runtime, without a CVE-specific rule or signature. That is a reported Raven test, not evidence that every possible Log4j exploit—or every CVE-less vulnerability—is covered. The point is more precise: the defense did not need the vulnerability to be named first. [5]
A vulnerability identifier describes a problem. A runtime policy can stop the dangerous action that problem tries to trigger.
From CVE-centric security to runtime truth
The traditional question is, “Which vulnerable packages do we have?” The more valuable question is, “Which components are actually loaded and executing in our production applications—and which vulnerable functions have been observed running?”
That distinction is foundational to Raven Runtime SCA. A library found on disk is not the same as one loaded into memory. A loaded library is not the same as one executing. And executing code is not the same as observing a particular vulnerable function. Runtime evidence helps teams prioritize remediation using the application’s real behavior, not package presence alone. A function not observed during a particular period is not proof that it is unreachable.
This is the natural first step for large enterprises drowning in vulnerability alerts: replace an undifferentiated inventory with a runtime-informed view of exposure.
The next step: CVE-less prevention
Visibility earns trust. Then the question changes. If a deserialization library should never spawn a shell, why wait for the next vulnerability report before restricting that capability? If a parser does not need to contact the internet or read sensitive files, why leave those actions available to it?
Raven’s approach is not to force customers to manage a policy for every library. The customer selects a specific application image. Raven focuses on security-sensitive library families—such as serialization/deserialization, templating, authentication, dynamic execution, and other components with sensitive capabilities—and applies relevant runtime restrictions within the supported scope. The aim is simple: the customer chooses the image; Raven handles enforcement.
The restrictions are behavioral: prohibit an unwanted process launch, an unnecessary outbound connection, or access to a file the library has no reason to touch. These policies can remain useful when new CVEs appear, because their logic depends on prohibited behavior rather than the identifier of a newly discovered flaw.
This does require discipline. Some libraries legitimately need network or file access. Authentication bypasses and logic errors may never produce a sensitive operating-system action to block. Real prevention depends on precise attribution, validated policies, safe rollout, and explicit visibility into coverage. CVE-less does not mean riskless, patchless, or universal protection.
Our forecast: more findings, less dependence on CVEs
Over the next few years, we expect three forces to reinforce one another. AI-assisted research will expose more previously unknown bugs. AI-assisted engineering will shorten some patch cycles, but not uniformly across enterprise production. And attackers will be able to study disclosed weaknesses and automate exploitation attempts faster, increasing pressure on systems that lag behind.
The security market will therefore need two kinds of intelligence simultaneously: runtime exposure intelligence to determine what really deserves attention, and runtime behavioral enforcement to constrain what risky code can do—whether the flaw was assigned a CVE yesterday, has not been reported yet, or may never qualify for one.
We should still use CVEs, fix defects, and update software. But we should stop treating a CVE number as the prerequisite for protection. That dependency is what must end.
The future is not CVE-free. It is CVE-independent.
See what runs. Understand what matters. Control what code is allowed to do. That is how we step off the CVE treadmill.
Explore Raven ADR to see how runtime protection works or book a demo to see it in action.
