Traditional vulnerability management is great at telling you what’s broken–just ask the team managing your neverending backlog of vulnerability findings. But it’s not great at incorporating context on your specific threat landscape and attack surfaces. Risk-based vulnerability management is trying to shift this dynamic. Unfortunately there’s a long way to go for these approaches to give you a clear understanding of key risks.
That’s the key difference between vulnerability vs exposure management. The latter is the broader, more strategic concept. Exposure management incorporates the missing context around how a vulnerability could realistically be exploited based on your actual attack surface, and whether you have other, more important gaps to fix.
In this post, we’ll unpack how these two approaches differ, how concepts like patching, exploitability and compensating controls come into play, and why modern security teams must go beyond just scanning for CVEs to truly reduce risk.
Vulnerability vs Exposure Management: Key Differences
So what’s the difference between a vulnerability and an exposure anyway? The answer should be straightforward. Unfortunately, the hype around CTEM has led VM vendors to position their products toward exposure management without materially expanding functionality. Also, the program for reporting publicly known vulnerabilities is called CVE, or “common vulnerabilities and exposures,” muddying the waters more.
A vulnerability is a specific software, hardware, or firmware security flaw. It could be a code-level weakness, a fundamental configuration error, a design issue, or anything else specifically related to the affected system that attackers can exploit to perform malicious activity.
An exposure is a broader concept than vulnerabilities. It is any condition that increases the likelihood of adversaries successfully attacking an organization, even if the attack doesn’t exploit a vulnerability. In other words, all vulnerabilities are exposures, but not all exposures are vulnerabilities.
Beyond Vulnerabilities: Other Types of Exposures
So if exposures go beyond vulnerabilities, what other gaps are relevant? Let’s review the key categories.
Prevention Control Gaps
Exposures include gaps in prevention controls that leave an organization susceptible to attacks. Examples of these kinds of exposures are numerous and span a range of security domains. They could include cloud misconfigurations that expose sensitive data to the public internet; lapses in hardening processes, like failing to disable unnecessary services and ports, which can weaken security posture over time as systems scale and settings drift from their initially secure defaults; or lax access controls (e.g. weak passwords, the absence of multi-factor authentication) that make it easier for attackers to gain unauthorized access to systems and data.
Detection Control Gaps
Another type of exposure is detection control gaps that leave the security team unaware of active threats inside their environment. A key example is the lack of active SIEM rules for attacker techniques relevant to the organization’s threat landscape, leading to blind spots in threat coverage. Another example is broken rules where SIEM detections were created but don’t fire alerts when they should due to issues like parsing errors or log schema drift. This category also includes noisy rules that create false positives so often that analysts start ignoring corresponding alerts. It’s like the security version of the boy who cried wolf (or, the “SIEM rule that cried malware”). Analysts see irrelevant alerts so frequently that they miss true positives and fail to respond to an active threat.
Supply Chain and Third Party Risks
Working with partners, vendors, and other third parties as part of extended business operations introduces risks. It’s difficult enough to understand your own security posture and risk levels. It’s nearly impossible to know all the risks associated with third parties. You don’t have direct control over their security processes. The 2013 Target breach is the most infamous example. Adversaries didn’t attack Target directly, instead targeting (pun intended) an HVAC vendor with phishing attacks that enabled indirect access to Target’s contract management and billing platforms.
Where Traditional Vulnerability Management Comes Up Short
When reviewing vulnerability vs exposure management and the subcategories, vulnerabilities still tend to get the most attention. Sprawling IT infrastructure has drastically increased the attack surfaces available to adversaries, leading to corresponding growth in the sheer volume of reported vulnerabilities. This results in massive backlogs of findings in VM tools.
IT and security teams can’t possibly keep up. Gartner puts it bluntly in a research note on patching published earlier this year: “the cold hard reality is that no one is outpatching threat actors at scale in any size organization, geography, or industry vertical.” And even if they could, many teams are hesitant (or outright resistant) to patch. Why? Because they’ve been burned when patches don’t work as intended, causing outages, lost revenue, and reputational damage.
The Missing Context: Observed Attacks, Exploitability, and Compensating Controls
VM tools also generally fail to incorporate details on observed attacker activity tied to CVEs. The chart below (from the same Gartner research note) shows that relatively few reported vulnerabilities are actually exploited. Of the nearly 25,000 reported vulnerabilities in 2023, only about 10% were actually exploited in 2023. That percentage ranges from roughly 5-10% over the course of the sample data.
The data highlights that adversaries focus on a small subset of vulnerabilities in observed attacks. Meanwhile, even fewer vulnerabilities are actually exploitable in context. Configuration settings, network topology, and other unique factors surrounding an organization’s attack surfaces can prevent attackers from realistically accessing the system related to the vulnerability. So just because a vulnerability is in an attacker’s crosshairs doesn’t mean they can actually do anything to exploit it.
The story doesn’t stop there. Organizations often have compensating controls elsewhere in their IT and security stack to mitigate risks. These alternative security measures effectively cover risks associated with exploitable vulnerabilities, deprioritizing patch workflows (or in some cases, making them unnecessary or irrelevant).
False Positives and Findings Fatigue
These insights on exploitability and compensating controls are hidden across siloed tools and not generally represented in traditional VM approaches. The result? VM backlogs that are filled with false positives, or vulnerability findings that aren’t truly representative of the risks facing your organization.
You’ve probably heard of “alert fatigue” in the context of threat detection and response. “Findings fatigue” is its parallel for teams responsible for managing vulnerabilities and patches. In the same way that noisy alerts distract SOC analysts from actual threats, massive findings backlogs obscure the exposure risks that actually matter.
Teams need a new operating model that breaks the cycle of endlessly toiling on patches without meaningfully reducing risk. That’s where really understanding vulnerability vs exposure management is critical.
From Patch Cycles to Targeted Risk Reduction
Exposure management is the necessary evolution from these VM challenges to a more holistic strategy focused on high-impact remediation workflows. VM will remain a key component, but in support of the broader goal of eliminating exposure risk.
Exposure management reframes “when can we implement this patch?” to “is that vulnerability exploitable in our environment?” and “is that patch really a priority?” Those answers lead to more fundamental questions like “where are we actually exposed?” and “is the work we’re doing actually reducing risk?”
To make this evolution happen, organizations need to correlate real-time context on their threat landscape and the availability, status, and configuration of relevant controls. Connecting these insights across siloed tools pinpoints which assets are actually at risk of exploitation, narrowing down thousands of security findings to the handful that actually matter.
From there, organizations can prioritize and kickstart high-impact remediations that have a demonstrable impact on risk levels. And that’s exactly what we’re focused on delivering at CardinalOps.
If your team is ready to make this shift, let’s connect.