Researchers, vendors, and security pros have disclosed more than 280,000 known common vulnerabilities and exposures (CVEs). But with this impossibly long list of priorities, how can teams know what’s truly important? After all, the “patch everything” approach is unscalable, and regardless, not all CVEs pose equal risks. Lack of prioritization also erodes confidence in teams tasked with endlessly applying fixes. The CVE database is a powerful tool to help, so we’re looking at practical first steps to understanding CVEs — and how to use them in smarter ways.
What is a CVE?
A CVE is a standardized identifier for publicly disclosed cybersecurity vulnerabilities and exposures. Each CVE is assigned a unique identifier (a CVE ID), such as CVE-2024-12345, for organizations to recognize, track, and address specific vulnerabilities across systems and software. CVE records also contain links to technical details and patches, where available. Types of vulnerabilities include:
- Buffer overflows
- SQL injections
- Cross-site scripting (XSS)
- Privilege escalation
- Remote code execution (RCE)
- Denial of Service (DoS)
- Insecure authentication
- Insecure cryptography
- Command injection
- Directory traversal
- Zero-day vulnerabilities once discovered
- Supply chain vulnerabilities
The non-profit MITRE Corporation manages the CVE List along with their MITRE ATT&CK Framework, but contributions come from various sources, including MITRE researchers, tech companies, vendors, and authorized collaborators who verify and assign CVE IDs. Vendors without CNA status can report vulnerabilities directly to MITRE or use bug bounty programs to identify and disclose them.
CVEs are collaborative records stored in repositories, like the National Vulnerability Database (NVD), along with added information like common vulnerability severity scores (CVSS), impact metrics (e.g., scope, confidentiality, integrity, and availability), and patches.
Prioritize CVEs with Runtime and Container Scanning from Upwind
Upwind’s runtime-powered container scanning helps you prioritize CVEs effectively by providing real-time threat detection, contextualized analysis, and remediation insights. Understand which vulnerabilities matter most to your unique workloads and resolve them faster — up to 10X faster than traditional methods.
The Urgency of Vulnerability Management
As cybersecurity threats evolve in cloud architectures, unpatched vulnerabilities become a top concern. The vulnerabilities cataloged in the CVE list are an essential starting point for assessing risks, but the scale of unpatched vulnerabilities continues to rise, creating significant exposure for organizations.
According to one survey of cybercrime victims, unpatched vulnerabilities accounted for 60% of total reported data breaches.
Not all CVEs are equal in impact since some pose immediate threats to public-facing web applications while others create latent risks in internal cloud workloads. By looking at how common CVEs manifest across different environments, teams can begin to identify their own risks and craft smarter approaches to mitigation.
Log4Shell (CVE-2021-44228) in Distributed Cloud Applications
Log4Shell is a vulnerability in the Apache Log4j logging library that allows attackers to execute remote code. It has been particularly devastating in cloud-native environments with distributed services. In Kubernetes clusters or SaaS platforms, attackers can exploit Log4Shell to compromise containers, steal data, and pivot across services.
EternalBlue (CVE-2017-0144) in Legacy Windows Systems
EternalBlue exploits a flaw in the Server Message Block (SMB) protocol, commonly found in legacy or unsupported Windows environments, to execute remote code. This vulnerability was weaponized in the WannaCry attack, which spread ransomware across networks with unpatched Windows servers.
Shellshock (CVE-2014-6271) in Web Servers
Shellshock is a vulnerability in the Bash shell, a program that executes commands on Linux systems. It allows attackers to run unauthorized commands. Public-facing servers, such as those used to host websites, are especially at risk since attackers can use this flaw to steal sensitive information or secretly install tools that let them access the server later.
Heartbleed (CVE-2014-0160) in TLS/SSL Encrypted Environments
Heartbleed exploits a flaw in OpenSSL, an encryption toolkit for secure communications, that allows attackers to read sensitive data like private keys directly from memory. In environments that rely heavily on encrypted communications, Heartbleed can compromise user credentials or expose sensitive communications.
ProxyShell (CVE-2021-34523, -34473, -31207) in Exchange Servers
ProxyShell lets attackers bypass authentication and remotely execute code on Microsoft Exchange Servers, a common target in corporate email environments. Exploiting ProxyShell can lead to email exfiltration, ransomware deployment, and persistence within enterprise networks.
Dirty COW (CVE-2016-5195) in Virtualized Workloads
Dirty COW (Copy-On-Write) is a Linux kernel vulnerability enabling local privilege escalation, often in containerized or virtualized environments. Attackers can escalate privileges from a container or virtual machine, potentially compromising the host or neighboring systems.
The variety of environments affected by these CVEs underscores the significance of context in vulnerability management. A CVE impacting an outdated on-premises system may pose little risk to a fully cloud-native enterprise, while a cloud-centric CVE could be catastrophic for organizations operating at scale.
By understanding how specific CVEs interact with systems and workloads, teams can prioritize patches and mitigations more effectively, reducing both risk and downtime.
Prioritization Strategies for Vulnerability Management
Effectively managing vulnerabilities requires more than tracking CVEs — it also means developing a clear understanding of their potential impact on specific environments and workloads. A vulnerability that poses a critical risk to one organization may be negligible for another, depending on factors like architecture, business function, and exposure.
While CVSS provides a baseline measure of vulnerability severity on a scale from 0.0 to 10.0, it lacks the context teams need to determine how a vulnerability might impact their organization. CVSS is useful for assessing technical severity, including factors like scope and exploitability, but it doesn’t account for factors like business-critical workloads, environment exposure, or exploit activity in real time.
Here, we’re breaking down the crucial factors behind an organization’s CVE priorities. How should each factor play out in a real-world scenario?
| Factor | High Impact Example | Low Impact Example | Mitigation Priority |
| Exploitability | Actively exploited vulnerability like Log4Shell | Theoretical vulnerability with no known exploits | High priority for exploited CVEs. Monitor others |
| Environment | Vulnerable public-facing web server running Shellshock | Internal legacy server with limited access | Patch public-facing systems first |
| Business Criticality | A vulnerability affecting a production database with customer data | Development server with no sensitive information | Focus on workloads tied to core business functions |
| Operational Disruption | Vulnerability leading to ransomware on critical infrastructure (e.g., EternalBlue) | CVE in a rarely used, non-critical application | Immediate action to prevent catastrophic outcomes |
| Dependence on Third-Party Software | Open-source library vulnerability affecting multiple workloads | CVE in a standalone application with minimal dependencies | Prioritize vulnerabilities with wide-reaching impact |
Exploitability isn’t always enough to prioritize a CVE for immediate remediation. Instead, teams should identify which CVEs are actively exploited, as these pose the highest immediate risk. But while a known exploit increases urgency, it doesn’t always dictate severity. And all these factors work together to paint a more complete picture of organizational risk than exploitability alone. For example, if the vulnerability affects a non-critical system, its priority may be lower than an unexploited vulnerability on a public-facing server.
Even with a known exploit, the environment, business criticality, operational disruption, and third-party dependency provide context that helps teams focus on CVEs where the stakes are highest.
Upwind Identifies the Riskiest CVEs Better
Understanding and prioritizing CVEs is essential for minimizing risk and maintaining operational resilience in today’s complex environments. By focusing on the vulnerabilities that pose the greatest threat to your systems and workloads, teams can efficiently allocate resources, reduce downtime, and stay ahead of potential exploits. But the CVE List is primarily a static resource and prioritizing CVEs can be a laborious process.
Upwind is dynamic, designed to contextualize, automate, and operationalize vulnerability management in complex cloud-native environments. See how to take vulnerability management to the next level. Get a demo.
FAQ
What’s the difference between a CVE and a CVSS score?
A CVE (Common Vulnerabilities and Exposures) is a unique identifier for a specific cybersecurity vulnerability, providing a standardized way to reference and track it. It is a way of cataloging vulnerabilities.
A CVSS (Common Vulnerability Scoring System) score, on the other hand, measures the severity of that vulnerability so organizations can prioritize which vulnerabilities to address based on risk. This risk won’t account for the unique ways in which that vulnerability may be embedded in the code and operations of a particular organization.
What tools can I use to detect CVEs in my systems?
Apart from comprehensive CNAPP solutions like Upwind, there are open-source tools available to scan for CVEs in your environment. These tools won’t come with prioritization features like machine learning and behavioral baselines tailored to your environment.
Nevertheless, tools like OpenVAS can detect CVEs in traditional environments, though it needs significant configuration to work effectively in cloud-native architectures.
Are CVEs relevant for cloud-native environments?
Yes, CVEs are extremely relevant for cloud-native environments. That’s because vulnerabilities can exist in containers, Kubernetes clusters, serverless functions, and cloud infrastructure. Here are some examples:
- Containers: Vulnerabilities in base images (e.g., CVEs in outdated OpenSSL versions).
- Kubernetes: Exploits targeting misconfigured pods or insecure APIs.
- Cloud Infrastructure: CVEs in cloud service libraries or exposed management interfaces.
But CVEs aren’t just for the cloud. CVEs are also important in non-cloud-native environments, where they help identify vulnerabilities in traditional on-premises systems, legacy applications, and network infrastructure. For example, CVEs can highlight risks in unpatched operating systems, outdated file-sharing protocols like SMB, or enterprise applications that rely on older software versions.
What’s the role of CVEs in compliance and audit processes?
CVEs play a significant role in compliance and audit processes. They help organizations identify and mitigate known vulnerabilities to meet security standards. Many compliance frameworks require regular vulnerability assessments and remediation efforts, and referencing CVEs provides a standardized way to document risks and track progress. Overall, CVEs:
- Aid in risk Identification: They help auditors verify that vulnerabilities are being tracked and addressed.
- Help teams document remediation: They provide evidence that specific CVEs have been mitigated to meet compliance requirements (e.g., PCI DSS, HIPAA).
- Monitor their environments continuously: They allow teams to demonstrate that they adhere to ongoing vulnerability management practices as part of the organization’s larger security posture.
How do CVEs relate to zero-day vulnerabilities?
A zero-day vulnerability is a security flaw that is either unknown to the vendor or has no available fix, making it highly exploitable until disclosed and mitigated. It won’t appear in any list of CVEs. It’s particularly dangerous at this stage because security teams don’t know it exists, while attackers might.
A zero-day becomes a CVE once publicly disclosed and assigned a CVE identifier. At this point in its lifecycle, the zero-day isn’t necessarily more dangerous than other vulnerabilities. Once disclosed and assigned a CVE, a zero-day’s risk depends on factors like patch availability and exploit activity.
