Shift from CVE counts to risk-based vulnerability management in the AI era

Artificial intelligence is rapidly shrinking the window between vulnerability discovery and active exploitation, forcing a fundamental shift in how engineering teams manage security debt. As software volume expands and attack automation improves, traditional spreadsheet-based tracking of Common Vulnerabilities and Exposures (CVEs) no longer provides an accurate picture of organizational risk.

What happened

The traditional model of vulnerability management has remained largely unchanged for years: scan code, identify CVEs, assign severity scores via the Common Vulnerability Scoring System (CVSS), and hand the list to developers for remediation. This approach assumed that technical severity correlated directly with business risk. However, the current landscape reveals a growing gap between the number of vulnerabilities security teams can identify and the number they can meaningfully investigate and fix.

This gap is widening because AI is accelerating both software production and attack sophistication. While vulnerability density per line of code might decline, the sheer volume of software being generated is increasing overall exposure. Simultaneously, attackers use AI to automate tasks that previously required significant manual effort, combining vulnerabilities in unpredictable ways to create new attack paths. The result is that organizations are drowning in data but starving for context, leading to what some experts call "CVE theater," where teams measure activity rather than actual risk reduction.

The core issue is that a CVE indicates a publicly identified flaw exists, but it does not indicate whether that flaw is exploitable in a specific environment. Two organizations may have the same CVE, but if one has the vulnerable component behind multiple security layers with no external exposure, while the other runs it in an internet-facing production app, their risk profiles are vastly different. Treating them equally wastes engineering resources on low-risk items while leaving critical exposures unaddressed.

How it works

To close this gap, security programs must move from static severity scoring to contextual, continuous risk assessment. This begins with reducing the vulnerability footprint before deployment by using hardened base images and curated language libraries. First-party code is secured through Static Application Security Testing (SAST) and AI-assisted scanning, while configuration weaknesses are addressed using frameworks like Security Technical Implementation Guides (STIGs). These automated checklists identify issues such as excessive privileges or weak authentication, which can be as dangerous as code vulnerabilities.

Crucially, the focus shifts to scanning what is actually running in production, as registries and repositories only reflect perceived risk. Production environments change constantly, so continuous visibility is required. Tools perform reachability analysis to determine if a vulnerable code path is actually executed and if the system is externally accessible. This environmental context allows teams to distinguish between theoretical vulnerabilities and those that present immediate, actionable threats.

Finally, remediation priorities are set by combining threat intelligence signals, such as CISA’s Known Exploited Vulnerabilities catalog and the Exploit Prediction Scoring System (EPSS), with production exposure data. This creates a dynamic model that answers which vulnerability should be fixed first, in this specific environment, and why, rather than relying on a static list sorted by CVSS score.

Key details

• AI accelerates exploit development, shrinking the time between vulnerability disclosure and active attack.
• CVSS scores measure technical severity but do not account for environmental exposure or exploit likelihood.
• "CVE theater" occurs when teams prioritize closing high volumes of findings without reducing consequential risk.
• Production scanning provides the source of truth for what is actually deployed and running.
• Reachability analysis determines if vulnerable code paths are executed and if systems are externally accessible.
• Threat intelligence sources like KEV and EPSS help estimate the likelihood of exploitation within a timeframe.

Why it matters

For software engineers and technical leads, this shift means moving away from reactive, volume-based remediation toward a more strategic, risk-based approach. The old model of handing developers a spreadsheet with thousands of CVEs is unsustainable in an AI-driven threat landscape. It leads to alert fatigue and misallocated resources, where critical bugs are buried under noise. By focusing on context, teams can reduce the cognitive load on developers and ensure that remediation efforts target the flaws that actually matter to the business.

Furthermore, this approach aligns security goals with operational reality. Understanding which doors are open, which ones an attacker can reach, and which lead to critical assets allows for better decision-making. It transforms security from a bottleneck into a continuous improvement process. As Russ Andersson notes, "We need to know which doors are open, which ones an attacker can reach, which ones lead somewhere important, and which ones represent the greatest risk right now."

What you can do

• Replace static CVSS-based prioritization with risk models that include production exposure and reachability data.
• Implement continuous production scanning to maintain visibility into what is actually running in your environment.
• Use hardened base images and curated libraries to reduce the initial vulnerability footprint of applications.
• Integrate threat intelligence feeds like CISA KEV and EPSS to gauge the likelihood of active exploitation.
• Automate configuration checks using STIGs to identify and remediate security weaknesses in settings and privileges.
• Establish temporal discipline by defining different remediation windows for vulnerabilities based on their real-world risk level.