Knowing which vulnerability to fix first
InfoWorld ·
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. What CVSS actually measures 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. What EPSS adds 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? The four decision lanes 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, exposure, and risk tolerance. A real scan changes the conversation A CVE Lite CLI case study of the Lit repository shows why two signals are more useful than one. The scan found a critical form-data vulnerability associated with CVE-2025-7783 and a medium-severity Karma finding associated with CVE-2022-0437. In the EPSS snapshot used for the study, CVE-2025-7783 ranked at approximately the 77th percentile. CVE-2022-0437 ranked above the 96th percentile. The exact values will move because EPSS updates daily, but the decision pattern remains instructive. A severity-only table pushes the Karma finding far below the critical item and invites the developer to ignore it. The combined model does something more honest. It places the form-data vulnerability in Fix Soon because of its critical technical severity, while surfacing the Karma vulnerability in Monitor because of its unusually elevated exploitation forecast. It does not pretend that either label is the final answer. It makes both findings visible for different reasons. The next questions are environmental. Is the affected package present in a production path? Is the vulnerable function reachable? Is the system exposed? What would exploitation affect? Has CISA or another trusted source confirmed exploitation? A scanner that cannot answer those questions should not imply that it has. From score to developer workflow I implemented this model in CVE Lite CLI v1.33.0 as the EPSS Priority Signal. For an advisory with multiple CVE aliases, the tool uses the highest available EPSS percentile so that a lower-scoring alias does not hide the stronger forecast. The result appears in the verbose terminal table, the HTML report, and the prioritySignal field in JSON output. The implementation matters less than where it appears. A probability buried in a JSON response does not help a developer facing 20 findings. The combined signal has to reach the terminal output, remediation plan, and CI policy at the moment a dependency decision is being made. That does not mean every Fix Now finding should automatically block every release. A defensible CI policy can use Fix Now as one blocking condition while treating a CISA KEV match, confirmed reachability, or a critical production asset as independent reasons to stop. Monitor and Lower Priority findings can flow into tracking unless local context raises them. This is a better model than blocking on every high-severity advisory. A gate that produces constant noise will eventually be bypassed. A gate that explains why a finding is elevated, and which additional evidence can override the default, is easier to trust. A research direction At Colorado State University , researchers are exploring where this model can go further. Rakesh Podder , Viktoria Koscinski, and Indrajit Ray developed CAPE (Context-Aware Prioritization Engine), a framework that enriches each CVE with deployment-specific evidence — reachability, centrality, and exploitability analysis — producing a ranked priority score using Analytic Hierarchy Process (AHP). Evaluated across 30 open-source projects and over 6,000 scanner-reported CVEs, their findings show that 43.3% of scanner-reported CVEs are statically unreachable (53.1% for TypeScript and JavaScript; 27.4% for Python). In the most extreme case, that rate reached 76.1%. I am collaborating with the CSU team to explore incorporating these contextual signals into CVE Lite CLI’s prioritization model, moving from forecast-based tiers toward deployment-aware scoring that accounts for reachability and effort distribution. The underlying principle CVSS is not wrong. It is being asked to do too much. A severity score can describe technical characteristics and potential impact, but it cannot serve as a threat forecast, an asset inventory, a reachability analysis, and a business decision all at the same time. EPSS supplies one of those missing dimensions: a dynamic forecast of exploitation likelihood. CISA KEV supplies confirmed exploitation evidence. Application and asset context supply presence, reachability, and consequence. Good prioritization comes from keeping those signals distinct and combining them deliberately. The right place to surface that combination is developer-time tooling: the scanner that runs locally or in CI while the developer can still change the dependency. A weekly dashboard is useful for governance, but it is not the moment when the code decision happens. A vulnerability scanner should not confuse the size of the possible blast radius with the probability that someone will light the fuse. More importantly, it should never claim to know whether the fuse is lit when all it has is a forecast. CVSS severity tells you what exploitation could cost. EPSS helps estimate where exploitation may happen next. Context tells you what to do today.
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. What CVSS actually measures 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. What EPSS adds 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? The four decision lanes 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, exposure, and risk tolerance. A real scan changes the conversation A CVE Lite CLI case study of the Lit repository shows why two signals are more useful than one. The scan found a critical form-data vulnerability associated with CVE-2025-7783 and a medium-severity Karma finding associated with CVE-2022-0437. In the EPSS snapshot used for the study, CVE-2025-7783 ranked at approximately the 77th percentile. CVE-2022-0437 ranked above the 96th percentile. The exact values will move because EPSS updates daily, but the decision pattern remains instructive. A severity-only table pushes the Karma finding far below the critical item and invites the developer to ignore it. The combined model does something more honest. It places the form-data vulnerability in Fix Soon because of its critical technical severity, while surfacing the Karma vulnerability in Monitor because of its unusually elevated exploitation forecast. It does not pretend that either label is the final answer. It makes both findings visible for different reasons. The next questions are environmental. Is the affected package present in a production path? Is the vulnerable function reachable? Is the system exposed? What would exploitation affect? Has CISA or another trusted source confirmed exploitation? A scanner that cannot answer those questions should not imply that it has. From score to developer workflow I implemented this model in CVE Lite CLI v1.33.0 as the EPSS Priority Signal. For an advisory with multiple CVE aliases, the tool uses the highest available EPSS percentile so that a lower-scoring alias does not hide the stronger forecast. The result appears in the verbose terminal table, the HTML report, and the prioritySignal field in JSON output. The implementation matters less than where it appears. A probability buried in a JSON response does not help a developer facing 20 findings. The combined signal has to reach the terminal output, remediation plan, and CI policy at the moment a dependency decision is being made. That does not mean every Fix Now finding should automatically block every release. A defensible CI policy can use Fix Now as one blocking condition while treating a CISA KEV match, confirmed reachability, or a critical production asset as independent reasons to stop. Monitor and Lower Priority findings can flow into tracking unless local context raises them. This is a better model than blocking on every high-severity advisory. A gate that produces constant noise will eventually be bypassed. A gate that explains why a finding is elevated, and which additional evidence can override the default, is easier to trust. A research direction At Colorado State University , researchers are exploring where this model can go further. Rakesh Podder , Viktoria Koscinski, and Indrajit Ray developed CAPE (Context-Aware Prioritization Engine), a framework that enriches each CVE with deployment-specific evidence — reachability, centrality, and exploitability analysis — producing a ranked priority score using Analytic Hierarchy Process (AHP). Evaluated across 30 open-source projects and over 6,000 scanner-reported CVEs, their findings show that 43.3% of scanner-reported CVEs are statically unreachable (53.1% for TypeScript and JavaScript; 27.4% for Python). In the most extreme case, that rate reached 76.1%. I am collaborating with the CSU team to explore incorporating these contextual signals into CVE Lite CLI’s prioritization model, moving from forecast-based tiers toward deployment-aware scoring that accounts for reachability and effort distribution. The underlying principle CVSS is not wrong. It is being asked to do too much. A severity score can describe technical characteristics and potential impact, but it cannot serve as a threat forecast, an asset inventory, a reachability analysis, and a business decision all at the same time. EPSS supplies one of those missing dimensions: a dynamic forecast of exploitation likelihood. CISA KEV supplies confirmed exploitation evidence. Application and asset context supply presence, reachability, and consequence. Good prioritization comes from keeping those signals distinct and combining them deliberately. The right place to surface that combination is developer-time tooling: the scanner that runs locally or in CI while the developer can still change the dependency. A weekly dashboard is useful for governance, but it is not the moment when the code decision happens. A vulnerability scanner should not confuse the size of the possible blast radius with the probability that someone will light the fuse. More importantly, it should never claim to know whether the fuse is lit when all it has is a forecast. CVSS severity tells you what exploitation could cost. EPSS helps estimate where exploitation may happen next. Context tells you what to do today.