When you see a vulnerability in a report or security advisory, one of the first things you’ll notice is a score. That number comes from the Common Vulnerability Scoring System, or CVSS.

CVSS is a standardized framework used to evaluate the severity of security vulnerabilities. It gives each vulnerability a numerical score (ranging from 0.0 to 10.0) that helps organizations assess how serious the issue is and how urgently it needs to be addressed. The higher the number, the more severe the vulnerability.

The CVSS system was originally developed by the National Infrastructure Advisory Council and is now maintained by the Forum of Incident Response and Security Teams (FIRST). It’s widely adopted across the security ecosystem, being used by the NVD (National Vulnerability Database), security vendors, bug bounty programs, and developer tools like Snyk.

CVSS is made up of several components. At its core is the Base Score, which reflects the inherent characteristics of a vulnerability that don’t change based on environment or time. For example, how easy it is to exploit, what kind of access an attacker needs, and what impact it has on confidentiality, integrity, and availability. On top of that, CVSS also defines Temporal and Environmental metrics, which allow the score to be refined based on real-world factors, like whether a fix is available or how a specific environment is configured.

Here’s how the scoring generally breaks down:

• 0.0 – 3.9: Low severity
• 4.0 – 6.9: Medium severity
• 7.0 – 8.9: High severity
• 9.0 – 10.0: Critical severity

This gives teams a shared language for discussing risk. Instead of vague labels like “bad” or “urgent,” you get a structured, comparable score that can guide decisions. Understanding CVSS doesn’t mean you have to become a scoring expert, but having a basic grasp of how it works can help you interpret vulnerability reports more accurately and make more informed security decisions.

In this lesson, you’ll learn what CVSS scores mean, how they’re calculated, and how you can use them to assess and prioritize risk in your projects. We’ll break down the components of a CVSS score, show what it looks like in action, and give you practical tips for applying that knowledge to your development workflow.

Security vulnerabilities can show up in your code, your dependencies, your containers, or your infrastructure. When they do, you need to make decisions quickly about what to fix first, what can wait, and what poses the biggest risk. That’s where CVSS becomes essential.

The Common Vulnerability Scoring System (CVSS) offers a standardized way to measure and communicate the severity of a vulnerability. Instead of relying on gut instinct or generic labels, developers and security teams can use CVSS scores to speak a common language. A CVSS score of 9.8 tells you something very different from a 5.6. And those numbers aren’t arbitrary. They’re derived from a consistent formula that weighs key factors like exploitability and impact.

CVSS is especially useful in large or complex environments where vulnerabilities are discovered constantly. If your team is juggling hundreds of open issues, CVSS scores help you prioritize based on risk. Many organizations set internal policies that require high or critical vulnerabilities (CVSS 7.0 and up) to be addressed within a certain timeframe. Having this consistent benchmark allows teams to act faster and with more confidence

But CVSS isn’t just for compliance or triage, it’s also part of how tools like Snyk provide value directly to developers. When a vulnerability is found in a dependency or container, the CVSS score is often the first signal you get about how serious the problem is. That number gives context at a glance, helping you make smart trade-offs between fixing an issue and staying focused on feature work.

Importantly, while CVSS scores are helpful, they aren’t everything. A medium-severity vulnerability in a critical system might matter more than a high-severity one in an unused dev tool. That’s why many tools (and teams) combine CVSS with other signals, like exploitability, popularity, or environment-specific impact, to make more nuanced decisions.

Still, if you’re a developer trying to build secure software, understanding CVSS gives you an edge. It helps you read reports more accurately, prioritize effectively, and talk about security with more precision.

The CVSS system is still evolving, and CVSS 4.0, released in 2023, introduces several important updates. It adds more scoring granularity, especially around impact and exploitability, and introduces new metric groups.

One major shift in CVSS 4.0 is the move away from a single all-purpose score. Instead, it encourages more context-aware scoring, helping organizations evaluate risk based on their specific environment.

Although some tools and databases still use CVSS 3.1 as their default, adoption of CVSS 4.0 is growing. As a developer, being aware of these changes will help you interpret scores more accurately as they begin to appear in your tools and vulnerability reports.

A prime real-world example of the Common Vulnerability Scoring System (CVSS) in action is the critical "Log4Shell" vulnerability CVE-2021-44228 discovered in the widely used Java logging library, Apache Log4j. This vulnerability was assigned a CVSS score of 10.0, the highest possible rating, signifying a critical severity.

