CVE
In vulnerability management, a CVE is a public identifier assigned to a specific vulnerability in a product, so that everybody discussing it is discussing the same thing. It is a name, not a measurement: the identifier says a flaw was catalogued, and says nothing at all about how much it matters to you.
How it works
Identifiers are issued by CVE Numbering Authorities, organisations authorised to assign identifiers within a defined scope. Most large vendors are a numbering authority for their own products, which is why a fixed advisory and its identifier usually appear together. The scope is broader than people assume: it covers hardware and firmware as well as software, which matters when the affected component is a controller, a baseboard management processor or an appliance.
One identifier equals one vulnerability, but the mapping to real systems is not clean. A flaw in a widely embedded library carries one identifier and appears in hundreds of products, each of which patches on its own schedule. A single vendor advisory can carry many identifiers. And the affected version data attached to a record is frequently incomplete, which is what makes automated matching noisy.
What goes wrong
Counting them. A report that says an estate has four thousand identifiers has said nothing about risk, because the population includes flaws in components that are not loaded, in configurations that are not used, and on hosts that are not reachable. The number moves procurement conversations and does not move risk.
The second problem is treating the absence of an identifier as the absence of a flaw. Custom code has no identifiers at all, which is exactly why an estate can have an immaculate patch position and still be compromised through its own application. Most of what a penetration test reports has no identifier, because nobody has assigned one to your authorisation model.
For a European reader there is a further piece of context: alongside the long-standing catalogue and the numbering authorities, NIS2 gives the European Union agency for cybersecurity a role in maintaining a vulnerability registry at European level. Anyone citing that registry in a compliance document should confirm its current name and status first.
Where this shows up in an audit
We cite identifiers where they exist because they make a finding verifiable and give the client something to search their own inventory for. We do not use them as the structure of the report, and we never carry a vendor’s severity across without restating it for the environment, which is the job of CVSS combined with EPSS and reachability. A finding with no identifier is not a lesser finding.