Every vulnerability report you receive is full of identifiers like CVE-2023-44487. They are not severity ratings, not scores, and not statements that you are at risk — they are catalogue numbers, and knowing what they do and do not mean makes the reports far easier to read.
What the identifier actually is
CVE stands for Common Vulnerabilities and Exposures. A CVE identifier is a unique reference number for one specific flaw in one specific product, and it exists to solve a coordination problem rather than a technical one.
Before it existed, the same vulnerability had a different name in every vendor's advisory and every scanner's database, and nobody could tell whether two reports described one problem or two. A shared identifier means your scanner, your operating-system vendor, a news article and a government advisory can all refer to the same thing unambiguously.
The format is simple: CVE, the year it was assigned, and a sequence number — CVE-2023-44487. The year is when the identifier was reserved, not necessarily when the flaw was found or published, so a CVE with last year's number can be brand new to you.
Numbers are handed out by CVE Numbering Authorities under the CVE Program, which MITRE operates on behalf of the US government: organisations authorised to assign identifiers within their own scope. Many large software vendors are their own authority, which is why a vendor can publish an advisory and an identifier simultaneously. Regional catalogues have appeared alongside it — ENISA now runs the EU Vulnerability Database, which references the same CVE identifiers.
CVSS: the score, and what it measures
A CVE identifier carries no severity. That comes from CVSS — the Common Vulnerability Scoring System — which produces a number from 0 to 10, usually presented in bands: low, medium, high, critical.
The score is built from characteristics of the flaw itself: whether it can be exploited over the network or needs local access, how complex the attack is, whether the attacker needs credentials or a user to click something, and what they gain — the ability to read data, change it, or take the system down.
Two things about CVSS are worth internalising, because they explain most of the confusion:
It is a severity score, not a risk score. It describes how bad exploitation would be in the abstract, with no knowledge of your environment. A 9.8 in a component you have deployed on the public internet and a 9.8 in a component running on an isolated machine are the same number and very different problems.
The score you are shown does not change when the world does. CVSS defines optional Threat metrics — Exploit Maturity in version 4.0, Temporal metrics before it — that are meant to move as exploit code appears. Almost nobody publishes them: what advisories and scanners carry is the Base score, assigned once at publication. It does not go up when exploit code appears, and it does not go down when a flaw turns out to require conditions nobody runs. In practice, whether anyone is exploiting a vulnerability is not something the number in front of you expresses — which is why a high CVSS score is not enough to decide what to patch first.
The three questions the numbers cannot answer
Am I actually running the affected version? Advisories specify version ranges, and getting this right is harder than it looks — particularly with Linux distributions, which frequently apply a fix to an older version without changing its number. A package reported as an old version may well be patched.
Is the vulnerable code reachable in my usage? Many flaws only apply when a particular feature or configuration is enabled. Being present is not the same as being exposed, which is the entire premise of VEX documents.
Is anyone exploiting it? This is the most useful question for deciding what to do this afternoon, and it lives outside both the CVE and its CVSS score.
What "no CVE" does not mean
Worth ending on, because it is a common misreading. A vulnerability with no CVE identifier is not thereby safe. Plenty of real flaws are fixed quietly in a release without an advisory ever being filed, and some ecosystems — particularly the long tail of plugins and small libraries — are covered far less thoroughly than mainstream server software.
A clean CVE report means no published, catalogued vulnerabilities matched what you are running. That is genuinely useful information. It is not the same as no vulnerabilities.
What is a CVE?
CVE stands for Common Vulnerabilities and Exposures, and a CVE identifier is a unique reference number for one specific security flaw in one specific product — for example CVE-2023-44487. It exists to solve a coordination problem: before it, the same vulnerability had a different name in every vendor advisory and scanner database. The identifier itself carries no severity and is not a statement that you are at risk; it is a catalogue number that lets everyone refer to the same flaw unambiguously.
What is the difference between CVE and CVSS?
A CVE is the identifier for a specific flaw; CVSS is the scoring system that rates how severe it would be, from 0 to 10. The score is built from characteristics of the flaw itself — whether it can be exploited over the network, how complex the attack is, whether credentials are needed, and what the attacker gains. It is a severity score rather than a risk score, because it knows nothing about your environment.
Who assigns CVE numbers?
CVE identifiers are assigned by CVE Numbering Authorities — organisations authorised to issue numbers within a defined scope, operating under the CVE Program that MITRE runs on behalf of the US government. Many large software vendors are their own authority, which is why a vendor can publish an advisory and its identifier at the same moment. Smaller projects go through a general-purpose authority instead, and the year in the identifier is when the number was reserved, not necessarily when the flaw was found.
If a scan finds no CVEs, is my software safe?
A clean CVE scan means no published, catalogued vulnerabilities matched what you are running, which is useful but not the same as having none. Real flaws are regularly fixed quietly in a release without an advisory ever being filed, and coverage varies by ecosystem — the long tail of plugins and small libraries is documented far less thoroughly than mainstream server software. A clean report is evidence, not a guarantee.
Where VulnControl fits
VulnControl identifies the software your website actually runs and matches each version against a nightly-refreshed mirror of the US National Vulnerability Database, marking anything that appears in CISA's exploited catalogue. Matching is done on the formal product identifier inside each record rather than on words in its description, which is the difference between a usable report and an unusable one. Where a version cannot be established it says so, rather than reporting you as clean.