Vulnerability prioritization: CVSS, EPSS, KEV, and context

Understand what the external signals measure

CVSS communicates vulnerability characteristics and severity using a defined scoring framework. EPSS provides an estimate of exploitation likelihood. CISA’s Known Exploited Vulnerabilities catalog supplies evidence that listed vulnerabilities have been exploited. These signals can complement one another, but they are not interchangeable.

A high score does not establish that every deployment is reachable, and a lower score does not make an important exposed workflow harmless. Absence from KEV is not evidence that exploitation is impossible. Read the relevant advisory and preserve the meaning of each signal in your triage record.

References: [1] FIRST, [2] FIRST, [3] CISA

Add your deployment and business context

Establish whether the affected component and configuration are present, which inputs reach the vulnerable behavior, and what authority the service holds. Consider internet exposure, authentication prerequisites, sensitive data, operational dependency, and any verified compensating controls.

Distinguish a development-only component from code executing in a privileged build job or production worker. Both can matter, but their consequences differ. Use the actual environment and workflow to explain priority rather than assigning every instance the same business impact.

References: [4] NIST, [5] OWASP

Choose a concrete action and owner

For an applicable issue, decide whether the next action is an update, containment, a temporary control, more investigation, or a documented risk decision. Assign an owner and a response target appropriate to the evidence and your organization’s requirements. Avoid a universal deadline that ignores the system involved.

Record why an issue is prioritized and what would change that decision. A newly published exploit, changed exposure, failed mitigation, or confirmed credential access may justify re-triage. A queue needs a way to react to new evidence rather than preserving the original score forever.

References: [3] CISA, [2] FIRST, [6] NIST

Verify remediation at the actual boundary

Define closure before making the change. For a dependency issue, verify the fixed component in the deployed artifact. For authorization, retest the forbidden and allowed outcomes. For an exposure control, verify the effective access decision from the relevant context.

Track accepted and deferred risks separately from fixed issues. A patch merged into source is not necessarily active in every environment, and a scanner’s disappearance of an alert can have several causes. Preserve evidence that connects the action to the original risk.

References: [7] NIST, [8] OWASP

Your next steps

1. Record applicability, severity, likelihood, and known-exploitation signals separately.
2. Add exposure, reachable behavior, authority, and business importance.
3. Assign an action, owner, and reasoned response target.
4. Discuss a review that validates high-impact findings and closure evidence.