Prioritize, mitigate, and verify vulnerability remediation

CVSS describes vulnerability characteristics; it does not know local asset value, internet exposure, existing controls, or business dependency. Prioritization should combine technical severity with evidence of exploitation, reachability, privilege, affected population, mission impact, and remediation feasibility.

CISA's Known Exploited Vulnerabilities catalog is evidence that a vulnerability has been exploited in the wild and includes required-action context for covered agencies. It is a strong threat signal, not proof that every local asset is reachable or compromised. Verify inventory and exposure while accelerating the response.

A patch removes vulnerable code but may need testing and downtime. A configuration change, feature disablement, isolation rule, or virtual patch can reduce exposure sooner. Call these mitigations when the vulnerable condition remains, and record expiry so temporary controls do not become invisible permanent exceptions.

Verification must test both security and service. Confirm the vulnerable action is blocked or the fixed version is present, then confirm the required business transaction still works. Rollback criteria should describe measurable failure, not simply discomfort with the change.

CVSS communicates technical severity; EPSS estimates near-term exploitation probability and changes over time; KEV supplies evidence of known exploitation. None includes every local fact. Validate true positives, retain possible false negatives from coverage gaps, and prioritize with exposure, asset mission, impact, controls, and treatment feasibility.

A true positive is a validated affected condition and a false positive is a reported condition that is absent or inapplicable; a true negative is correctly cleared, while a false negative is a missed real condition. External, internal, and isolated placement changes reachable attack paths but does not erase inventory. Record the CVSS version/vector, EPSS score/date, intelligence date, fix availability, and local context rather than sorting by one number.

A CVSS Base vector gives one value per metric. In CVSS v3.1 the exploitability metrics are Attack Vector (AV: Network, Adjacent, Local, Physical), Attack Complexity (AC: Low, High), Privileges Required (PR: None, Low, High), and User Interaction (UI: None, Required). Scope (S) is Unchanged or Changed, and the Confidentiality, Integrity, and Availability impacts (C, I, A) are each High, Low, or None. Example: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H describes a flaw reachable over the network with low complexity, no privileges, no user action, and high impact on all three properties; it scores 9.8. CVSS v4.0 adds Attack Requirements (AT), replaces Scope with separate impacts on the vulnerable system (VC, VI, VA) and subsequent systems (SC, SI, SA), and names scores by the groups used: CVSS-B is Base only, CVSS-BT adds Threat, and CVSS-BTE adds Environmental metrics.

The severity bands are the same in v3.1 and v4.0: None 0.0, Low 0.1-3.9, Medium 4.0-6.9, High 7.0-8.9, and Critical 9.0-10.0. A Base score describes the flaw itself; Temporal (v3.1) or Threat (v4.0) metrics adjust it for exploit maturity, and Environmental metrics adjust it for the affected asset's requirements and controls. EPSS publishes two numbers for each CVE: a probability from 0 to 1 that exploitation activity will be observed in the next 30 days, and a percentile, which is the share of scored CVEs at or below that probability. In FIRST's example a probability of 0.10 sits near the 88th percentile, so a small-looking probability can still rank above most CVEs.

A patch removes vulnerable code, while configuration and network controls can reduce a reachable attack path even when code remains. Secure coding changes the cause; attack-surface management removes unnecessary exposure. If no direct fix exists, document the exception owner, compensating control, monitoring, expiry, and conditions that reopen treatment.

Validation observes the deployed state. Confirm the intended version or configuration, repeat the previously vulnerable action from a relevant vantage point, and test required service behavior. A downloaded patch, merged branch, closed ticket, or untested firewall rule does not show that the running system changed or that the control works.