A severity score tells you how bad a flaw could be. It does not tell you whether an attacker can reach it, whether anyone is using it, or what it would give them. Teams that sort remediation by severity alone end up patching what scores high and leaving open what actually gets exploited.
The gap the data shows
Verizon’s most recent Data Breach Investigations Report puts the problem in numbers. Exploitation of vulnerabilities overtook stolen credentials as the most common way into a breach, at 31% of breaches in the study period. In the same report, only 26% of vulnerabilities in CISA’s Known Exploited Vulnerabilities catalog were fully remediated across the organizations measured, down from 38% the year before. The median time to full remediation rose from 32 days to 43.
Read those together. Attackers are using vulnerabilities more, and defenders are closing the proven ones more slowly. The cause is rarely a lack of scanning. Most organizations know about far more flaws than they can fix. The weakness is in choosing which few matter first, and in how quickly those few get closed.
What a severity score does and does not say
CVSS measures the intrinsic severity of a vulnerability. That is useful, but FIRST, which maintains the standard, is explicit that a Base score is only one part of the picture. CVSS v4.0 organizes metrics into Base, Threat and Environmental groups, plus a Supplemental group that adds context without changing the score. It defines four score combinations, from Base alone to Base with Threat and Environmental context, so that the score can reflect your situation rather than the average one.
In practice many programs still sort by the Base number. A critical Base score on a system that cannot be reached or that holds nothing of value then outranks a moderate flaw on an exposed system with privileged access. The ranking is tidy and wrong.
Signals that add what severity lacks
No single signal settles priority. Each answers a different question and has a blind spot.
| Signal | What it tells you | What it misses |
|---|---|---|
| CVSS Base | How severe the flaw is in general. | Reachability, exploitation, and your environment. |
| CISA KEV catalog | The vulnerability has been exploited in the wild. CISA binding directive BOD 22-01 requires federal civilian agencies to remediate listed items by set dates. Others can use it as a high-confidence list. | It is not exhaustive. Absence from the list does not mean a flaw is safe. |
| EPSS | A probability that exploitation activity will be seen in the next 30 days, published by FIRST. | A prediction, not a fact. It knows nothing about your assets. |
| SSVC | A decision tree that combines exploitation status, technical impact and mission relevance into an outcome of Track, Track*, Attend or Act. | Needs inputs about your own environment, which many teams do not have. |
| LEV (proposed) | A NIST and CISA white paper proposes a metric estimating the probability that a vulnerability has already been exploited. It could check EPSS and the completeness of KEV. | Presented as a proposal. Its authors say industry work is needed to measure how well it performs. |
The first three are the practical core. KEV says what is already being used. EPSS says what is likely to be used soon. SSVC turns those and your own context into an action.
Five links between a flaw and a loss
The useful way to read a vulnerability is as the first link in a chain. Whether it becomes a business problem depends on the rest of the chain. These five questions are the ones to answer for any flaw that might be urgent.
| Question | What you are checking | Where the answer comes from |
|---|---|---|
| 1. Can it be reached? | Is the vulnerable service exposed to the internet, a partner network or only an isolated segment? | External attack surface data, network reachability |
| 2. Is it being used? | Is it in KEV, tied to active campaigns, or scored as likely to be exploited? | KEV, EPSS, threat intelligence |
| 3. What does it give an attacker? | Code execution as what account? What does that account reach? | Identity and privilege data, configuration |
| 4. What sits behind it? | Does it lead to a system or data the business cannot lose? | Crown jewel and data criticality mapping |
| 5. What already limits the damage? | Do segmentation, monitoring or recovery capabilities actually work, as tested? | Control validation, detection testing |
A flaw that fails the first link, with no route to it, can wait. A flaw that passes the first three and leads to a critical asset is an emergency regardless of its score.
Two flaws, one decision
This is a hypothetical scenario for illustration.
A scan returns two items. The first is rated critical, in a reporting tool that sits on an internal segment, accessible only to a handful of staff, with no known exploitation and no privileged account behind it. The second is rated medium, in a remote access service on the internet edge. It is listed in KEV, and the service runs under an account that can reach the identity infrastructure.
A severity-sorted queue handles the first one first. The five questions reverse that order. The second flaw is reachable, being used, powerful and close to something critical. It needs action outside the normal cycle. The first can follow the regular patch schedule.
This is also why edge devices matter so much. They are exposed by design, they often run with high privilege, and the same exposure that makes them useful makes them targets. Programs that keep an accurate view of what is facing the internet are far better placed to see these cases, which is the job of external attack surface management.
Where this breaks down in practice
-
No asset ownership. Priority means little if nobody owns the system. Many delays are really search time for the person who can approve a change.
-
Unknown exposure. If your inventory misses internet-facing assets, the reachability question gets the wrong answer. Unmanaged and forgotten systems are the usual reason.
-
Compensating controls that were never verified. Teams defer fixes because a web application firewall or segmentation “should” cover the risk. If that has not been tested, treat it as an assumption.
-
Change windows and fragile systems. Some systems cannot be patched quickly. The decision then becomes mitigation, isolation or accepted risk, and it needs a named owner and a review date.
-
Exceptions that never expire. An accepted risk without an end date turns into a permanent gap.
Treat remediation as a decision, not a queue
A single severity-driven SLA treats all high scores alike. A tiering that follows the five questions reflects actual exposure. This is a recommended structure, and the timeframes should match your own change capacity and risk appetite.
| Tier | Typical conditions | Response |
|---|---|---|
| Emergency | Reachable, actively exploited, and leads to privileged access or critical assets. | Act outside the normal cycle. Mitigate first if a full fix takes longer. |
| Urgent | Exploited or likely to be, and either reachable or tied to sensitive assets. | Fix in the next available change window. |
| Planned | High severity but not reachable, not exploited, and with limited access behind it. | Fix on the regular schedule. |
| Accept or monitor | Low exposure and low consequence, or no fix is available. | Record an owner, a compensating control and a review date. |
What to measure instead of counts
Totals of open vulnerabilities rise with scanner coverage, so a bigger number can mean better visibility. Measures that reflect exposure are more informative:
-
Time to remediate for flaws that are both exploited and reachable.
-
Share of KEV-listed vulnerabilities on internet-facing assets that are fixed or mitigated.
-
Number of exceptions past their review date.
-
Share of internet-facing and critical assets with a named owner.
-
Recurrence: how often the same class of flaw returns after being closed.
The recurrence measure points to a larger issue. If the same weakness keeps coming back, the problem is in how systems are built or deployed, and remediation governance needs to address the cause, not the instance.
Using this article
Take the latest scan and re-rank the highest-rated findings with the five questions in place of the Base score. Count how many of your top ten change position. If several do, your queue was ordered by severity and not by risk, and the fastest improvement available is to change the ordering rule.
Sources
1. Verizon, Data Breach Investigations Report. https://www.verizon.com/business/resources/reports/dbir/
2. CISA, Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
3. CISA, Binding Operational Directive 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities. https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities
4. FIRST, Common Vulnerability Scoring System v4.0. https://www.first.org/cvss/v4-0/
5. FIRST, Exploit Prediction Scoring System (EPSS). https://www.first.org/epss/
6. CISA, Stakeholder-Specific Vulnerability Categorization (SSVC). https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
7. NIST, CSWP 41, Likely Exploited Vulnerabilities: A Proposed Metric. https://csrc.nist.gov/pubs/cswp/41/likely-exploited-vulnerabilities-a-proposed-metric/final
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionManage Cyber Risk & ExposureKnow what attackers can reach and what it would cost.See how we work →Related service
Vulnerability & Exposure Management
Use this to prioritize vulnerabilities by real exposure.