A CVE (Common Vulnerabilities and Exposures) record is the standard way the security world names and describes a specific weakness in software. When a scanner flags your project, it points you to a CVE. The goal of this tutorial is simple: by the end you will be able to open any CVE and understand what it means for your code, without needing a security background.
Prerequisites
- A CVE ID you want to look up (something like
CVE-2021-44228) - A web browser to reach a public CVE database
- Optional: a terminal, if you want to look CVEs up from the command line
That is genuinely all you need. Reading a CVE is a skill, not a tool purchase.
Step-by-step
-
Find the record. Every CVE lives in public databases. The most common are the National Vulnerability Database (nvd.nist.gov), the official CVE.org list, and OSV (osv.dev) for open-source packages. Paste your CVE ID into any of them. For this walkthrough we will use the well-known
CVE-2021-44228(Log4Shell) as an example because it is heavily documented. -
Read the CVE ID itself. The format is
CVE-YEAR-NUMBER. The year is when the ID was reserved, not always when the bug was found. The number is just a unique counter. The ID tells you nothing about severity on its own — it is only a label. -
Read the description. This is one or two sentences explaining the flaw: what component is affected, what an attacker can do, and under what conditions. For Log4Shell, the description explains that a logging library could be tricked into executing attacker-controlled code. Read this first to decide if it is even relevant to you.
-
Check the CVSS score and severity. CVSS is a number from 0.0 to 10.0 that estimates how bad a flaw is. The bands are: 0.1 to 3.9 is Low, 4.0 to 6.9 is Medium, 7.0 to 8.9 is High, and 9.0 to 10.0 is Critical. Log4Shell scored 10.0. A high score means "pay attention," but it is not the whole story, which we will cover in step 7.
-
Look at the CWE. A CWE (Common Weakness Enumeration) describes the category of bug — for example, SQL injection, path traversal, or deserialization. The CWE helps you understand the root cause and spot similar problems elsewhere in your code.
-
Identify the affected versions. This is the part developers care about most. The record lists which versions of the software are vulnerable and which version contains the fix. If you are on a version outside the affected range, you may not need to act at all.
-
Check exploitation signals. Two extra data points tell you how urgent a CVE really is. The KEV catalog (CISA's Known Exploited Vulnerabilities list) tells you if attackers are actively using it. EPSS is a percentage estimating the chance it will be exploited soon. A Critical CVSS with a low EPSS and no KEV entry is often less urgent than a Medium CVE that is on the KEV list.
-
Look it up from the terminal (optional). If a CVE affects your dependencies, a scanner can confirm it. With the Safeguard CLI you can query a specific CVE directly:
curl -sSfL https://get.safeguard.sh/install.sh | sh
safeguard scan --cve CVE-2021-44228
This tells you whether that CVE is present in the project you are scanning, and which package version introduced it.
How to know it worked
You have read a CVE successfully when you can answer four questions in a sentence each: What is the flaw? How severe is it? Which versions are affected? Is there a fix? If you can answer those, you understand the CVE well enough to make a decision. You do not need to memorize the CVSS math — you just need to know the severity band and whether attackers are using it.
Next steps
Reading one CVE is the foundation. The next skill is doing this at scale, because a real project can surface dozens of CVEs at once. That is where a scanner and a prioritization method save you hours. Learn the underlying vocabulary on our concepts pages, then see how automated software composition analysis maps CVEs to the exact packages in your project. When you are ready to practice, the Safeguard Academy has hands-on exercises for reading and triaging real vulnerability data.
Frequently Asked Questions
What is the difference between a CVE and a CVSS score?
A CVE is the identity of a specific vulnerability — its name and description. A CVSS score is a separate number that estimates how severe that vulnerability is. One CVE has one CVSS base score, but you will often see slightly different scores from different sources because each may weigh the environment differently.
Does a high CVSS score always mean I must fix it immediately?
No. Severity is only one input. A Critical CVE in a component you do not actually use, or in a code path attackers cannot reach, may be far less urgent than a Medium CVE that is on the Known Exploited Vulnerabilities list. Always combine the score with exploitation signals and whether the vulnerable code is reachable in your app.
Where do CVE records come from?
CVEs are assigned by organizations called CNAs (CVE Numbering Authorities), which include vendors, open-source projects, and coordination centers. Once assigned, the record is published to public databases like the NVD and OSV, where anyone can read it for free.
What should I do if there is no fix yet?
If a CVE has no patched version, check the references section for a workaround or mitigation — sometimes disabling a feature or changing a configuration removes the risk. If none exists, document the exposure, monitor for an update, and reduce access to the affected component in the meantime.
Ready to see CVEs mapped to your own code automatically? Create a free account at app.safeguard.sh/register and keep building your skills at the Safeguard Academy.