A dangerous drug is not a poison
Open the leaflet of any common medication: not recommended for pregnant women, contraindicated in heart failure, to be avoided alongside such-and-such treatment. Sometimes an impressive list of warnings. And yet it is prescribed every day to millions of people, safely — because risk never exists in the absolute: it depends on the patient, the dose, the interactions. The physician contextualizes by reflex before deciding.
Software vulnerability management too often does the opposite. It treats every flaw as an absolute poison, when a vulnerability is above all a risk — and a risk is weighed against context data.
The problem: the raw CVE, taken as a verdict
The usual pattern is familiar: you run a scanner, it spits out a list of CVEs, and the analysis is considered done. What remains is a jumble of hundreds or thousands of flaws, ordered at best by their CVSS score.
But the base CVSS measures an intrinsic and theoretical severity — the impact of a successful exploit, under ideal conditions for the attacker. It says nothing about your actual exposure. Its temporal and environmental metrics, designed precisely to adjust that score, are almost always ignored. So you end up steering remediation with an indicator that, by construction, was never meant to measure your risk.
The consequences follow mechanically. The volume becomes unmanageable, and the handful of genuinely dangerous flaws drowns in the background noise. When everything is “critical,” nothing is: prioritization collapses, and you fix tickets at random rather than in order of risk.
For lack of triage, two reflexes set in, each as costly as the other:
- Absorbing the volume. Teams wear down (alert fatigue), engineering time goes up in smoke on noise, and security — from crying wolf too often — loses the credibility that would get it heard.
- Overreacting. You patch everything, right now. But patching isn’t neutral — it’s an intervention that carries its own risk: a poorly assessed fix introduces regressions, breaks a dependency, causes an outage. Fixing in a rush, at the cost of downtime, a flaw that isn’t exploitable in your context: the cure becomes worse than the disease.
Either way, you end up steering by a number — the count of closed CVEs — instead of by real exposure, in a posture dictated by fear or compliance rather than by risk.
Contextualizing: four questions to ask
Getting out of this jumble doesn’t take more scanning, but more context. That context comes down to four questions, whose answers come from different sources — the vendor, your deployment, your stakes, the threat — that no single party holds alone. Cross-referencing them turns a raw list into decisions.
Is the vulnerable component even used? A dependency carrying a CVE doesn’t mean its vulnerable function is reached in your execution path. This answer comes from the vendor, via a VEX (Vulnerability Exploitability eXchange) — a document declaring the flaw’s exploitability within its product (not_affected, affected, fixed…), an assertion intrinsic to the product and therefore portable. Failing that, you can reconstruct it through reachability analysis: an SCA tool traces the call graph and checks whether a path exists to the targeted function — no path, no reachable flaw, no practical harm. Caveat: this analysis may amount to reverse engineering when run against a third-party component’s binary, with the legal limits that implies.
Is the flaw exposed in your deployment? The same CVE doesn’t carry the same weight depending on where and how the component runs. An unauthenticated RCE (Remote Code Execution) on an Internet-facing service has nothing in common with the same flaw on an internal component that is segmented, with the vulnerable option disabled, behind strong authentication. Sometimes the flaw isn’t even applicable: a Windows-specific CVE doesn’t concern a Linux image running in Kubernetes, even if the scanner flags it. Network exposure, runtime platform, configuration, compensating controls: this data can only come from you, because the vendor doesn’t know your architecture. Corollary: it holds only for this deployment and must be re-evaluated for each environment.
Does the affected asset matter to you? A flaw on a secondary service doesn’t weigh the same as one on a system that handles sensitive data or underpins a vital business process. This is the logic of CIA requirements — the level of confidentiality, integrity, and availability demanded of the asset — which CVSS itself incorporates through its environmental metrics (CR/IR/AR) to reweight the base score. That criticality is a matter of your business priorities, and no one else’s.
Is the flaw actually being exploited? External data this time, shared by everyone. EPSS estimates a probability of exploitation within 30 days; CISA’s KEV catalog lists the CVEs whose exploitation is confirmed. These signals redirect effort toward what is actively attacked, not toward what merely shows a high CVSS. To be handled with care, though: EPSS is a probabilistic model calibrated on history, and the AI-driven acceleration of exploit development is shortening timelines to the point of undermining predictions built on the past.
Cross-referenced, these four answers melt the volume away: out of thousands of alerts, only a handful combine reachable code, exposed deployment, critical asset, and confirmed exploitation. Those are the ones you handle first — and without delay.
The counterattack will be agentic
Contextualizing at this level has a cost: gathering data from heterogeneous sources — SBOM, VEX, asset inventory, EPSS, KEV, network topology — cross-referencing it and deciding, flaw by flaw. By hand, it’s untenable; that’s precisely why so many teams give up and fall back on lazy CVSS-based triage. Risk-based vulnerability management then stays a principle everyone approves of without ever applying it.
This is exactly what agentic AI unlocks: an agent queries the sources, reconciles VEX statuses with the actual state of the deployment, flags inconsistencies, and proposes a reasoned triage — with the human keeping the decision. Steering by risk stops being wishful thinking and becomes operable at scale.
And it’s no luxury. The same AI that accelerates exploit development — the one already making EPSS probabilities obsolete — is reshuffling the deck in the attackers’ favor. AI on the attack, AI on the counterattack: in this race, agentic contextualization is no longer a commodity, it’s the condition for staying in the game. The goal was never to patch everything — only to protect what matters, and now, to move fast enough to do it.