CVE and CVSS Explained: How Vulnerabilities Are Tracked and Scored
A CVE is a standard identifier for a publicly known vulnerability, and CVSS is a scoring system that rates how severe it is on a scale from 0 to 10. Together they let everyone talk about the same flaw and compare risk. A score is a starting point for decisions, not the whole answer.
What a CVE is
The Common Vulnerabilities and Exposures system assigns each publicly disclosed flaw a unique identifier in the format CVE, year, and a number. The identifier gives vendors, researchers, scanners and administrators a shared label, so they can match alerts, advisories and patches to the same issue. A CVE entry includes a short description and references to more details.
A CVE does not say how dangerous the flaw is. That is where scoring comes in.
Why shared identifiers help
Before shared identifiers, the same flaw could have different names in different products and reports, making it hard to know whether two warnings referred to the same thing. A single identifier lets a scanner, a vendor bulletin and a news report line up. It also lets teams search their asset inventories for exactly the affected component and tell auditors precisely what was fixed and when.
What CVSS measures
The Common Vulnerability Scoring System produces a number from 0 to 10, grouped into ratings from none and low through medium and high up to critical. The base score reflects the intrinsic qualities of the flaw.
- Attack vector: can it be exploited over the network, or only locally or with physical access?
- Attack complexity: how hard is it to exploit reliably?
- Privileges required: does the attacker need an account first?
- User interaction: must a victim click or open something?
- Impact: how much confidentiality, integrity and availability could be lost?
- Scope: can the flaw affect components beyond the vulnerable one?
A flaw exploitable remotely, without authentication or user action, with a big impact, scores highest.
A quick worked example
Imagine a flaw that lets anyone on the internet run code on a web server without logging in or tricking anyone. It is reachable over the network, needs low effort, no privileges and no user interaction, and could expose or alter data. That combination yields a very high score. Now imagine a flaw that requires physical access to a machine and an administrator account. Even if the impact is large, the conditions are so narrow that the score will be much lower. The scoring model captures exactly this difference.
The limits of a score
- The base score ignores your environment. A critical flaw in software you do not use matters less than a medium flaw in a system exposed to the internet.
- It does not show whether the flaw is being exploited in the wild.
- It does not know the value of the asset affected.
- Scores can differ between sources, and vendors may rate the same flaw differently.
- Chains of lower-rated flaws can combine into serious attacks.
Using CVE and CVSS to prioritize
- Match CVEs from your scanner or vendor advisory to your asset inventory.
- Check whether the vulnerable system is exposed to the internet or to untrusted users.
- Check whether the flaw is known to be exploited. Public catalogs of actively exploited vulnerabilities exist for this purpose.
- Weigh the business importance of the system.
- Use the CVSS score as one input and set target fix times by overall risk.
- Apply patches or mitigations, then verify with a rescan.
Where to look for information
- Vendor security advisories, which list affected versions and fixes.
- Public vulnerability databases that collect CVE entries with scores and references.
- Catalogs of vulnerabilities known to be exploited, maintained by government cyber agencies.
- Your vulnerability scanner reports, which map findings to CVE identifiers.
- Security news and mailing lists for early warning of widely abused flaws.
Combining sources gives a fuller picture than any single score.
Reading an advisory
A good advisory states which products and versions are affected, the nature of the flaw, the fixed version, available workarounds and any signs of exploitation. Read the affected-versions section carefully, since a flaw might apply only to certain configurations. If no patch exists yet, look for the vendor’s suggested mitigation and reduce exposure by restricting access.
Building a simple workflow
Subscribe to advisories for the products you use, check your scanner results weekly, and log each relevant CVE with an owner, a priority and a due date. Track exceptions, such as a patch that must wait, together with the compensating control you apply meanwhile. Review the list regularly so nothing is forgotten. Consistent small habits beat a perfect but unused process.
Over time, this vocabulary becomes second nature. When you see a new CVE in the news, ask four questions: do we use it, is it exposed, is it being exploited, and is a fix available. Those answers decide the response.
Frequently asked questions
Is every vulnerability given a CVE?
No. Only publicly disclosed flaws that meet the program’s criteria get one. Some issues are fixed quietly or never reported.
Is a CVSS 10 always worse than a 7?
Not necessarily in practice. A 7 in a public-facing system under active attack can be more urgent than a 10 in a system that is isolated or unused.
Who assigns CVE identifiers?
A coordinated program works with authorized organizations, including many vendors and research groups, which can assign them for the flaws they handle.
Key takeaways
- CVE names a flaw, CVSS rates its severity.
- Scores ignore your environment and real-world exploitation.
- Prioritize by exposure, exploitation and business impact.
- Always read the advisory for versions and mitigations.
