CVSS v4.0 added a Supplemental Metric group with five metrics: Safety, Automatable, Recovery, Value Density, and Provider Urgency, plus a sixth, Vulnerability Response Effort, that rounds out the group. None of them touch the numeric score. A finding scored 9.8 stays 9.8 whether Safety is Present or Negligible, whether Automatable is Yes or No. That is deliberate, and it is also why most teams either ignore the group entirely or try to fold it back into a “modified score.” Neither approach extracts the value in the data. The Supplemental group is metadata for routing decisions, not a second severity dial.
What Supplemental metrics are, and why the score ignores them on purpose
CVSS v4.0 splits into four metric groups: Base, Threat, Environmental, and Supplemental. The first three feed the scoring algorithm and produce CVSS-B, CVSS-BT, or CVSS-BE depending on which are populated. Supplemental metrics are excluded from that algorithm by design. FIRST’s own specification states the group exists to convey extrinsic attributes of a vulnerability that may be useful for prioritization, without altering the base characteristics that the score represents.
The reasoning holds up in practice. A CVSS Base score is meant to be portable: an analyst at any organization, looking at the same CVE, should reproduce roughly the same Base vector. Safety consequences, recovery difficulty, and how automatable an exploit is are all real, but they are either organization-specific (a PLC controlling a conveyor belt versus one controlling a centrifuge) or dependent on information that is not stable at disclosure time (whether working exploit code appears in a public repository next week). Mixing that into a “universal” score would break the comparability across organizations that CVSS exists to guarantee.
Mechanically, Supplemental metrics just ride along in the vector string. A full v4.0 vector might read CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/S:P/AU:Y/R:A/V:C/U:Amber. Everything before the S:P segment feeds the score. Everything from S:P onward is Supplemental: present in the record, absent from the arithmetic. A pipeline that parses CVSS vectors needs to keep these two halves logically separate rather than averaging them into one number.
Safety (S): the OT, ICS, and medical-device metric
Safety takes two values: Negligible or Present. It answers one question: can exploitation plausibly cause physical harm, injury, or loss of life, as opposed to purely a data or availability loss? The definition borrows its severity categories from IEC 61508: Marginal, Critical, and Catastrophic consequences all collapse into Present; anything below that threshold is Negligible.
The metric exists because a Base score cannot see the difference between “availability loss on a marketing CMS” and “availability loss on a safety instrumented system that stops an overpressure event.” Both can score AV:N/AC:L/VA:H and land in the same numeric range. Safety is the flag that tells a downstream reader which of those two situations they are actually looking at.
Who consumes it in practice: ICS/OT asset owners running IEC 62443 programs, medical device manufacturers working from FDA premarket and postmarket cybersecurity guidance, and CISA, which has started including a Safety value on a subset of ICS advisories. If your inventory has zero PLCs, medical devices, or safety instrumented systems, Safety will read Negligible on every finding and you can largely stop looking at it. If it does not, treat any Present value as a routing signal independent of the Base score: a Medium-severity finding with Safety:Present on a burner management system deserves a faster review cycle than a Critical finding on an internal wiki.
Automatable (AU): the closest thing CVSS has to a wormability flag
Automatable is binary, No or Yes, and it is lifted almost directly from the “Automatable” decision point in CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC) model. It asks whether the first four steps of the kill chain, reconnaissance, weaponization, delivery, and exploitation, can be scripted and repeated against a large population of targets without target-specific manual work.
Concrete test questions that hold up when a scanner or triage engine has to assign this value automatically:
- Is there a working public exploit or a Metasploit/Nuclei module, as opposed to only a research write-up?
- Does exploitation require pre-authentication access to a network-reachable service, rather than local access, physical access, or a social-engineering step against a specific victim?
- Does the exploit path avoid per-target customization such as guessing a unique secret, path, or configuration value?
- Is the vulnerable component something that shows up in mass internet scanning (Shodan, Censys) rather than a bespoke internal integration?
A pre-authentication deserialization RCE in a widely deployed edge appliance, reachable over HTTPS with a published PoC, is Automatable:Yes. A CSRF that requires a specific authenticated user to click a crafted link inside a niche internal application is not, even at a comparable Base score. Automatable correlates with high EPSS scores and with CISA KEV additions, but the three signals differ: EPSS is a probability estimate updated daily, KEV confirms exploitation in the wild, and Automatable is a structural property that does not change once set. Use them together, not as substitutes.
Recovery (R) and Value Density (V): the blast radius after a successful attack
Recovery and Value Density both describe what happens after exploitation succeeds, which is a different question from how easily it succeeds in the first place. That distinction is easy to lose if you are used to CVSS metrics all describing the attack itself.
Recovery has three values: Automatic, User, and Irrecoverable. Automatic means the system restores itself without intervention, for example a service that crashes and is respawned by a supervisor with no data loss. User means a person has to do something, a restart, a config rollback, a manual data restore from backup, but recovery is achievable. Irrecoverable means the resources lost cannot practically be restored: encrypted or wiped data with no viable backup, a hardware security module whose keys were extracted, a supply-chain build system whose signing key is now untrusted.
Value Density has two values: Diffuse and Concentrated. It asks how much an attacker gains from one successful exploitation. Compromising a single employee laptop is Diffuse: real damage, but bounded to that one asset. Compromising a multi-tenant secrets manager, a certificate authority, or a central identity provider is Concentrated: one exploitation event unlocks value across many downstream systems at once.
Read together, Recovery and Value Density approximate the cost of a bad day rather than the likelihood of one. A finding with Recovery:Irrecoverable and Value Density:Concentrated, even at a moderate Base score, justifies a different incident-response posture than a Critical finding that is Recoverable and Diffuse. Programs that map findings to frameworks such as ISA/IEC 62443 alongside ISO 27001 or PCI DSS controls often use exactly this pair to decide which findings need a separate reporting line to leadership, independent of the numeric score.
Provider Urgency (U): the vendor’s opinion, and when it beats your own math
Provider Urgency lets the vendor that issued the advisory attach its own rating: Red, Amber, Yellow, or Clear, loosely mapped to Critical, High, Medium, and Low. It is the one Supplemental metric that is explicitly a subjective, vendor-supplied judgment rather than a technical property of the vulnerability.
There are good reasons to weight it heavily. The vendor may have telemetry you do not: evidence of active exploitation against their customer base, awareness of a chaining path with another bug they have not yet disclosed, or knowledge that the public PoC is more reliable than it looks from the outside. When a vendor advisory pairs a Red urgency rating with a specific technical justification, an added CISA KEV entry, a reference to observed exploitation, a note about a second bug that turns the issue into full RCE, treat that as a genuine override signal and move the finding ahead of your normal queue.
There are equally good reasons not to take it at face value by default. Vendor incentives are not always aligned with yours: understating urgency avoids alarming customers before a patch is ready; overstating it can pressure customers toward a faster paid upgrade cycle. A vendor’s Amber or Red rating is also usually calculated against their reference deployment, which may include features or configurations you have disabled. A concrete rule that works: accept Provider Urgency as an override only when the advisory names a specific technical reason for it; treat an unexplained Red or Amber as a tiebreaker to review sooner, not as a reason to skip your own validation step.
Turning Supplemental values into routing rules, not score adjustments
The practical failure mode is trying to compute a new number, an “effective CVSS,” by nudging the Base score up or down based on Safety, Automatable, Recovery, Value Density, and Provider Urgency. That destroys the comparability the Base score exists to provide and produces a figure nobody else can reproduce from the same vector string. The better pattern is to keep the Base score untouched and store each Supplemental value as a separate, queryable field that drives routing logic.
A workable rule set looks like this:
| Condition | Routing action |
|---|---|
| Safety = Present | Route to the OT/safety review queue regardless of Base score; target initial triage within one business day. |
| Automatable = Yes and asset is internet-reachable | Escalate to the emergency patch queue, bypassing the standard change window. |
| Recovery = Irrecoverable and Value Density = Concentrated | Require a backup or immutable-snapshot check and a named approver before the ticket can close. |
| Provider Urgency = Red without a stated technical reason | Flag for analyst review within four hours; do not auto-close on vendor rating alone. |
Platforms that ingest CVSS v4.0 vectors during collection can apply this kind of table automatically instead of leaving it as a wiki page nobody follows under deadline pressure. In AI-driven triage, for instance, SITEY parses the Supplemental fields alongside the Base vector and treats Automatable:Yes on a network-reachable asset as an independent escalation trigger, separate from and in addition to the CVSS-B score it also records for reporting. That is the mechanism worth copying even without the product: keep the score and the routing logic in two separate columns, and let the routing logic reference Supplemental fields directly rather than smuggling them into a recalculated severity.
The same separation matters at closure time. A finding with Recovery:Irrecoverable should not be marked resolved purely because a patch was deployed; the actual question is whether the recovery path itself was tested, which is a job for retest rather than for the patch step. Systems that gate closure on an independent retest confirming the fix rather than trusting the patch command’s exit code catch the cases where the underlying data loss risk was never really addressed. And because Provider Urgency can change after an advisory ships, once a KEV entry gets added a week later, for example, findings need to stay visible for re-evaluation rather than disappearing once first triaged; that is a property of how a program tracks the full vulnerability lifecycle, not of the CVSS vector itself.
None of this requires waiting for every scanner to emit clean v4.0 vectors. Even with only Base scores available today, start recording Safety, Automatable, Recovery, Value Density, and Provider Urgency as manual tags on the asset classes where they matter most, OT segments, internet-facing edge services, systems holding concentrated secrets, and wire the same routing table to those tags. When full v4.0 vectors arrive from your scanners, the routing logic is already in place; only the data source underneath it changes.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.