The Vulnerability

The Log4Shell vulnerability allowed for remote code execution (RCE), meaning an attacker could run any code on a vulnerable server without needing to be authenticated. Because Log4j is used in countless applications and services, the potential impact was massive. The high CVSS score was a direct result of these factors:

• Attack Vector (AV): Network - The vulnerability could be exploited over a network.
• Attack Complexity (AC): Low - It was relatively easy for an attacker to exploit.
• Privileges Required (PR): None - The attacker did not need any special permissions.
• User Interaction (UI): None - No action was needed from any user.
• Scope (S): Changed - The vulnerability could affect resources beyond the scope of the vulnerable component.
• Confidentiality (C): High - An attacker could access all data on the system.
• Integrity (I): High - An attacker could modify any file on the system.
• Availability (A): High - An attacker could completely shut down the system.

When scanning your code, you may see something like this:

To fix this, simply upgrade your log4j version:

CVSS 4.0 introduces a more flexible and context-aware model for scoring vulnerabilities. Like previous versions, the Base Score still ranges from 0.0 to 10.0, but the way that score is calculated has changed. And unlike older versions, CVSS 4.0 introduces two additional scores alongside the Base Score:

• Base Score – inherent technical severity (most commonly seen)
• Threat Score – adds exploitability intel (e.g., known exploits)
• Environmental Score – adjusts severity based on your specific environment

Most developer tools (like Snyk) use the Base Score by default

CVSS 4.0 Base Metrics

You can use the CVSS 4.0 calculator to get your scoring.

As a developer, you don’t need to memorize the entire CVSS rubric, but knowing how to read and interpret CVSS scores can help you make smarter, faster decisions during development and remediation.

Prioritize what matters

Modern development workflows generate a lot of security noise. If you're scanning code, containers, and open source dependencies regularly (as you should be!), you're going to see dozens or even hundreds of issues. CVSS helps cut through the noise:

• High or critical severity (CVSS 7.0–10.0): Stop and evaluate. If it's exploitable and reachable in your code, fix it ASAP.
• Medium (CVSS 4.0–6.9): Evaluate in context. It may not be urgent, but consider mitigating or monitoring.
• Low (CVSS 0.1–3.9): Often minor issues, informational in nature, or hard to exploit — but still worth understanding.

Don’t rely on the score alone

CVSS gives you a snapshot of severity, but not the full story. For example, a critical score (like 9.8) is only relevant if the affected code is actually used and exposed. A low score might still be a problem if it’s part of a critical business function or affects sensitive data. Combine CVSS with reachability data, exploitability context, and business impact to guide your response.

CVSS is a widely used tool for assessing vulnerability severity, but it has its flaws, and it’s important for developers to understand where it falls short.

CVSS doesn’t measure actual risk

CVSS scores reflect inherent severity, not actual risk to your project. For example:

• A library in your codebase may have a critical CVSS 9.8 vulnerability. But if it’s not used or exposed in any runtime path, it might not pose any real danger.
• Conversely, a medium severity vulnerability might be easily exploitable in your specific environment due to how it’s configured or deployed.

CVSS doesn’t account for:

• Whether the vulnerable code is reachable
• Whether there are other mitigating controls
• The business impact of an exploit

This is why tools that combine CVSS with reachability analysis, exploit maturity, or runtime context are more useful in practice.

Scoring can be inconsistent

CVSS scoring depends on human judgment. Different organizations may assign slightly different base scores for the same vulnerability based on how they interpret:

• Attack complexity
• Required privileges
• Scope of impact

Despite these limitations, CVSS remains a helpful triage tool, especially when used alongside other signals. It’s not perfect, but it’s part of the bigger picture of vulnerability management.

Want to go deeper into how CVSS works and how it impacts your day-to-day as a developer? Check out these resources:

• CVSS 4.0 Specification Documentation – FIRST.org - Official spec covering how CVSS 4.0 works, how scores are calculated, and what the new metrics mean.
• CVSS v4.0 Calculator – FIRST.org - Try calculating scores yourself based on real-world CVEs or sample vulnerabilities.
• Snyk Learn: What is a CWE? - If you’re curious how CVSS ties in with Common Weakness Enumeration (CWE), this is a great companion lesson.