A software vulnerability is a flaw or weakness in software that can be exploited by an attacker to cause the software to behave in unintended ways, often allowing the attacker to access data, execute unauthorized code, or disrupt the software’s operation. Vulnerabilities are properties of the software itself, present from the moment the flawed code is written, and they may remain undiscovered and unaddressed for months or years.
Understanding software vulnerabilities is relevant to every software publisher, not just those building large enterprise systems. A vulnerability in a desktop application, a library, a command-line tool, or a plugin can be exploited to harm users, and the publisher bears responsibility for addressing it. This article covers what vulnerabilities are, how they are classified and measured, how they move from discovery to patch, and how they relate to software distribution integrity practices like code signing.
The Vocabulary: Vulnerability, Exploit, and Attack
These three terms are frequently used interchangeably but describe different things in the vulnerability lifecycle:
- Vulnerability: A weakness or flaw in software, hardware, or a system component. The vulnerability exists whether or not anyone has discovered it or tried to exploit it. It is a property of the thing, not an action upon it.
- Exploit: A piece of code, technique, or methodology that takes advantage of a specific vulnerability to cause it to behave in an unintended way. An exploit turns a theoretical vulnerability into a practical attack capability.
- Attack: The actual use of an exploit against a target. An attack requires a motivated attacker, a target with the vulnerable software, and often some means of delivery (a malicious link, a compromised server, a downloaded file).
A vulnerability may exist for years without a known exploit. An exploit may be developed but not used in active attacks. Understanding this distinction helps prioritize responses: a vulnerability with a known exploit actively used in attacks requires faster response than an equal-severity vulnerability with no known exploit.
Major Categories of Software Vulnerabilities
The Common Weakness Enumeration (CWE) maintained by MITRE catalogs hundreds of distinct weakness types. The following categories account for the majority of vulnerabilities in practice:
Memory safety vulnerabilities (C, C++, and systems software)
Memory safety vulnerabilities arise when software allows operations that read or write memory outside intended bounds, or access memory after it has been freed. Buffer overflows, stack overflows, heap overflows, use-after-free errors, and null pointer dereferences are common examples. These vulnerabilities can allow an attacker to overwrite program control data (return addresses, function pointers) and redirect execution to attacker-controlled code.
Memory safety vulnerabilities are predominantly associated with C and C++ code, which gives the programmer direct control over memory without automatic safety checks. The Linux kernel, many system libraries, Windows and macOS core components, and many widely-deployed network services are written in C and C++. Memory safety vulnerabilities in these components can have broad impact. Newer systems languages like Rust address memory safety at the language level by enforcing safety properties at compile time.
Injection vulnerabilities
Injection vulnerabilities occur when untrusted data is included in a command or query without proper validation or escaping, causing the data to be interpreted as instructions rather than as data. SQL injection, command injection, LDAP injection, XML injection, and cross-site scripting (XSS) are injection vulnerability types. In each case, an attacker who can control input to an injectable function can cause the system to execute attacker-controlled instructions.
SQL injection remains one of the most prevalent vulnerability classes in web applications despite being well-understood and preventable. Parameterized queries and prepared statements eliminate SQL injection at the database query level. XSS vulnerabilities allow attackers to inject scripts into web pages viewed by other users, enabling session hijacking and credential theft.
Authentication and authorization vulnerabilities
Authentication vulnerabilities allow attackers to bypass the controls that verify identity. Weak passwords, password reuse, insecure credential storage (plaintext passwords in databases), broken session management, and multi-factor authentication bypass are authentication vulnerabilities. Authorization vulnerabilities allow authenticated users to access resources or perform actions they should not be permitted to: horizontal privilege escalation (accessing another user’s data) and vertical privilege escalation (gaining administrative access without authorization).
Cryptographic vulnerabilities
Cryptographic vulnerabilities arise from using weak or broken cryptographic algorithms, implementing cryptography incorrectly, or managing cryptographic keys insecurely. Using MD5 or SHA-1 for password hashing, using ECB mode for encryption, generating random numbers without sufficient entropy, or hardcoding encryption keys in source code are cryptographic vulnerabilities. These vulnerabilities often do not produce observable errors during normal operation, making them difficult to detect without specific security review.
Dependency and supply chain vulnerabilities
Modern software depends heavily on third-party libraries and components. A vulnerability in a dependency becomes a vulnerability in every application that uses it. The Log4Shell vulnerability (CVE-2021-44228) in the Log4j logging library affected thousands of applications globally because Log4j was a nearly ubiquitous Java dependency. The dependency chain can be deep: an application depends on library A, which depends on library B, which contains the vulnerability.
Software composition analysis (SCA) tools scan applications for known vulnerable dependencies by checking component versions against vulnerability databases like the National Vulnerability Database (NVD). Dependency vulnerabilities are addressed by updating to a patched version of the dependency.
Configuration vulnerabilities
Configuration vulnerabilities arise not from flaws in code but from how software is deployed and configured. Default credentials (unchanged default administrator passwords), exposed debugging endpoints, overly permissive file system permissions, disabled security features, and open firewall rules are configuration vulnerabilities. These are often preventable through security hardening practices applied during deployment.
CVE and CVSS: How Vulnerabilities Are Identified and Measured
CVE: Common Vulnerabilities and Exposures
CVE is a standardized system for naming and identifying publicly known software vulnerabilities. Each CVE entry receives a unique identifier in the format CVE-YEAR-NUMBER (for example, CVE-2021-44228 for Log4Shell). The CVE program is maintained by MITRE and sponsored by the US Department of Homeland Security. National Vulnerability Databases (the US NVD and equivalents in other countries) enrich CVE entries with additional technical analysis and scoring.
When a new vulnerability is discovered and publicly disclosed, a CVE identifier is assigned by a CVE Numbering Authority (CNA). CNAs include software vendors (Microsoft, Google, Apple, Red Hat), coordinating bodies, and MITRE itself. The CVE identifier becomes the standard way to reference the vulnerability across security tools, advisories, and communications.
CVSS: Common Vulnerability Scoring System
CVSS provides a standardized numerical score for vulnerability severity, ranging from 0.0 to 10.0. The score is calculated from base metrics (properties of the vulnerability itself), temporal metrics (exploit code availability, patch status), and environmental metrics (specific deployment context). Higher scores represent greater severity.
CVSS v3.1 and v4.0 are currently in use. A CVSS score of 9.0 or higher is Critical; 7.0 to 8.9 is High; 4.0 to 6.9 is Medium; 0.1 to 3.9 is Low. Organizations use CVSS scores to prioritize patching: critical and high vulnerabilities typically warrant immediate response.
CVSS scores should be interpreted in context. A CVSS 9.8 vulnerability in software that is not deployed in your environment is lower priority than a CVSS 7.0 vulnerability in software that is exposed to the public internet. The CVSS score measures the theoretical severity of the vulnerability; risk assessment considers deployment context and likelihood of exploitation.
| CVSS score range | Severity level | Typical response timeline |
| 9.0 – 10.0 | Critical | Immediate: hours to 1-2 days in most organizations |
| 7.0 – 8.9 | High | Urgent: within days to 1 week |
| 4.0 – 6.9 | Medium | Scheduled: within 30 days in most patching cycles |
| 0.1 – 3.9 | Low | Best effort: typically addressed in regular maintenance |
| 0.0 | None | No impact: informational only |
The Vulnerability Lifecycle: From Discovery to Patch
Vulnerabilities follow a lifecycle from initial existence through discovery, disclosure, patching, and eventually remediation across all affected systems:
Discovery
Vulnerabilities are discovered through multiple paths: security researchers conducting targeted analysis of software, automated fuzzing (providing malformed input to find crashes), static analysis tools examining source code, penetration testing, and unfortunately, by attackers who find and exploit them before defenders do. A vulnerability that is known only to the attacker who found it is called a zero-day vulnerability.
Coordinated disclosure
When security researchers find vulnerabilities, the standard practice is coordinated (or responsible) disclosure: notifying the software vendor privately before publishing details, giving the vendor time to develop and release a fix. Most organizations follow a 90-day disclosure policy: if the vendor has not released a fix within 90 days of notification, the researcher publishes details regardless (to motivate users to apply mitigations and vendors to prioritize fixes). Google’s Project Zero, which popularized the 90-day standard, has published thousands of vulnerabilities under this policy.
Full disclosure (publishing vulnerability details immediately without advance notice to the vendor) and non-disclosure (keeping vulnerability details secret indefinitely, either for operational security reasons or to sell to governments or exploit brokers) are alternative approaches, both of which have legitimate use cases in specific contexts and significant drawbacks in general practice.
The attack window
The period between when an exploit becomes available and when a patch is widely deployed represents the window of maximum risk. Even after a patch is released, many users and organizations do not apply it immediately. For widely deployed software, this window can persist for months or years: the EternalBlue exploit used in the 2017 WannaCry ransomware attack targeted a vulnerability (MS17-010) for which a patch had been available for two months, but large numbers of organizations had not patched.
Software publishers have direct influence over the length of this window through patch quality and distribution. A well-distributed, easy-to-apply patch reaches more users faster than a complex patching process. Signed software updates with automatic update mechanisms significantly reduce the time between patch availability and patch deployment.
How Vulnerabilities Relate to Code Signing
Software vulnerabilities and code signing address different security problems, but they intersect in ways relevant to every software publisher.
Vulnerability vs tamper: different threats, complementary defenses
A vulnerability is a flaw within the legitimate software. Code signing does not address vulnerabilities: a signed binary with a SQL injection vulnerability is still vulnerable. Code signing verifies that the binary is what the publisher produced, not that what the publisher produced is free of flaws.
Tamper, by contrast, is modification of the software after the publisher produced it. Code signing directly addresses tamper: a modified binary no longer matches the signature’s hash and fails verification. These are complementary defenses targeting different threat vectors.
Signing patch distributions
When a software publisher releases a security patch for a vulnerability, code signing is the mechanism that ensures the patch reaching users is the authentic fix and not a malicious substitute. On platforms where automatic updates deliver signed packages, the update infrastructure verifies signatures before applying updates. An on-path attacker who intercepts the update delivery cannot substitute a malicious package for the signed patch without breaking the signature verification.
This is a specific and important application of code signing: every security update for signed software is only as trustworthy as the signing infrastructure that protects it. Publishers who have not signed their software cannot offer this assurance for their patches.
Supply chain vulnerabilities and the limits of signing
Supply chain attacks exploit vulnerabilities in the development and build process to insert malicious code before signing. SolarWinds is the canonical example: the vulnerability was in the build environment’s security, and the exploit was inserting malicious code that was then legitimately signed. The resulting signed binary was produced by the legitimate publisher; it was the production process that was compromised.
Code signing provides no protection against supply chain vulnerabilities because the compromise occurs before signing. Supply chain security requires separate controls: build environment access management, reproducible builds, software bills of materials, and artifact provenance attestation.
The relationship between vulnerabilities and code signing is complementary rather than substitutive. Vulnerability management addresses flaws in software content. Code signing addresses the integrity of software distribution. Both are necessary for a complete publisher security posture. A publisher who signs software but doesn’t address vulnerabilities is distributing authenticated flawed software. A publisher who addresses vulnerabilities but doesn’t sign is distributing unverifiable patches.
Frequently Asked Questions
What is the difference between a vulnerability and a security bug?
The terms are often used interchangeably. A security bug is a defect in software that has security implications. A vulnerability is the same thing viewed from the attacker’s perspective: a weakness that can be exploited. Not all bugs are vulnerabilities (a sorting error is a bug but typically not a security vulnerability), and not all vulnerabilities arise from bugs in the traditional sense (configuration vulnerabilities arise from deployment choices, not code defects). In practice, the terms are nearly synonymous in security contexts.
What does CVE mean?
CVE stands for Common Vulnerabilities and Exposures. It is a standardized identification system for publicly known security vulnerabilities. Each CVE entry has a unique identifier (CVE-YEAR-NUMBER) and a description of the vulnerability. CVE identifiers are assigned by CVE Numbering Authorities (CNAs) and become the standard reference for a vulnerability across security tools, advisories, patch notes, and incident reports. The National Vulnerability Database (NVD) adds CVSS severity scores and additional technical analysis to CVE entries.
How does code signing help with software vulnerabilities?
Code signing does not prevent vulnerabilities or fix them: it addresses a different security concern: whether the software reaching users is authentic and unmodified. Code signing’s most direct vulnerability-related contribution is to security patches: when a publisher signs a security update, users and update infrastructure can verify that the patch is authentic before applying it. This prevents an attacker from substituting a malicious file for a legitimate security patch. Code signing does not address vulnerabilities in the software’s own logic or its dependencies.
Published: Dec 2022 | Last Reviewed: May 2026 | Category: Software Security / Vulnerabilities / CVE / CVSS / Risk Management
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.