Threat, vulnerability, likelihood, impact, and uncertainty

Four words that are not synonyms

A threat is a person or process that might cause a loss: a ransomware group, a dishonest contractor, a misconfigured job that wipes a disk. A vulnerability is a weakness that makes the loss easier: an unpatched virtual private network (VPN) appliance, a shared warehouse password, a public object store. Likelihood is how plausible it is that a threat will use that weakness in your environment. Impact is how badly Riverstone is hurt if it happens: stalled docks, stolen customer addresses, a forged bill of lading.

Risk is the combination of those pieces plus uncertainty. Two vulnerabilities can share a vendor severity label and still deserve different queues. The internet-facing VPN that terminates driver sessions is exposed to anyone who can reach it. An outdated plugin on the internal lunch-menu wiki is also “unpatched software,” but it is reachable only from the office network and it does not hold TrackPort data.

Severity, predicted exploitation, and observed exploitation

The Common Vulnerability Scoring System (CVSS) from FIRST describes characteristics of a vulnerability, such as how it is reached and how strongly it can affect confidentiality, integrity, or availability. It is not a promise that attackers are using it against you this week. FIRST’s Exploit Prediction Scoring System (EPSS) estimates the probability that a vulnerability will be exploited in the wild over the next 30 days. That is a population-level forecast, not a measurement of your warehouse.

CISA’s Known Exploited Vulnerabilities (KEV) catalog records vulnerabilities with evidence of exploitation in the wild. KEV is observed evidence, not a complete list of everything dangerous and not a ranking of business impact. A Riverstone analyst should put these signals side by side: CVSS tells you how bad a successful exploit can be in the abstract, EPSS estimates whether this vulnerability will be exploited in the wild during the next 30 days, and KEV tells you someone has already used it. None of the three knows whether the VPN is in production, whether compensating network filters exist, or whether YardOS would stop if the VPN failed.

• Severity describes potential technical harm, not your queue order.
• EPSS is a 30-day exploitation probability estimate, not a certainty.
• KEV is evidence that exploitation has occurred somewhere, not proof it occurred at Riverstone.
• Exposure and business context still have to be written in your own words.

Worked comparison: VPN versus wiki

Suppose both the VPN appliance and the wiki plugin have similar high CVSS scores. The VPN is on the internet, authenticates drivers, and is on CISA KEV. The wiki plugin is internal, has a low EPSS estimate, and is not on KEV. The VPN should jump the queue even if a scanner labeled both “critical.” The remaining uncertainty is whether a web application firewall or geofence already reduces VPN exposure; until someone checks, that is an open question, not a reason to wait forever.

Write the note as: threat (opportunistic ransomware crews scanning VPN products), vulnerability (unpatched appliance), likelihood signals (KEV plus internet exposure), impact (drivers cannot authenticate; FleetLink and YardOS stall), uncertainty (we have not confirmed whether management ports are filtered). That note can be challenged. A single red score cannot.