We regularly cite vulnerability identifiers without explaining them. Yet understanding this system lets you do something useful: know whether an alert concerns you, how urgent it is, and where to find the fix. It is probably the most cost-effective security skill for someone who is not a specialist.
What a CVE identifier is
It is a unique reference assigned to a specific vulnerability in a specific piece of software. The format is simple: the letters CVE, the year, then a sequence number.
Its value lies in coordination. Without a shared identifier, a vendor, a researcher and a system administrator would talk about the same flaw with three different descriptions, unaware that it is the same problem. A shared number lets everyone point to exactly the same thing.
A point that is often misunderstood: the existence of an identifier does not mean the flaw is being exploited, or even that it is exploitable in your configuration. It means it has been documented.
Severity, and what it does not say
Each vulnerability receives a score, usually out of ten, calculated from standardised criteria: difficulty of exploitation, privileges required, impact on data confidentiality and integrity.
This score is useful for triage, and it has an important limitation: it describes the flaw in the abstract, not in your situation. A vulnerability rated very severe on a component you do not expose to the network can be less urgent than a medium-severity flaw on a publicly accessible service.
The right reading therefore combines two things: the stated severity, and your actual exposure.
When a researcher finds a flaw, established practice is to notify the vendor privately and give it a window — often ninety days — to publish a fix before making the information public. This balance protects users without letting a vendor ignore a problem indefinitely. It also explains why a flaw and its patch are usually announced on the same day: the work had begun weeks earlier.
The most dangerous moment
This is a counter-intuitive and essential point: the riskiest period begins after publication.
As long as a flaw is unknown, only those who discovered it can exploit it. Once published, with its technical description, it becomes accessible to anyone who would not have known how to find it.
The race therefore starts at the moment of disclosure: defenders apply the patch, attackers automate the exploit. This is what we documented with a campaign targeting 460 systems, which exploited already-patched vulnerabilities.
And this race is speeding up, as shown by an open model that identified more than a thousand real flaws: the acceptable window between disclosure and patching has just shortened on both sides.
What to do in practice
Know what you use. You cannot know whether an alert concerns you without an inventory of your software and its versions. It is tedious, and it is the foundation of everything else.
Follow announcements for your critical tools. Most vendors offer a security mailing list.
Patch quickly what is exposed. Prioritise based on what is reachable from the outside, not just on the score.
For an individual, all of this boils down to one thing: enable automatic updates and do not keep postponing them. It is unspectacular, and it is most of what protects you.
What to remember
This system rests on an idea worth highlighting: making flaws public protects better than hiding them. It is counter-intuitive and borne out by fifty years of practice.
It is also what is sorely missing on the AI side, as we regularly write. There is no equivalent of this system for flagging that a model exhibits problematic behaviour: no shared identifier, no disclosure obligation, no standardised timeline. Computer security took decades to build this apparatus. It will probably take less time for AI, but it does not exist yet.