A security scanner can produce thousands of findings, each decorated with a severity label and a decimal score. The natural response is to patch every item marked critical before touching anything rated lower. That rule is simple, auditable, and often wrong.
The Common Vulnerability Scoring System, or CVSS, describes technical severity. It does not know whether a vulnerable product is installed in your environment, exposed to the internet, protected by another control, or supporting a safety-critical service. It also does not necessarily tell you whether attackers are exploiting the flaw today. A better patch queue combines CVSS with evidence of active exploitation, a forecast of likely exploitation, and local knowledge about the affected asset.
CVSS describes a vulnerability’s technical characteristics
CVSS gives security teams a common language for discussing software, hardware, and firmware vulnerabilities. In version 4.0, the Base metrics capture intrinsic characteristics such as attack requirements and potential impact. Threat metrics can reflect changing information such as exploit maturity, while Environmental metrics adapt the assessment to a particular deployment. Supplemental metrics add context without changing the score.
The official CVSS 4.0 specification says consumers should enrich Base metrics with threat and environmental information. It also lists factors outside CVSS, including regulatory obligations, customers affected, possible financial loss, threats to life or property, and reputational impact. The US National Vulnerability Database puts the distinction even more directly in its CVE frequently asked questions: CVSS is a qualitative measure of severity, not a measure of risk.
A Base score is still valuable. It helps compare the inherent consequences and exploit conditions of different flaws using a transparent vector. The mistake is treating that useful input as a complete work order.
Confirmed exploitation changes the priority
The Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities Catalog, usually shortened to KEV. An entry means CISA has evidence that attackers have exploited the vulnerability in the wild, that a clear remediation action exists, and that the vulnerability meets the catalog’s inclusion criteria. This is a stronger urgency signal than a theoretical possibility or public proof-of-concept alone.
CISA created the catalog through Binding Operational Directive 22-01. Its deadlines apply to covered US federal civilian agencies, but CISA recommends that other organizations use KEV as an input to vulnerability management. The important idea travels well: remediation capacity should focus first on vulnerabilities that attackers have demonstrated they can use.
KEV is not a complete inventory of everything dangerous. It is deliberately evidence-based and retrospective. A newly disclosed flaw may deserve urgent action before it reaches the catalog, and an attacker may exploit vulnerabilities that public sources have not yet confirmed.
EPSS estimates near-term exploitation probability
The Exploit Prediction Scoring System, or EPSS, addresses a different question. Maintained by the Forum of Incident Response and Security Teams, it uses a data-driven model to estimate the probability that exploitation activity for a published CVE will be observed in the next 30 days. Scores are updated daily and are available through public data feeds.
According to the official EPSS overview, the model uses empirical signals associated with attacker behavior and ongoing activity. A probability score is not the same as its percentile ranking. Probability estimates the absolute likelihood of observed exploitation; percentile shows how the score ranks against other vulnerabilities.
EPSS and KEV should not be forced into agreement. The EPSS guidance describes KEV as confirmed historical evidence and EPSS as a forward-looking forecast. A KEV entry can have a low current EPSS score without contradiction. When direct evidence of active exploitation exists, that evidence takes precedence over a forecast.
Your environment determines the consequence
A flaw cannot harm an organization through a product it does not run. Even when the product is present, reachability and consequence vary. An internet-facing identity server is a different target from an offline test machine. A vulnerable library loaded by a public application matters more than the same library sitting unused in an archive.
Asset context should answer four practical questions. Is the vulnerable component actually present? Can an attacker reach it? What privileges or business process could exploitation affect? Which controls would block, detect, or contain the attack? These answers can raise or lower urgency without changing the underlying CVSS Base score.
This is why an accurate software inventory matters. Our guide to software bills of materials explains that an SBOM can help locate components but cannot prove they are exploitable or safe. Inventory starts the investigation; deployment context completes it.
A layered patch queue works better than one cutoff
A practical workflow begins by matching scanner findings against a verified asset inventory. Remove obvious false positives, identify externally reachable systems, and connect each asset to an owner and business function. Then layer the signals rather than multiplying them into a mysterious master number.
First, elevate vulnerabilities on CISA KEV or supported by reliable evidence of active exploitation. Within that group, prioritize internet exposure, privileged systems, sensitive data, safety consequences, and weak compensating controls. Next, use EPSS to rank vulnerabilities without confirmed exploitation, while keeping CVSS impact and local consequences visible. Finally, schedule the remaining work according to severity, exposure, maintenance windows, and vendor support.
This ordering is not universal. A hospital, factory, small publisher, and cloud provider have different consequences and downtime constraints. The method should produce a documented queue that engineers can explain, not an opaque score that nobody can challenge.
Patch speed is only one part of remediation
Installing an update can introduce downtime or compatibility failures, especially in operational technology and older appliances. When immediate patching is unsafe, teams may isolate the service, disable a feature, block an attack path, increase monitoring, or retire the asset. Those compensating controls should have owners, evidence, and expiration dates.
Validation matters after the change. Confirm that the vulnerable version is gone, the service restarted correctly, exposure did not move to another instance, and the scanner sees the new state. Our article on continuous threat exposure management explains why remediation should be tested as a reduction in reachable exposure rather than counted as a closed ticket.
Common shortcuts produce misleading priorities
One shortcut is patching every CVSS 9 or 10 while ignoring lower-scored flaws with active exploitation. Another is treating the absence of a KEV entry as proof that a vulnerability is not exploited. A third is reading an EPSS percentile as an exploitation probability. These values answer different questions.
Multiplying CVSS and EPSS is also a poor shortcut. The EPSS maintainers caution that a calibrated probability multiplied by an ordinal severity score does not create an interpretable risk value. Keep likelihood, technical impact, and local consequence as separate visible inputs so reviewers can understand why an item moved up or down.
Limitations and what to watch next
No public feed sees every attack. KEV requires confirmation and can lag a fast campaign. EPSS learns from observable data and cannot know the details of a specific organization’s network. CVSS vectors can be incomplete, disputed, or based on a worst-case default. Asset inventories also drift as cloud services, containers, and third-party software change.
Watch for wider adoption of CVSS 4.0 Threat and Environmental metrics, faster machine-readable vendor advisories, better component-to-asset mapping, and clearer evidence behind exploitation claims. Teams should also measure whether their prioritization method catches exploited vulnerabilities with a sustainable amount of work, then adjust thresholds as their environment and threat landscape change.
A critical severity score deserves attention, but it is not a stopwatch. The best patch decision combines what a flaw could do, whether attackers are using or likely to use it, where it exists, and what failure would mean to the organization.
Featured image: AI-generated editorial illustration of a conceptual vulnerability-triage workflow, not a screenshot of a specific security product.
Leave a Reply