Bottom line: a CVSS score communicates structured vulnerability severity under defined metric inputs. It does not know whether the vulnerable product exists in your environment, whether the relevant path is exposed, what the service means to the business, or which change is safest.
\nThe official CVSS v4.0 specification defines an open framework for communicating vulnerability characteristics and severity. Version 4.0 uses Base, Threat, Environmental, and Supplemental metric groups. Base describes intrinsic characteristics; Threat captures characteristics that can change over time; Environmental reflects a consumer’s environment; Supplemental conveys additional context without changing the final score.
\nFIRST states that consumers should enrich Base metrics with Threat and Environmental values for more meaningful, environment-specific severity input. The specification also says organizations may use CVSS within a broader vulnerability-management process that considers factors outside CVSS. It requires the score and vector string to be presented together when CVSS data is published.
\nCVSS does not establish asset presence, exploit confirmation, business risk, legal duty, patch quality, operational safety, or remediation order by itself. A high Base score and a low-scored vulnerability with confirmed exploitation can both require attention for different reasons.
\nChanging the score locally without preserving the provider vector, metric group nomenclature, rationale, source, and time can make comparisons misleading. A scanner’s score may also reflect an older CVSS version or incomplete vendor information.
\nThe following steps are DSE recommendations based on the cited source.
\nSample prioritized and deferred vulnerabilities. Reconstruct the source vector, applicability, current threat evidence, environmental reasoning, owner, decision, exception, due date, change result, and closure test. Confirm that an updated advisory or score can trigger reassessment.
\n