Vulnerability programs rarely fail because teams cannot find enough findings. They fail because the organization has not built a reliable way to decide what deserves action first.
I have seen this at enterprise scale: scanners produce more work than remediation teams can absorb, every owner believes someone else’s exception is less justified, and the dashboard rewards closing tickets rather than reducing material exposure. Adding another severity threshold does not fix the operating model.
The leadership question is not “How many critical vulnerabilities do we have?” It is:
Which exposures create the most credible path to material harm, what should we do about them now, and who owns that decision?
CVSS, EPSS, CISA’s Known Exploited Vulnerabilities catalog, and SSVC can help answer parts of that question. None of them can answer it alone.
Start by separating the signals
CVSS describes technical severity
CVSS is useful for describing the characteristics and potential technical impact of a vulnerability. A base score is not a measurement of organizational risk. It does not know whether the affected product is deployed, reachable, business-critical, protected by compensating controls, or capable of producing a meaningful loss scenario.
Treating every CVSS Critical finding as an emergency creates predictable failure: the queue becomes larger than available capacity, exceptions become routine, and the word “critical” stops changing behavior.
EPSS estimates exploitation probability
The Exploit Prediction Scoring System estimates the probability that exploitation activity for a CVE will be observed in the next 30 days. It is updated daily and grounded in empirical signals.
That makes EPSS valuable for distinguishing likely attacker attention from theoretical exploitability. It still does not know whether the vulnerable instance exists in your environment or what exploitation would cost the organization. FIRST is explicit that EPSS is not a complete risk score.
KEV provides evidence of known exploitation
The CISA Known Exploited Vulnerabilities catalog answers a narrower but powerful question: has the vulnerability met CISA’s criteria for known exploitation in the wild?
Presence in KEV should create a strong response signal, especially for exposed and high-impact assets. Absence from KEV is not proof of safety; catalogs have visibility and timing limits.
SSVC structures the response decision
Stakeholder-Specific Vulnerability Categorization uses a decision tree to connect factors such as exploitation status, technical impact, mission impact, and exposure to outcomes such as Track, Track*, Attend, or Act.
Its strength is not that it produces one more score. It makes the reasoning visible. Its weakness is that contextual inputs require governance. If asset impact, exposure, or control effectiveness is guessed inconsistently, the decision tree only makes inconsistent assumptions look formal.
Combine evidence without creating score soup
A practical decision flow looks like this:
- Confirm applicability. Is the vulnerable component actually present, and is the detection trustworthy?
- Map exposure. Is the instance internet-facing, reachable from a likely attack path, or isolated behind effective controls?
- Assess attacker evidence. Is it in KEV? What does EPSS indicate? Is reliable exploit intelligence available?
- Assess consequence. What data, service, safety, financial, or regulatory outcome could follow exploitation?
- Choose the response. Patch, mitigate, isolate, monitor, accept, or retire—with an owner and a deadline.
- Verify the result. Confirm that the exposure changed, not merely that a ticket closed.
The same CVE can reasonably produce different actions on different assets. That is not inconsistency; it is context. The inconsistency to eliminate is applying different reasoning to comparable exposures because separate tools, teams, or executives use different hidden rules.
What leadership must put around the model
Metrics do not create accountability. A functioning program still needs:
- A common asset and service ownership model
- Defined decision rights for emergency changes and risk acceptance
- Remediation targets tied to risk tiers, with an exception path that expires
- Capacity planning with infrastructure and application teams
- Evidence that compensating controls work as assumed
- Measures of exposure reduction, recurrence, and time at risk—not only ticket closure
This is where vulnerability management becomes a management system. Security supplies evidence and challenge. Technology owners bring operational reality. Business leaders own material risk decisions. The program makes those decisions repeatable and visible.
The test I use
Ask a security leader, an application owner, and an infrastructure leader to independently explain why the top five items are the top five. If their answers depend on different dashboards or private judgment, the organization does not yet have a prioritization model—it has competing queues.
Lessons learned
Operating large programs changed what I optimized for. More scan coverage and more score thresholds improved detection and sorting, but neither gave security and technology teams a shared reason to act. The missing piece was a decision process connecting the technical evidence to exposure, consequence, ownership, capacity, and a verified response.
I am not looking for one perfect score. I want a process that directs limited engineering time toward the exposures most likely to matter, records its assumptions, and can change course when those assumptions fail. A useful test is to sample the top decisions across teams, trace each one to the evidence and policy behind it, and confirm that the chosen response actually reduced exposure.
That is how a program stops playing whack-a-mole: not by swinging faster, but by deciding where action reduces the most risk.
For an executive review, I use the questions in What Executives Should Demand from Vulnerability Prioritization to challenge that process without pretending every leader needs to inspect the scoring mechanics.
If you asked security, application, and infrastructure leaders to explain the same five priorities today, where would their reasoning diverge—and what governance change would close that gap?
Sources and disclosures
- FIRST: CVSS v4.0 specification
- FIRST: using EPSS
- CISA Known Exploited Vulnerabilities catalog
- CISA Stakeholder-Specific Vulnerability Categorization
This is an independent analysis based on the author’s enterprise vulnerability-management experience and the cited public frameworks. It is not affiliated with or endorsed by FIRST or CISA, and it does not disclose employer, customer, or proprietary scoring details.
