Cybersecurity professionals have long been told that visibility is the foundation of protection. If you know which vulnerabilities are being exploited, you know where to focus. Budgets, dashboards, compliance audits, and patching strategies are built around this idea. However, the assumption only holds true if the source of “visibility” accurately reflects reality. Today, it no longer does.
Modern software stacks are inextricably linked to open source. According to the 2025 Open Source Security and Risk Analysis report, 97% of applications include open source components, accounting for roughly 70% of the average codebase and more than 900 components per application. In practice, that means most organizations are dependent on code they did not write, cannot directly control, and may never fully inventory.
As the dependency chain grows, exposure scales with it. Every new library, framework, or imported module offers its own potential attack path, and all attackers need is one.
Why a Catalog of “Known Exploited Vulnerabilities” Can’t Keep Enterprises Safe Anymore
When the U.S. Cybersecurity and Infrastructure Security Agency (CISA) launched the Known Exploited Vulnerabilities (KEV) list in 2021, it addressed an urgent need: distinguishing between theoretical CVEs and those confirmed to be exploited in the wild. The emergence of KEV allowed security teams to prioritize what was actually dangerous rather than what was merely possible.
In that era, KEV represented progress. In today’s era, it represents latency.
Miggo Security’s recent research reveals a reality the industry has been reluctant to confront: KEV represents a minority of genuine exploit risk. After analyzing more than 24,000 open source vulnerabilities from the GitHub Security Advisory (GHSA) database, Miggo’s research team identified 572 vulnerabilities with at least one GitHub-hosted exploit repository.
Only 69 of those 572 exploits appear in KEV.
The miss isn’t selective; it’s structural. Among the verified exploit set:
- 407 weaponized or fully functional exploits were identified
- 165 were proof-of-concept exploits
KEV recorded only 68 of the 407 functional exploits, and just 1 of the 165 proof-of-concept exploits. This isn’t a rounding error. It is evidence that organizations relying heavily on KEV are blind to most of the weaponized exploits that already exist in public repositories.
Exploitation Has Outgrown Verification
Miggo defines the discrepancy as the KEV Gap, the distance between what is actively exploitable and what the KEV catalog recognizes. That distance increasingly widens due to a converging set of pressures, which Miggo identifies as the Four Vs of modern exploitation: Volume, Variants, Velocity, and Visibility.
The most destabilizing of the four is velocity. Exploitation used to unfold over months. Then weeks. According to Miggo, AI-assisted threat actors can weaponize vulnerabilities within minutes of their disclosure. The speed of exploitation has surpassed the speed of verification, and KEV is fundamentally a verification-based system.
KEV can only include vulnerabilities that have been confirmed to be actively exploited. But attackers aren’t waiting for confirmation to strike. They simply use the publicly published exploit code, and there is no requirement for a breach to be reported or validated before the attack is executed.
This forces a question the industry has avoided for years: If exploitation is fully automated and confirmation is not, how can a confirmation-based defense model survive?
Defense Shifts From Classification to Prevention Inside the Runtime
Miggo’s answer is not to fix KEV but to replace the role KEV has been filling. The company proposes a proactive runtime defense model, technology that operates inside live applications to determine whether a vulnerability is exploitable in that specific environment and automatically deploys AI-generated virtual patching to block the attack path.
In this model, mitigation doesn’t depend on:
- a CVE being published
- KEV listing it
- a patch being issued
- incident confirmation
Instead, runtime security uses application behavior, data flow, and execution paths to stop exploits the moment they occur, whether documented or not.
Miggo states that this reduces time-to-mitigation from weeks or months to seconds, buying engineering teams breathing room to apply permanent patches rather than firefight production attacks.
The New Boundary of Cybersecurity Is Where Code Runs
Miggo isn’t arguing that KEV should disappear; it argues that KEV can no longer anchor risk strategy. KEV was built for a world where exploitation was manual. Exploitation is not manual anymore.
The calculus has changed. Organizations are flooded with vulnerabilities. Attackers exploit at machine speed. AI models are embedded directly in software systems. Static lists were never designed for this environment.
Miggo’s research points to an uncomfortable but necessary evolution: cyber defense must move from identifying vulnerable code to interrupting exploitable behavior inside the runtime itself. Software is now dynamic, and risk is, too. It follows that protection must also be dynamic.
