Primer - Beyond the Score: Navigating CVSS from v2.0 to v4.0 for Effective Vulnerability Disclosure

https://unattributed.blog/posts/cvss-standards-vulnerability-disclosure-nvd-guide

As security researchers, the language we use to describe a vulnerability’s risk is as critical as the discovery itself. The Common Vulnerability Scoring System (CVSS) is our shared lexicon, but with multiple versions in active use, its nuances can be a source of confusion rather than clarity.

This post will demystify the evolution of CVSS, from the legacy of v2.0 to the cutting-edge v4.0. More importantly, we’ll translate this knowledge into actionable guidance for how to properly document and submit your security findings to the National Vulnerability Database (NVD), ensuring your hard work has the maximum impact.

The Evolution of a Standard: CVSS v2.0, v3.x, and v4.0

CVSS provides a framework for capturing the principal characteristics of a vulnerability. The numerical score (0.0-10.0) it generates has become a universal shorthand for severity. However, the standard has undergone significant refinements to keep pace with modern threats.

CVSS v2.0: The Foundation

Introduced in 2007, CVSS v2.0 established the core triad of metrics: Base, Temporal, and Environmental [1]. While foundational, it was often criticized for its vagueness. Key limitations included:

  • Subjective “Access Complexity”: Terms like “Medium” were open to interpretation.
  • No “Scope” Concept: It couldn’t accurately score vulnerabilities that crossed security boundaries, like a virtual machine escape.
  • Oversimplified Impact: The “Confidentiality, Integrity, Availability” impacts were only rated as Partial or Complete, lacking granularity.

Example v2.0 Vector: AV:N/AC:L/Au:N/C:P/I:P/A:P

CVSS v3.x: The Modern Baseline

A major overhaul, CVSS v3.0 (2015) and its minor update v3.1 (2019) addressed v2.0’s key shortcomings [2, 3]. It is the current de facto standard for the industry. Critical changes included:

  • The Introduction of Scope (S): This metric defines if a vulnerability can affect components beyond its own authority (e.g., from a guest OS to the host hypervisor).
  • Increased Granularity: “Attack Complexity” was refined, and a new User Interaction (UI) metric was added to account for attacks requiring user action.
  • Refined Privileges: “Authentication” became Privileges Required (PR), more precisely defining the attacker’s privilege level.

Example v3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CVSS v4.0: The Future of Precision

Published in 2023, CVSS v4.0 is the next-generation standard designed for greater precision and to cover new domains like IoT and Operational Technology (OT) [4]. Its most significant advancements are:

  • New Metric Categories: It introduces the “Threat” group (replacing Temporal) and, crucially, adds “Safety” and “Automation” metrics to the Environmental group, which are vital for vulnerabilities with potential physical impacts.
  • Clarity and Specificity: “User Interaction” is split into Passive and Active, and a new Attack Requirements (AT) metric covers prerequisites like a man-in-the-middle position.
  • New Scoring Nomenclature: Scores are now labeled as CVSS-B (Base), CVSS-BT (Base + Threat), etc., with CVSS-BTE representing the full score.

Example v4.0 Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Crafting the Perfect Submission: A Researcher’s Guide to NVD and CVE

The goal of finding a vulnerability is only half achieved if it is not properly communicated and documented. Here’s how to align your process with the expectations of CVE Numbering Authorities (CNAs) and the NVD.

1. Pre-Submission: Documenting Your Findings

Before you even think about a CVE ID, your private report to the vendor must be impeccable. A well-structured report, as recommended by practices like the “Vulnerability Description Ontology (VDO)” from Carnegie Mellon’s CERT/CC, enables automation and clear understanding [5].

Your report should include:

  • Executive Summary: A concise, non-technical overview of the vulnerability and its potential business impact.
  • Technical Details:
    • Affected Product/Versions: Be precise.
    • Attack Vector: The sequence of actions required to exploit the vulnerability (e.g., network-based, local, physical).
    • Attack Scenario (Proof of Concept): A step-by-step walkthrough. This is not just exploit code; it’s a narrative that explains how the flaw is triggered.
    • Evidence: Screenshots, packet captures, or system logs that corroborate your findings.
  • Impact Analysis: A preliminary assessment of the consequences—data theft, privilege escalation, denial-of-service, etc. This is where you can propose a CVSS vector string.

