Common Vulnerability Scoring System (CVSS) severity tells you how serious a vulnerability could be. Exploit Prediction Scoring System (EPSS) estimates how likely exploitation is in the next 30 days. Neither one, by itself, tells you what your team should fix first.
Run a dependency scan on any moderately sized JavaScript project and you will probably see a table of findings, many of them labeled “high” — 10, 20, sometimes 50 entries. If they all carry the same label, which one gets the next hour of engineering time?
The usual answer is the one with the highest CVSS number. That feels objective, but it uses a severity score as a remediation queue. Those are not the same thing.
The Common Vulnerability Scoring System describes technical severity. Its Base metrics account for characteristics such as attack vector, attack complexity, privileges required, user interaction, and potential impact on confidentiality, integrity, and availability.
A high Base score means the vulnerability has a severe technical profile under the assumptions encoded by CVSS. It does not mean the vulnerable code is reachable in your application. It does not know whether the affected system is exposed to the internet, whether compensating controls exist, or whether exploitation is occurring.
That distinction matters because severity is a property of a vulnerability. Priority is a decision about a vulnerability in context.
Security teams have long added threat intelligence, exploit catalogs, asset data, and vendor-specific risk models to severity scores. But developer-time dependency scanners often collapse the result back into a single severity column. The developer sees an advisory ID and a label, then has to reconstruct the missing context.
The Exploit Prediction Scoring System, maintained by FIRST and updated daily, answers a different question. It estimates the probability that exploitation activity for a published CVE will be observed in the wild during the next 30 days.
EPSS produces both a probability and a percentile. The probability is the model’s direct forecast. The percentile describes where that probability ranks among published CVEs. A CVE at the 93rd percentile has a higher predicted exploitation likelihood than 93% of scored CVEs; it is in the top 7%.
Those numbers are easy to confuse. The 90th percentile does not mean a 90% chance of exploitation. Because exploitation has a low base rate, a CVE can rank near the top of the population while its absolute probability remains only a few percent.
CVSS and EPSS measure different properties, so a high value in one does not imply a high value in the other. That gap is useful. A technically severe vulnerability may have a low near-term exploitation forecast. A medium-severity vulnerability may rank near the top of the EPSS population.
But EPSS is still a forecast. It does not prove that a CVE is being exploited, identify an active campaign, or establish that your application is reachable. Confirmed exploitation requires another source, such as the CISA Known Exploited Vulnerabilities Catalog (CISA KEV) or reliable threat intelligence. These scores face another bigger challenge: if it’s a newly discovered CVE with a high severity score and no EPSS or KEV record, how should it be handled?
Once impact and predicted exploitation likelihood are kept separate, the scan stops being a one-dimensional list. CVE Lite CLI uses four decision lanes:
- Fix Now – Critical or high severity with EPSS at or above the 90th percentile. Both technical impact and predicted exploitation likelihood are elevated, so investigate immediately.
- Fix Soon – Critical or high severity below the 90th percentile. The potential consequences remain substantial, but the EPSS forecast provides less reason to put it in the first lane.
- Monitor – Medium or lower severity at or above the 90th percentile. The severity label is lower, but the elevated forecast means the finding should not disappear into the normal backlog.
- Lower Priority – Medium or lower severity below the 90th percentile. Handle it through normal remediation unless reachability, asset importance, confirmed exploitation, or other local context increases its urgency.
These are decision lanes, not a universal mathematical ranking. A reachable Monitor finding on an internet-facing authentication service may matter more to your organization than a Fix Soon finding in an unused development tool. The lanes tell you which question to ask next; they do not eliminate the need to ask it.
The 90th percentile is also a product default, not a law of vulnerability management. CVE Lite CLI uses it as a deliberately simple boundary that identifies the highest-ranked 10% of CVEs while keeping the elevated queue manageable. FIRST does not prescribe a universal threshold. Teams should adjust policy to remediation capacity,
[…]
Content was trimmed to protect the source. Please visit the original article for the full text.
Read the original article: