How to read a CVE and CVSS score

Identifier, record, score

A CVE identifier gives a public vulnerability a common name. NVD and vendors may add descriptions, affected-product information, references, and scoring. CVSS describes technical severity through defined metrics. These pieces improve coordination, but none of them proves that a particular organization is exposed or compromised.

Why a high score can wait—and a lower score cannot

Priority changes with internet exposure, affected version, available privileges, exploit availability, active exploitation, asset importance, compensating controls, and the cost of failure. A flaw used in the wild against an exposed identity system may outrank a higher-scoring flaw on an isolated system.

A defensible triage sequence

Confirm the product and version, determine exposure, check vendor guidance and known-exploitation evidence, identify affected business services, choose a patch or mitigation, and verify the result. Record uncertainty instead of filling gaps with assumptions. Severity is an input to that decision, not the decision itself.

Example: the same CVE in two places

A vulnerable library may be reachable in an internet-facing service and also present in an isolated test image that is not running. The CVE and base score are the same, but exposure, business consequence and remediation timing differ. The lower-priority asset still needs an owner and disposition; the higher-priority service needs a tested change path. Context changes response without changing the vulnerability’s identity.

A defensible vulnerability record

Keep the CVE, vendor advisory, affected product and version, asset evidence, exposure, compensating controls, owner, planned action and completion proof. If exploitation evidence such as a KEV entry changes, update the priority and note the date. This record makes it possible to explain why one asset was patched immediately and another was held for a defined dependency rather than silently ignored.