CVE

A CVE identifier exists to solve a naming problem. Before the scheme, the same flaw appeared in three vendors’ advisories under three descriptions and nobody could tell whether their scanner, their supplier and their auditor were discussing one issue or several. The identifier is deliberately nothing more than a label with a year and a number: it carries no severity, no exploitability judgement and no instruction. Severity is layered on afterwards by scoring systems, and those are separate artefacts produced by different parties who sometimes disagree.

Two properties of the system regularly catch teams out. Identifiers are frequently reserved before any details are published, so a record can be referenced while still saying almost nothing. And the affected-version data, which is what every automated tool actually matches against, is contributed by people with varying levels of insight into the software — meaning a package can be flagged for a version that was never affected, or quietly not flagged for one that was.

Reading a record properly

• Check the affected version range against what you actually ship, including how your lockfile resolved the transitive graph rather than what the manifest requests.
• Read the vendor advisory alongside the record. The vendor usually states the precondition — a specific configuration, an exposed interface — that determines whether it applies to you at all.
• Treat the published score as an input rather than a verdict, since it describes the flaw in the abstract and knows nothing about where the component sits in your system.
• Look for whether exploitation has been observed in the wild, which changes the urgency far more than a decimal point of severity does.

An identifier is a name, not a risk assessment: the same record can be a same-day emergency on one system and a documented non-issue on another running the identical version.