2. Submission for CVE Candidacy

The CVE program is the dictionary of publicly known cybersecurity vulnerabilities. You typically request a CVE ID through a CNA [6].

  • When to Submit: Submit after the vendor has confirmed the vulnerability and a patch is imminent or available. Coordinated disclosure is key.
  • What to Provide the CNA: They will often have a template, but your well-documented report from the previous step will form the core of the submission. Clearly state why the issue constitutes a security vulnerability and not just a bug.

3. Crafting the Public Disclosure for NVD

Once a CVE ID is assigned, the NVD analyzes and enriches it. Your public disclosure (e.g., a blog post, GitHub advisory) is the primary source for this analysis. To ensure a smooth and accurate process, structure your public disclosure to include:

  • A Clear, Unambiguous Description: Write a description that can stand alone without the context of your full blog post. The NVD analyst will use this.
  • The CVSS Vector String: Always provide the full vector string, not just the base score. For example, CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N provides infinitely more context than just “CVSS 4.1”. Explicitly state which CVSS version you are using.
  • References: Link to the vendor advisory, your detailed analysis, the patch/commit, and any other relevant resources.
  • CWE Identification: Suggest the relevant Common Weakness Enumeration (CWE) ID (e.g., CWE-89: SQL Injection). This helps categorize the flaw [7].

Best Practices for the Modern Researcher

  1. Default to CVSS v3.1: Until v4.0 tooling is ubiquitous, use v3.1 for your submissions. The NVD currently scores all CVEs using v3.0/v3.1 [8].
  2. Justify Your Score: In your report, briefly explain your reasoning for the chosen vector. For instance: “I scored Attack Complexity as ‘High’ because exploitation requires winning a race condition.”
  3. Engage with the CNA Early: If you’re unsure who the correct CNA is for a product, use the CNA of Last Resort program [6].
  4. Prioritize Clarity Over Hype: Avoid sensationalist language. A factual, professional tone increases the likelihood of your report being taken seriously and processed efficiently.

Conclusion: From Finder to Force Multiplier

Understanding the trajectory of CVSS—from the broad strokes of v2.0 to the precise, safety-conscious framework of v4.0—empowers us to be better communicators. By meticulously documenting our findings and aligning our submissions with the structured processes of CNAs and the NVD, we do more than just report bugs. We contribute vital, actionable intelligence that strengthens the entire digital ecosystem.

Your diligence in crafting the narrative around a vulnerability is what transforms a line of code into a catalyst for a more secure future.

References

[1] Mell, P., Scarfone, K., & Romanosky, S. (2007). A Complete Guide to the Common Vulnerability Scoring System Version 2.0. Forum of Incident Response and Security Teams (FIRST). Retrieved from https://www.first.org/cvss/v2/guide [2] Mell, P., Scarfone, K., & Romanosky, S. (2015). Common Vulnerability Scoring System Version 3.0: Specification Document. FIRST. Retrieved from https://www.first.org/cvss/v3.0/specification-document [3] Mell, P., Scarfone, K., & Romanosky, S. (2019). Common Vulnerability Scoring System Version 3.1: Specification Document. FIRST. Retrieved from https://www.first.org/cvss/v3.1/specification-document [4] FIRST. (2023). Common Vulnerability Scoring System Version 4.0: Specification Document. FIRST. Retrieved from https://www.first.org/cvss/v4-0/specification-document [5] Householder, A., Arnold, D., & Spring, J. (2021). Vulnerability Description Ontology (VDO): A unified framework for describing vulnerabilities. Carnegie Mellon University, Software Engineering Institute. Retrieved from https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=644300 [6] The MITRE Corporation. (2023). CVE - Request a CVE ID. Retrieved from https://www.cve.org/RequestCveID [7] MITRE. (2023). Common Weakness Enumeration (CWE). Retrieved from https://cwe.mitre.org/ [8] National Institute of Standards and Technology (NIST). (2023). National Vulnerability Database (NVD) - Vulnerability Metrics. Retrieved from https://nvd.nist.gov/vuln-metrics/cvss