Our AI strategy for preemptive security
Vulnerability management starts from a list of assets you already know about and works through the flaws in them: scan, score, prioritize, fix, verify. Attack surface management starts from the opposite assumption, that you do not have a complete list, and works outward to find internet-facing assets nobody registered, then watches them for change.
The practical difference is what each one does with an asset it has never seen. Vulnerability management has no answer, because an unknown asset is never scanned. Attack surface management treats discovery as the first job, which is why it catches shadow IT, forgotten subdomains, and cloud services stood up outside the normal process.
Most security teams run both. ASM decides what belongs in scope; vulnerability management decides what to do about what is in scope.
Attack surface management and vulnerability management are two cybersecurity approaches that share similar goals in strengthening your security posture and reducing risks in your environment.
But this convergence around similar goals often results in conflating the two approaches, which is an important mistake to avoid when you’re in the market for a new cybersecurity solution that assists with their implementation.
Read on to get some clarity on attack surface management vs vulnerability management to help you better discern between the two and choose what’s right for your business.
Attack surface management combines asset discovery, classification, and monitoring capabilities to get continual visibility into your organization’s entire attack surface. This attack surface encompasses all the potential points of unauthorized access to your systems. All it takes is one vulnerable point in your attack surface going unnoticed and unprotected to provide an entry point for a malicious actor to potentially extract data or install malware.
Today’s IT environments are far more dynamic than the relatively static environments of a decade or two ago. Containers, cloud infrastructure, and SaaS applications get provisioned often without strict adherence to security policies, which results in shadow IT assets. Distributed workforces connect to networks or access digital assets in the cloud remotely at intermittent times. The crux of the matter is that you probably have an expanding attack surface in which it is difficult to maintain visibility over and reduce risk exposure; attack surface management solves these issues.
Being able to discover all internet-facing digital assets and get a complete picture of your evolving attack surface provides invaluable insight on its own by finding assets that you were unaware of. But the additional aspects of attack surface management are just as important. In particular, effective attack surface monitoring notifies you about vulnerable assets, misconfigurations, and changes to your IT environment so that you can proactively remediate faster than hackers can get inside.
It’s important to understand that an attack surface includes physical points of access in addition to digital. Your digital attack surface typically includes all external-facing, Internet-exposed assets including ports, email servers, API keys, web applications, public cloud services, IoT devices, SSL certificates, VPNs, and even web domains. Your physical attack surface could be thought of as all potential points of unauthorized entry into systems, and it spans physical access to workstations, passwords written down on paper, not using swipe cards to block access to office premises, and more.
You could also alternatively break down digital and physical into external and internal attack surfaces. Your physical attack surface is far easier to get visibility into and secure, is much less exposed to attack, and doesn’t change anywhere near as often as your digital or external attack surface.
It’s for this reason that attack surface management solutions tend to concentrate on your external attack surface. The remainder of this article will concentrate on external attack surface management, although most concepts will apply to your physical attack surface too.
A vulnerability is a weakness or defect in a network, device, or application that, if exploited, could jeopardize the confidentiality and integrity of the data it holds. If exploited, it could allow an attacker to gain unauthorized access, elevate privileges, or deny service to legitimate users. An exploit is a piece of software or a program used to take advantage of a weakness.
Bugcrowd’s Founder, Casey Ellis, has a saying to break down these definitions that became so popular, we even put it on a t-shirt!
threat actor = someone who wants to punch you in the face threat = the punch being thrown vulnerability = your inability to defend against the punch risk = the likelihood of getting punched in the face — cje (not @ vegas) (@caseyjohnellis) April 19, 2021
threat actor = someone who wants to punch you in the face threat = the punch being thrown vulnerability = your inability to defend against the punch risk = the likelihood of getting punched in the face
— cje (not @ vegas) (@caseyjohnellis) April 19, 2021
A handful of vulnerabilities from the early 2020s reshaped how organizations think about exposure, and several are still being exploited against unpatched systems today. They remain the clearest illustrations of why an unknown or unpatched asset is such a liability:
Log4Shell/Log4j (CVE-2021-44228)
Spring4Shell/Springshell (CVE-2022-22965)
BIG-IP iControl REST RCE (CVE-2022-1388)
Follina MSDT Bug (CVE-2022-30190)
Google Chrome Use After Free in Animation (CVE-2022-0609)
Zimbra RCE (CVE-2022-27925 and CVE-2022-41352)
ProxyNotShell (CVE-2022-41040 and CVE-2022-41082) in Exchange
Atlassian Confluence Vulnerability (CVE-2022-26134)
ZyXEL Vulnerability (CVE-2022-30525)
To help combat and improve security programs, the majority of discovered vulnerabilities are listed in the Common Vulnerabilities and Exposures (CVE) List and posted on the National Vulnerability Database (NVD).
Vulnerability management is a structured process for identifying, assessing, prioritizing, and resolving security vulnerabilities. The point here isn’t to just discover critical vulnerabilities that pose grave security concerns (although that’s clearly important). Vulnerability management also helps you get a better idea about all kinds of weaknesses commonly found in your environment and how to minimize them (such as by improving your patch management processes).
To bring the definition one step back, what exactly is a vulnerability? It’s a weakness in a system, process, or control that a threat actor could potentially exploit to conduct a cyber attack. The threat actor could be someone external to the organization or an insider threat.
A somewhat myopic focus on software flaws in web applications or unpatched operating systems leads many people to conclude that all they need to identify and manage their vulnerabilities are basic vulnerability scanning tools that search for known coding flaws, open ports, or outdated software/firmware in their environments. While this is a good start in vulnerability management, it probably won’t reveal other vulnerabilities, such as misconfigured cloud services or so-called zero-day vulnerabilities that haven’t been published in any database.
Vulnerability discovery should entail more advanced capabilities, such as searching for misconfigurations caused by human mistakes, services unintentionally exposed to attackers, and even zero-day flaws like the December 2021 Apache Log4j vulnerability. There’s even an argument that if you want comprehensive vulnerability management, the identification of vulnerabilities should incorporate results from both vulnerability scanning and penetration testing.
In an attacker’s world, coming up with a working exploit for a vulnerability can allow them to run malicious code, propagate computer worms or other malware, and even steal sensitive data assets. More stringent regulatory requirements pertaining to data privacy and an increasingly dangerous threat landscape are creating greater pressure on organizations to consistently manage the vulnerabilities in their IT environment and understand the risks they pose.
A final brief point of note about vulnerability management is that vulnerabilities can also be introduced into your environment by third parties. For example, a subcontractor with access to your systems might practice poor password management or otherwise lack the robust security standards you expect. Or threat actors might set their sights on these third parties with complex hacks in the knowledge that a single third party could provide access to systems and data at many organizations (see the Accellion and Solarwinds breaches as cases in point). It’s for this reason that a vulnerability management process should also include detecting vulnerabilities introduced by third parties.
With these explanations in mind, let’s now move on to explore the main differences between attack surface management and vulnerability management under a few headings.
The first key difference is notable in the scope of what these two processes cover in terms of security risks. Take a hypothetical example scenario in which you find a vulnerability in an exposed web application. The scope of vulnerability management covers everything from finding these kinds of vulnerabilities to remediating them.
But attack surface management gives your security teams a more holistic view of things by going beyond code-based weaknesses to cover other possible entry points across infrastructure, devices, apps, and data. Furthermore, attack surface management accounts for the interconnectedness of everything. From an attacker’s perspective, that same vulnerability in a web application might provide access to connected IT assets, eventually leading to achieving their objectives.
The initial step of detection in vulnerability management and discovery in attack surface management differ considerably in what happens across both approaches. For vulnerability management, detection efforts require the use of vulnerability scanners to find known vulnerabilities and pen testing results for harder-to-find vulnerabilities.
In attack surface management, specialized software needs to find and map all your digital assets that could be points of unauthorized intrusion into your environment (e.g. GitHub repositories, IoT devices, and IP addresses). Attack surface discovery needs to be complete and account for the dependencies and connections between different digital assets.
Part of the vulnerability assessment stage involves classifying vulnerabilities. This sounds equivalent (at least on the face of things) to the classification stage in attack surface management. However, attack surface management goes more granular with its classification.
Vulnerabilities typically get classified according to types (e.g. firmware, software) or root causes (e.g. a vulnerable open source library). In attack surface management, classification involves a granular inventory that labels assets according to several different properties, such as technical details, business importance, owners, and compliance requirements.
Without this effort, your security or admin teams spend valuable time remediating vulnerabilities that present low risks or stand little chance of being exploited, while resource constraints leave more critical vulnerabilities unfixed.
In a similar vein, attack surface management needs to have a risk scoring (prioritization) step that reflects the fluctuating risks posed by different digital assets in your environment. A large enterprise might have tens of thousands of digital assets making up its attack surface. No matter a company’s resources, managing the attack surface calls for prioritizing assets based on the risks they pose.
Where the risk scoring starts to differ is that vulnerabilities are often scored based on their severity according to a standard, such as the Common Vulnerability Scoring System (CVSS). With your attack surface assets, you can factor CVSS into the equation, but other factors should be included, such as asset discoverability, business purpose, and potential for damage if the asset is compromised.
Vulnerability management is not an inherently continuous process. At organizations lacking cybersecurity maturity, you’ll often find a scattergun approach in which vulnerabilities are managed on an ad hoc basis. This is even though the Center for Internet Security specifically recommends continuous vulnerability management as a Critical Security Control.
In contrast, continuous monitoring is a baseline capability in a modern ASM platform rather than a feature: assets are re-checked for change on an ongoing schedule, and new exposures surface between scan cycles rather than at the next one. That matters because the environment moves faster than the review cadence. A subdomain pointed at a decommissioned service, an expired certificate, or a storage bucket opened for a migration and never closed will all appear and disappear inside the window a quarterly assessment would miss.
Anything that only performs point-in-time asset discovery is measuring a version of your attack surface that no longer exists by the time the report is read.
A third term now shows up in the same conversation: exposure management, often written as continuous threat exposure management. It is worth knowing where it sits, because vendors use all three words loosely.
If vulnerability management asks what is wrong with this asset, and attack surface management asks what assets we actually have, then exposure management asks which of these an attacker could realistically chain together to reach something that matters. It layers attack path reasoning and threat intelligence on top of the asset inventory, so a medium-severity flaw on an exposed, internet-facing host outranks a critical one buried behind three controls.
None of the three replaces the others. Exposure management depends on the asset inventory that ASM builds and the findings that vulnerability management produces. Treat it as the prioritization layer rather than a separate program, and judge any tool that claims the label by whether it can show you the path, not just the score.
Neither is better, but one is usually more urgent, and which one depends on a question you can answer today: can you state how many internet-facing assets your organization owns, and are you confident that number is right?
If you cannot, attack surface management is the more urgent investment. Prioritization logic applied to an incomplete inventory produces confident-looking reports about the wrong things, and the assets missing from the list are disproportionately the ones nobody is patching.
If your inventory is reliable and the backlog is the problem, vulnerability management is where the return is. The constraint there is not visibility but throughput: deciding what gets fixed first, and what gets a compensating control while it waits.
Run for long enough, the two converge. ASM keeps the inventory honest as the environment changes, and vulnerability management keeps the findings moving.
Is attack surface management just vulnerability management with a new name?
No. They overlap on scanning, but they start in different places. Vulnerability management works from a known asset list; attack surface management assumes the list is incomplete and treats discovery as step one. A program that only scans what is already in the CMDB is doing vulnerability management, whatever it is called.
Do you need both ASM and vulnerability management?
In most environments, yes. ASM without vulnerability management gives you an accurate inventory and no remediation path. Vulnerability management without ASM gives you a disciplined process pointed at an incomplete list. The gap between the two is where unregistered internet-facing assets sit, which is the category attackers reach first.
Which one should you implement first?
Start with discovery if you cannot confidently state how many internet-facing assets you own. There is little value in tuning prioritization over an inventory you know is missing entries. If your inventory is genuinely reliable, start with vulnerability management and add ASM as the environment grows more distributed.
Does ASM cover internal assets?
Most commercial ASM tooling concentrates on the external attack surface, because that is the part an attacker can enumerate without already being inside. The concepts apply internally, but internal coverage usually comes from asset management and vulnerability scanning rather than from ASM tooling.
In summary, there are some important differences worth understanding in attack surface management vs vulnerability management. The two also share some similarities, and it’s probably fair to say that ongoing vulnerability management is a subset of attack surface management.
Bugcrowd can help protect your external attack surface with an innovative platform that provides automated asset discovery in minutes across Internet-facing and cloud environments. In recognition of the fact that vulnerabilities emerge constantly, our platform comes with vulnerability discovery to continuously monitor for infrastructure and application-level security weaknesses in external assets.