# What Is a Vulnerability and How Are They Scored
A vulnerability is a weakness in software, hardware, configuration, or process that an attacker can exploit to gain unauthorized access, cause harm, or extract data. Vulnerabilities exist because systems are built by humans under real constraints: time pressure, shifting requirements, incomplete threat models, and libraries written years before modern attack techniques existed. The CVE (Common Vulnerabilities and Exposures) system gives each discovered vulnerability a unique identifier so that defenders, vendors, and researchers can communicate about the same flaw without ambiguity. The CVSS (Common Vulnerability Scoring System) then assigns a numeric score reflecting severity, helping security teams decide which vulnerabilities to fix first. Without these two systems working together, vulnerability management becomes a disorganized, subjective process where every team argues about priority instead of fixing problems.
---
A vulnerability is a flaw in a system that, when exploited, allows a threat actor to violate the confidentiality, integrity, or availability of that system or its data. The formal definition in NIST SP 800-30 describes it as "a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source."
Vulnerabilities are distinct from threats and risks. A threat is the agent or event that might exploit a vulnerability. A risk is the probability that exploitation occurs combined with the impact if it does. Confusing these three terms leads to poor decision-making. A vulnerability sitting on a system that has no network exposure and no privileged data carries much lower risk than the same vulnerability on an internet-facing server storing payment card data.
Vulnerabilities are also distinct from misconfigurations, though the line blurs in practice. A buffer overflow in a vendor's code is a vulnerability. Leaving an S3 bucket publicly readable is a misconfiguration. Both can be scored and remediated, but they originate differently and require different remediation paths. CWE (Common Weakness Enumeration) classifies the underlying weakness types, such as improper input validation (CWE-20) or use-after-free (CWE-416), while CVE tracks specific instances of those weaknesses in specific products.
Subtypes worth distinguishing:
---
When a researcher, vendor, or automated scanner discovers a new vulnerability, it gets reported to a CVE Numbering Authority (CNA). CNAs include major vendors like Microsoft and Google, as well as independent bodies like MITRE, which operates the root CNA. The CNA reviews the submission and assigns a CVE ID in the format CVE-[YEAR]-[NUMBER], for example CVE-2021-44228, which is the Apache Log4Shell vulnerability.
The CVE entry includes a description of the flaw, the affected product and version ranges, and references to advisories, patches, and researcher write-ups. The National Vulnerability Database (NVD), maintained by NIST, then enriches the CVE entry with CVSS scores, CWE classifications, and CPE (Common Platform Enumeration) identifiers that allow automated tools to map vulnerabilities to specific software in an organization's inventory.
CVSS version 3.1 (and the newer CVSS 4.0) scores vulnerabilities on a 0.0 to 10.0 scale. The score is calculated from three metric groups:
Base Score: Reflects the intrinsic characteristics of the vulnerability, independent of environment or time. Key sub-metrics include:
A CVE-2021-44228 (Log4Shell) base score of 10.0 reflects network attack vector, low complexity, no privileges required, no user interaction, changed scope, and high impact across all three CIA dimensions. That combination means any attacker on the internet can exploit the flaw remotely with no authentication, gaining full control of the target system.
Temporal Score: Adjusts the base score based on current exploit availability (proof-of-concept versus weaponized), remediation status (official fix versus workaround versus none), and report confidence. A 9.8 base score drops in temporal score if no public exploit exists and the vendor has issued a patch.
Environmental Score: Allows individual organizations to adjust the score based on their specific context. A vulnerability in a component your organization does not deploy scores 0.0 in practice. One affecting systems that handle your most sensitive data can be adjusted upward.
Consider CVE-2023-34362, a SQL injection vulnerability in MOVEit Transfer, the managed file transfer application. The base CVSS score was 9.8: network exploitable, low complexity, no privileges required, no user interaction, and high impact on confidentiality, integrity, and availability. The Cl0p ransomware group exploited this vulnerability before a patch existed, extracting data from hundreds of organizations including government agencies and major corporations.
A security team using proper vulnerability management would have:
Teams that lacked an accurate software inventory did not know they ran MOVEit. Teams that did not monitor vulnerability feeds found out about the exploitation from incident responders, not from their own detection systems.
---
Unmanaged vulnerabilities are the single most reliable path attackers use to gain initial access and escalate privileges inside an organization. The Verizon Data Breach Investigations Report consistently identifies exploitation of vulnerabilities as one of the top three initial access vectors, alongside stolen credentials and phishing. This is not theoretical. It is the pattern observed across thousands of confirmed breaches analyzed every year.
The business impact of a successful exploit ranges from operational disruption to complete organizational failure. The 2017 WannaCry outbreak exploited CVE-2017-0144, the EternalBlue SMB vulnerability, on unpatched Windows systems. NHS hospitals in the United Kingdom canceled thousands of appointments and surgeries. The estimated global cost exceeded four billion dollars. The patch for EternalBlue had been available for approximately two months before the outbreak began. Organizations that applied the patch in time were not affected. Those that did not were compromised within minutes of the ransomware reaching their networks.
The most dangerous misconception in vulnerability management is that a high CVSS score automatically means the vulnerability is the most urgent priority. CVSS measures severity, not risk. A CVSS 9.8 vulnerability affecting software your organization does not run is irrelevant. A CVSS 5.4 vulnerability in your public-facing authentication system, for which a working exploit is publicly available, demands immediate attention. The KEV catalog, threat intelligence feeds, and environmental scoring exist precisely to help teams move from severity to actual risk ranking.
A second misconception is that patching is the only remediation path. In many environments, patches cannot be applied immediately because of application compatibility requirements, change management timelines, or vendor support constraints. Compensating controls such as network segmentation, web application firewalls, and monitoring rules can reduce the exploitability window while a permanent patch is scheduled. These are not permanent substitutes for patching, but they reduce risk during the gap period.
Organizations that lack a formal vulnerability management program also face direct compliance consequences. PCI DSS requires organizations to address high-risk vulnerabilities within one month. HIPAA's Security Rule requires risk analysis that includes vulnerability assessment. NIST CSF includes vulnerability management as a core function. Audit findings related to unpatched critical vulnerabilities generate regulatory scrutiny and, in breach scenarios, can increase liability.
---
CDA operates vulnerability management under the Planetary Defense Model (PDM) within the Vulnerability Surface Domain (VSD). The governing methodology is Continuous Surface Reduction (CSR), expressed operationally as: every surface you expose is a surface we eliminate.
Most organizations treat vulnerability management as a periodic activity, running scans quarterly or monthly and working through findings on a backlog. CDA treats it as a continuous operational function. The difference is not philosophical; it is structural. Continuous scanning means findings are identified within hours of a new CVE being published. Enrichment pipelines automatically correlate CVE data with the client's confirmed software inventory, filter out irrelevant findings, and produce a prioritized action list based on actual risk, not CVSS score alone.
CDA's VSD methodology explicitly incorporates the CISA KEV catalog as a mandatory escalation trigger. When a CVE enters the KEV catalog, it means federal agencies have already confirmed active exploitation. CDA treats that event as an emergency requiring response within 24 hours, regardless of where the finding sits in a normal remediation queue.
CDA also rejects the common practice of accepting risk on vulnerabilities that are technically difficult to exploit. Attackers invest in developing exploit chains. A vulnerability that is hard to exploit today becomes part of a working exploit kit within months if it remains unpatched. The CSR methodology requires either remediation or a documented compensating control with a defined review date. Open-ended risk acceptance is not a permissible outcome in the PDM framework.
On the measurement side, CDA tracks Mean Time to Remediate (MTTR) by severity tier and monitors the ratio of newly discovered vulnerabilities to closed vulnerabilities each week. A growing backlog is treated as a program failure requiring leadership escalation, not a normal operational condition. The goal is a shrinking attack surface, measured in confirmed closed findings, not in scan completion rates.
---
---
---