This chapter covers Common Vulnerabilities and Exposures (CVE), the Common Vulnerability Scoring System (CVSS), and the National Vulnerability Database (NVD). These three pillars form the backbone of vulnerability management and are essential for the SY0-701 exam under Objective 2.1 (Exploiting Vulnerabilities). You will learn how vulnerabilities are uniquely identified, how their severity is scored, and how this information is aggregated and made searchable. Understanding these concepts is critical for prioritizing patching, communicating risk, and interpreting security advisories in any enterprise environment.
Jump to a section
Imagine a massive public library that contains every book ever written (all software vulnerabilities). Each book has a unique call number assigned by the Library of Congress — this is the CVE ID (e.g., CVE-2023-1234). The call number is just an identifier; it tells you nothing about the book's content or condition. Now, when a librarian discovers a book is damaged (e.g., torn pages, missing chapters), they produce a condition report that scores the severity: 1–10, where 10 means the book is literally falling apart and could harm a reader. This condition report is the CVSS score. The report includes metrics: how easy is it to access the book (Attack Vector), does the damage require special tools (Attack Complexity), does the reader need a library card (Privileges Required), does the reader have to be in a specific room (User Interaction), and what parts of the book are affected (Confidentiality, Integrity, Availability impacts). The National Vulnerability Database (NVD) is the library's online catalog that stores all call numbers and condition reports. When a patron (security analyst) searches for a specific book, they see the call number and the condition score, helping them decide whether to handle the book with care or avoid it entirely. Just as a librarian assigns the call number and condition report independently, MITRE assigns CVE IDs, while NIST (via NVD) calculates CVSS scores. The library analogy captures the separation of identification (CVE) from severity scoring (CVSS), and the central repository (NVD) that ties them together.
Common Vulnerabilities and Exposures (CVE) is a dictionary of publicly known cybersecurity vulnerabilities. Each vulnerability receives a unique CVE ID (e.g., CVE-2024-3094) that serves as a standard identifier. The system is maintained by MITRE Corporation and is sponsored by the US Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA). CVE does not contain technical details, risk scores, or remediation information — it is purely an identity.
The Common Vulnerability Scoring System (CVSS) is a framework for assigning numerical scores (0.0–10.0) to vulnerabilities to reflect their severity. It is maintained by the Forum of Incident Response and Security Teams (FIRST). The current version is CVSS v3.1 (SY0-701 tests on v3.x, not v2 or v4). CVSS scores are calculated from three metric groups: Base, Temporal, and Environmental. The Base metrics produce a score between 0 and 10, with categories: None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), Critical (9.0–10.0).
The National Vulnerability Database (NVD) is the US government repository of vulnerability management data. It is managed by the National Institute of Standards and Technology (NIST). NVD takes CVE IDs and enriches them with CVSS scores, fix information (e.g., patch links), and affected product lists. NVD also provides a searchable API and downloadable data feeds.
How They Work Mechanically
Discovery and CVE Assignment: A researcher or vendor discovers a vulnerability. They report it to MITRE (or a CVE Numbering Authority, CNA). If the vulnerability is accepted, MITRE assigns a CVE ID. The CVE record includes the ID, a brief description (e.g., "Buffer overflow in XYZ software version 1.0 allows remote code execution"), and references (e.g., vendor advisory, exploit code URL).
2. CVSS Scoring: NVD analysts (or sometimes the vendor) calculate the CVSS score using the CVSS calculator. The Base metrics are: - Attack Vector (AV): Network (N), Adjacent (A), Local (L), Physical (P) - Attack Complexity (AC): Low (L), High (H) - Privileges Required (PR): None (N), Low (L), High (H) - User Interaction (UI): None (N), Required (R) - Scope (S): Unchanged (U), Changed (C) - Confidentiality (C): None (N), Low (L), High (H) - Integrity (I): None (N), Low (L), High (H) - Availability (A): None (N), Low (L), High (H)
The formula combines these into a vector string (e.g., CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and a numeric score (e.g., 9.8).
NVD Publication: Once the CVE is assigned and scored, NVD publishes the record. The NVD entry includes the CVE ID, CVSS v3.1 score, vector string, affected software versions, and a list of references. NVD also categorizes vulnerabilities using CWE (Common Weakness Enumeration) and maps them to CPE (Common Platform Enumeration) for product identification.
Key Components and Standards
CVE ID Format: CVE-YYYY-NNNNNN (year and at least 4 digits, e.g., CVE-2024-21626). The ID is permanent and never reused.
CVE Numbering Authority (CNA): Organizations authorized to assign CVE IDs (e.g., Microsoft, Google, Red Hat). There are over 200 CNAs.
CVSS Vector String: A compact representation of all metric values. Example: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
CVSS Score Formula: The Base score is calculated using a weighted formula that considers the impact sub-score (ISS) and exploitability sub-score. The formula is complex but you only need to know the categories and that scores are computed algorithmically.
NVD Data Feeds: Available in JSON, XML, and CSV formats. They are updated every 2 hours.
CWE: A list of software weakness types (e.g., CWE-79: Cross-site Scripting). NVD maps CVE to CWE.
CPE: A standardized way to name software products (e.g., cpe:2.3:a:microsoft:internet_explorer:11.0:*:*:*:*:*:*:*).
How Attackers and Defenders Use These
Attackers monitor CVE and NVD to find vulnerabilities in target systems. They look for high CVSS scores (especially 9.0+ Critical) that are easy to exploit (low attack complexity, no privileges required). They also check for proof-of-concept (PoC) code in references. For example, the Log4j vulnerability (CVE-2021-44228) had a CVSS score of 10.0 (Critical) and was widely exploited within hours.
Defenders use CVE and NVD to prioritize patching. They filter by CVSS score, affected products, and exploitability. They also subscribe to NVD data feeds to automate vulnerability scanning. Tools like Nessus, Qualys, and OpenVAS use NVD data to identify vulnerable software. For example, if a scanner finds Apache Log4j 2.14.1, it checks NVD for related CVEs and reports CVE-2021-44228 with a CVSS 10.0 and a recommendation to upgrade to 2.17.0.
Real Command/Tool Examples
Search NVD via web: https://nvd.nist.gov/vuln/search
NVD API: https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2024-3094 returns JSON with CVSS scores, descriptions, and references.
CVSS Calculator (FIRST): https://www.first.org/cvss/calculator/3.1
cve-search tool: cve-search -p apache:log4j -f 2.14.1 returns CVEs for that product.
jq to parse NVD JSON: curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2024-3094' | jq '.vulnerabilities[0].cve.metrics.cvssMetricV31[0].cvssData.baseScore'
Exploitability vs. Impact
CVSS separates exploitability (how easy it is to exploit) from impact (what damage is done). Exploitability metrics: AV, AC, PR, UI. Impact metrics: C, I, A. A vulnerability with high exploitability but low impact (e.g., denial of service on a non-critical system) might score Medium. Conversely, a vulnerability with low exploitability but high impact (e.g., requires physical access but leaks all data) might also score Medium. The exam tests your ability to interpret these metrics.
Temporal and Environmental Metrics
Temporal metrics adjust the score over time based on exploit code maturity, remediation level, and report confidence. Environmental metrics allow an organization to customize the score for their specific environment (e.g., modified impact metrics). For SY0-701, you need to know that these exist but focus on Base metrics.
Common Mistakes on the Exam
Confusing CVE with CVSS: CVE is an ID, CVSS is a score.
Thinking CVSS is the only factor for prioritization: Business impact and exploitability in the wild also matter.
Assuming a high CVSS score means the vulnerability is easy to exploit: A score of 9.0 could be due to high impact even if attack complexity is high.
Forgetting that CVSS v3.1 uses a 0-10 scale, not 1-10 (0.0 is possible).
1. Discover and Report Vulnerability
A security researcher or vendor identifies a new vulnerability, such as a buffer overflow in a widely used library. They document the technical details: affected software versions, attack vector, and proof of concept. They then report it to the appropriate CVE Numbering Authority (CNA) — for example, if it's in Microsoft software, they report to Microsoft's CNA. The CNA reviews the report to confirm it is a valid vulnerability and not a duplicate. If accepted, the CNA reserves a CVE ID. The researcher may also publish a blog post or advisory, but the official CVE record is not yet public. During this step, the vulnerability is typically under embargo until a patch is ready.
2. Assign CVE ID and Publish
The CNA assigns a unique CVE ID (e.g., CVE-2024-12345) and creates a brief description. The description follows a standard format: '[Type] in [Product] before [Version] allows [Attacker] to [Impact] via [Vector].' Example: 'Buffer overflow in XYZ Server before 5.6 allows remote attackers to execute arbitrary code via a crafted HTTP request.' The CNA also adds references: vendor advisory URL, patch link, and possibly exploit code URL. The CVE record is then published to the CVE List (cve.mitre.org). The publication date is recorded. At this point, the vulnerability is publicly known.
3. NVD Enrichment and CVSS Scoring
NVD analysts retrieve the new CVE record from the CVE List. They analyze the vulnerability details and assign a CVSS v3.1 Base score. They use the CVSS calculator to determine the vector string. For example, for a remote code execution vulnerability that requires no authentication and no user interaction, the vector might be AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, yielding a score of 9.8 (Critical). They also map the vulnerability to CWE (e.g., CWE-120: Buffer Copy without Checking Size) and CPE (e.g., cpe:2.3:a:xyz:xyz_server:5.5:*:*:*:*:*:*:*). The enriched record is then added to the NVD database and becomes searchable via the NVD website and API. This step typically takes a few days but can be expedited for critical vulnerabilities.
4. Vulnerability Scanning and Detection
Security tools like Nessus, Qualys, or OpenVAS download the latest NVD data feeds. When scanning a target network, they compare installed software versions against the CPE entries in NVD. If a match is found (e.g., XYZ Server 5.5 is installed and CVE-2024-12345 affects versions before 5.6), the scanner reports the vulnerability. The report includes the CVE ID, CVSS score, and a remediation recommendation (e.g., 'Upgrade to version 5.6'). The analyst reviews the scan results, filtering by CVSS score to prioritize critical and high vulnerabilities. They may also check the NVD references for exploit code availability.
5. Prioritization and Remediation
The security team prioritizes remediation based on CVSS score, business impact, and threat intelligence. For a Critical (9.0-10.0) vulnerability with active exploits, they may apply an emergency patch or implement compensating controls (e.g., firewall rules, WAF signatures). For a Medium (4.0-6.9) vulnerability with low exploitability, they may schedule patching during the next maintenance window. The team documents the CVE ID in their ticketing system and tracks remediation progress. After patching, they run a rescan to confirm the vulnerability is no longer present. They also update the asset inventory with the new software version. This step closes the vulnerability management lifecycle.
Scenario 1: Log4j (CVE-2021-44228) Response
In December 2021, the Log4j vulnerability (CVSS 10.0, Critical) was disclosed. Attackers rapidly scanned the internet for vulnerable systems. A SOC analyst at a financial firm received an alert from their vulnerability scanner indicating Apache Log4j 2.14.1 on a critical web server. The analyst checked NVD and saw the CVSS score of 10.0 and that exploit code was publicly available. They immediately escalated to the incident response team. The correct response: isolate the server if possible, apply the vendor patch (upgrade to Log4j 2.17.0), and deploy WAF rules to block JNDI injection attempts. A common mistake: treating it as routine patching and waiting for the next maintenance window, which would have allowed exploitation. The analyst should also check for indicators of compromise (IOCs) in logs for outbound LDAP connections.
Scenario 2: Prioritizing Patches in a Large Environment
A healthcare organization has 500 servers with 1,000 vulnerabilities reported by their scanner. The security engineer uses NVD data to filter by CVSS score: first patch all Critical (9.0+) vulnerabilities. Among these, they find CVE-2023-38146 (CVSS 9.8) affecting Windows Server 2022. They also find CVE-2023-36424 (CVSS 5.5, Medium) affecting a legacy medical device. The engineer correctly prioritizes the Windows vulnerability because it has a higher CVSS score and is remotely exploitable. However, they also consider the business impact: the medical device is patient-facing and cannot be patched immediately. They implement a compensating control: network segmentation to restrict access to the device. A common mistake: patching only by CVSS score without considering exploitability in the wild or business context. The engineer should also check the NVD references for active exploitation indicators.
Scenario 3: False Positive from CPE Mismatch
A vulnerability scanner reports CVE-2024-22394 (CVSS 7.5) affecting 'OpenSSL 1.1.1' on a server. The analyst verifies the server actually runs OpenSSL 1.1.1w, which is not in the affected version range (before 1.1.1v). The scanner incorrectly matched the CPE because the version string was ambiguous. The analyst checks NVD and sees the affected CPE: cpe:2.3:a:openssl:openssl:1.1.1:*:*:*:*:*:*:* (which means all 1.1.1.x versions). However, the vendor advisory clarifies that only versions before 1.1.1v are affected. The correct response: mark the finding as a false positive and update the asset's CPE version to the exact string. A common mistake: blindly accepting the scanner's CVSS score and creating a patch ticket without manual verification, wasting resources.
What SY0-701 Tests on This Objective
Objective 2.1: 'Given a scenario, exploit or mitigate vulnerabilities.' The exam expects you to:
Interpret CVE IDs and CVSS scores to prioritize vulnerabilities.
Understand the difference between CVE (identifier) and CVSS (score).
Know the CVSS v3.1 severity categories: None (0.0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), Critical (9.0-10.0).
Recognize the CVSS vector string components: AV, AC, PR, UI, S, C, I, A.
Understand that NVD is the repository that assigns CVSS scores to CVEs.
Identify that CVE is maintained by MITRE, CVSS by FIRST, and NVD by NIST.
Common Wrong Answers and Why
'CVE provides the severity score.' Wrong because CVE is only an identifier; CVSS provides the score.
'CVSS is maintained by MITRE.' Wrong; CVSS is maintained by FIRST. MITRE maintains CVE.
'NVD assigns CVE IDs.' Wrong; NVD enriches CVEs with scores, but MITRE or CNAs assign IDs.
'A CVSS score of 10.0 means the vulnerability is easy to exploit.' Not necessarily; 10.0 requires maximum impact across all three impact metrics, but exploitability could be high or low. For example, a vulnerability requiring physical access but causing total loss of confidentiality, integrity, and availability could score 10.0 (AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
Specific Terms and Values
CVE ID format: CVE-YYYY-NNNNNN (N is at least 4 digits).
CVSS v3.1 severity categories: 0.0, 0.1-3.9, 4.0-6.9, 7.0-8.9, 9.0-10.0.
CVSS vector string example: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (score 9.8).
Organizations: MITRE (CVE), FIRST (CVSS), NIST (NVD).
CWE: Common Weakness Enumeration (e.g., CWE-79 for XSS).
CPE: Common Platform Enumeration (e.g., cpe:2.3:a:microsoft:windows_10).
Common Trick Questions
'Which of the following is used to identify a specific vulnerability?' The answer is CVE ID, not CVSS score or NVD.
'A vulnerability has a CVSS score of 4.5. What is the severity?' Medium (4.0-6.9).
'Which organization publishes the CVSS standard?' FIRST, not NIST or MITRE.
'What is the purpose of the NVD?' To provide a repository of vulnerability information with CVSS scores and references.
Decision Rule for Eliminating Wrong Answers
On scenario questions, if the question asks about 'identifying a vulnerability,' look for CVE. If it asks about 'severity' or 'scoring,' look for CVSS. If it asks about 'searching for vulnerabilities' or 'getting details,' look for NVD. Remember the mapping: CVE = ID, CVSS = Score, NVD = Database. Also, know that CNAs assign CVE IDs, not NVD.
CVE IDs are unique identifiers for vulnerabilities, formatted as CVE-YYYY-NNNNNN (e.g., CVE-2024-3094).
CVSS v3.1 severity categories: None (0.0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), Critical (9.0-10.0).
CVSS Base metrics: Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), User Interaction (UI), Scope (S), Confidentiality (C), Integrity (I), Availability (A).
NVD is maintained by NIST and provides CVSS scores, CWE mappings, and CPE data for CVEs.
CVE is maintained by MITRE; CVSS is maintained by FIRST.
CVSS vector string example: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (score 9.8).
CVE IDs are never reused; rejected IDs remain in the database as RESERVED or REJECTED.
CVSS scores are not the only factor for prioritization; consider business impact and active exploitation.
Common Weakness Enumeration (CWE) categorizes the type of weakness (e.g., CWE-79 for XSS).
Common Platform Enumeration (CPE) standardizes product names for vulnerability matching.
These come up on the exam all the time. Here's how to tell them apart.
CVE (Common Vulnerabilities and Exposures)
Unique identifier for a vulnerability (e.g., CVE-2024-1234)
Maintained by MITRE
Contains a brief description and references
Does not include a severity score
Used to reference a specific vulnerability across databases
CVSS (Common Vulnerability Scoring System)
Numerical score (0.0-10.0) representing severity
Maintained by FIRST
Includes vector string with metric values (AV, AC, PR, etc.)
Does not identify the vulnerability; only scores it
Used to prioritize remediation efforts
NVD (National Vulnerability Database)
Managed by NIST
Enriches CVE records with CVSS scores, CWE, CPE
Provides searchable database and API
Includes fix information and references
Updates every 2 hours
CVE List (cve.mitre.org)
Managed by MITRE
Contains only basic CVE information (ID, description, references)
Does not include CVSS scores
Serves as the authoritative list of CVE IDs
Updated as new CVEs are assigned
Mistake
CVE and CVSS are the same thing.
Correct
CVE is a unique identifier for a vulnerability; CVSS is a numerical score (0-10) that represents its severity. They are separate but related — CVE identifies, CVSS scores.
Mistake
The NVD assigns CVE IDs.
Correct
CVE IDs are assigned by MITRE or a CVE Numbering Authority (CNA). The NVD enriches CVE records with CVSS scores and other metadata but does not assign the IDs.
Mistake
A CVSS score of 10.0 means the vulnerability is remotely exploitable.
Correct
A score of 10.0 requires maximum impact (C:H/I:H/A:H) and typically low exploitability metrics, but the Attack Vector could be Physical (AV:P) if the impact is still maximum. The vector string determines the specific characteristics.
Mistake
CVSS is the only factor needed to prioritize vulnerabilities.
Correct
CVSS provides a standardized severity score, but prioritization should also consider business impact, threat intelligence (e.g., active exploits), and compensating controls. A high CVSS vulnerability that is not exploitable in your environment may be lower priority.
Mistake
CVE IDs are reassigned if a vulnerability is found to be a duplicate.
Correct
CVE IDs are never reused. If a vulnerability is rejected or found to be a duplicate, the CVE ID is marked as 'RESERVED' or 'REJECTED' but not reassigned to another vulnerability.
CVE (Common Vulnerabilities and Exposures) is a unique identifier for a specific vulnerability, like a product serial number. CVSS (Common Vulnerability Scoring System) is a numerical score (0.0-10.0) that rates the severity of that vulnerability. Think of CVE as the name of a disease and CVSS as its severity on a scale of 1-10. For the exam, remember that MITRE manages CVE and FIRST manages CVSS.
The CVSS Base score is calculated using a formula that combines exploitability metrics (Attack Vector, Attack Complexity, Privileges Required, User Interaction) and impact metrics (Confidentiality, Integrity, Availability). The formula produces a score between 0.0 and 10.0. For example, a vulnerability that is remotely exploitable with no privileges and no user interaction, and that causes complete loss of confidentiality, integrity, and availability, gets a score of 9.8 (Critical). The exact formula is complex but you only need to know the metric groups and the severity categories for the exam.
The National Vulnerability Database (NVD) is a US government repository that takes CVE entries and enriches them with CVSS scores, CWE classifications, CPE product mappings, and remediation links. It is managed by NIST. Security professionals use the NVD to search for vulnerabilities affecting their software, get severity scores, and find patches. For example, if you have Apache Log4j 2.14.1, you can search the NVD for CVE-2021-44228 to see its CVSS score of 10.0 and recommended upgrade to 2.17.0.
This is a CVSS v3.1 vector string. It breaks down as: Attack Vector = Network (remotely exploitable), Attack Complexity = Low (no special conditions), Privileges Required = None, User Interaction = None, Scope = Unchanged (exploit doesn't affect other components), Confidentiality = High, Integrity = High, Availability = High. The resulting Base score is 9.8 (Critical). On the exam, you may need to interpret such a vector to determine the vulnerability's characteristics.
Yes. A CVSS Base score of 0.0 means the vulnerability has no impact on confidentiality, integrity, or availability, and is not exploitable. This could happen if the vulnerability only affects a non-security feature or requires impossible conditions. The severity category for 0.0 is 'None.' On the exam, remember that 0.0 is a valid score.
CVE IDs are assigned by MITRE or by a CVE Numbering Authority (CNA). CNAs are organizations authorized to assign CVE IDs for their own products (e.g., Microsoft, Google, Red Hat). Researchers typically report vulnerabilities to the relevant CNA, who then reserves a CVE ID. The NVD does not assign CVE IDs; it only enriches them.
CWE (Common Weakness Enumeration) categorizes the type of software weakness (e.g., CWE-79 for Cross-site Scripting), while CVE identifies a specific instance of a vulnerability in a particular product. For example, CVE-2024-1234 might be a specific XSS vulnerability in WordPress, and it would be mapped to CWE-79. On the exam, you may see CWE in the context of vulnerability classification.
You've just covered CVEs, CVSS Scoring, and NVD — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?