They should use both, but not as equals. CVSS tells you how severe a flaw may be, while EPSS helps identify what is most likely to be exploited soon. In a crowded dependency estate, exploit likelihood is often the better trigger for first-line remediation, especially when exposure spans multiple images and modules.
Why EPSS usually wins the first fix in supply chain remediation
For supply chain vulnerabilities, the practical question is not which score is “better” in the abstract, but which one should drive the next remediation queue. CVSS is useful for understanding inherent severity, but EPSS is often more operational because it estimates near-term exploitation likelihood. In dependency-heavy environments, that likelihood signal helps separate theoretical exposure from the flaws most likely to be used first.
That distinction matters because supply chain estates rarely fail one dependency at a time. A single vulnerable package, base image, or build component can fan out across multiple services, images, and modules, so prioritisation needs to account for blast radius as well as score. Severity still matters, but exploitability usually determines which issue should move from backlog to immediate action.
EPSS is strongest when the remediation team is triaging a large, fast-moving queue and needs a practical “what now” filter. FIRST EPSS is designed for that use case, while FIRST CVSS remains valuable for understanding the technical seriousness of the flaw itself. Used together, they answer different questions rather than competing for the same role.
How to interpret score disagreement between severity and likelihood
A high CVSS score with a low EPSS score usually means the flaw is serious, but not currently attracting or enabling easy exploitation. That does not make it safe, especially if the vulnerable component is internet-facing, widely reused, or hard to patch. It does mean you may be able to stage the fix behind more likely exploitation paths without losing control of the risk.
The reverse case is more urgent: a modest-severity issue with strong EPSS signals may warrant faster action because attackers are actively likely to weaponise it. That is especially true when the vulnerable dependency is shared across products or embedded in build and deployment pipelines. For supply chain issues, distribution and repeatability often matter as much as the nominal severity label.
When the scores diverge, treat CVSS as the floor for seriousness and EPSS as the trigger for sequencing. NIST National Vulnerability Database is useful for the canonical vulnerability record and CVSS context, but the remediation decision still needs an exploitation-likelihood layer if you are deciding what to fix first.
What supply chain teams should prioritise beyond the score
In dependency and build ecosystems, the best prioritisation model blends score with reach and trust boundary. A vulnerable component that is pinned in one internal service is not the same problem as the same component embedded in a shared library, signed artifact pipeline, or CI/CD toolchain. In those shared paths, one remediation action can remove risk from many downstream systems at once.
Teams should therefore rank findings by exploit likelihood, exposure breadth, and reversibility. If a package is broadly deployed, externally reachable, or used in a release process, it deserves more urgency than an isolated library with the same severity score. This is also why SLSA matters here: build provenance and artifact integrity reduce the chance that a vulnerable or tampered dependency reaches production in the first place.
If the issue involves transitive packages, maintainer accounts, or publishing tokens, the question is no longer just “how severe is the CVE?” but “how much trust does this component carry through the supply chain?” That is where controls around signing, provenance, dependency visibility, and release hygiene become part of the remediation decision, not separate hygiene tasks. CVSS alone cannot express that operational context.
Risk and Threat Considerations
Supply chain vulnerabilities are dangerous because the same weakness can propagate across many consuming systems, and attackers often target the easiest path to wide downstream impact. A flaw with modest nominal severity can become urgent if it sits in a widely distributed package, a shared build step, or a dependency that attackers can exploit before defenders can coordinate updates.
Failure mechanism: Organisations over-trust severity scoring and underweight exploitation likelihood, exposure breadth, and dependency reuse, which can leave actively targetable issues unpatched while slower-moving low-likelihood flaws absorb attention.
Impact: The result can be faster compromise of multiple downstream applications, broader blast radius from one vulnerable component, and delayed remediation of the issues most likely to be weaponised first.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, SLSA, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Supply-chain vuln triage depends on timely detection and prioritised remediation. |
| Recommendation — Prioritise remediation using exploit likelihood and exposure breadth, then verify closure in a continuous vulnerability process. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerabilities Are Identified and Documented | The question is about ranking vulnerabilities for action in a supply chain context. |
| Recommendation — Document vulnerable dependencies and rank fixes by exploitability and business exposure. | ||
| SLSA | SLSA — Supply-chain Levels for Software Artifacts | Supply-chain vulnerabilities are materially shaped by provenance and artifact integrity. |
| Recommendation — Adopt provenance and integrity controls so vulnerable or tampered artifacts are less likely to reach production. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | Vulnerability monitoring must feed remediation prioritisation in dependency estates. |
| Recommendation — Use vulnerability scanning outputs together with exploit-likelihood data to set fix order. | ||
| OWASP ASVS | V15 — Secure Architecture | Dependency and supply-chain risk affect the architecture-level trust path of delivered software. |
| Recommendation — Design release and dependency flows so one vulnerable component cannot propagate unchecked. | ||
Practitioner Guidance
What to prioritise: Use EPSS to order the near-term queue, then override it where a lower-likelihood issue sits in a highly shared or externally exposed dependency path. If a vulnerability can affect many systems from one fix, elevate it even when its EPSS is not the highest.
What to verify: Confirm whether the vulnerable component is directly deployed, transitive, pinned, mirrored, or embedded in build tooling. The same score means very different things depending on whether you can patch one service or must coordinate across many repositories and release streams.
Practitioner takeaway: CVSS tells you how bad the flaw is in principle, but EPSS usually tells you which supply chain issue deserves the next operational response, especially when shared dependencies can turn one vulnerability into many.
Related resources from NHI Mgmt Group
- How do organisations decide which supply chain controls to prioritise first?
- How should security teams prioritise software supply chain vulnerabilities?
- Should organisations prioritise segmentation or detection when supply chain malware is propagating?
- When should organisations prioritise supply chain trust mapping over simple patching?