Why context is king in Attack Surface Management (ASM): Key insights from my conversations with security leaders

When I launched this research, my goal was to understand the current perception of security practitioners regarding Attack Surface Management (ASM) solutions. Unlike in my previous article, "What is wrong with the current state of DAST?" I didn't start with an overall negative perception from the security practitioners. I was just generally curious and asked quite open-ended questions to see if anyone even had strong opinions on ASM (some didn’t!).

One key takeaway from the DAST research was that its success depends heavily on the specific environment being tested. Interestingly, the same theme kept popping up in the ASM conversations: while there are plenty of ASM tools available, choosing the right one really depends on the unique context of your organization. In this article, I’ll share some of the key feedback I gathered and explain why, when it comes to managing your attack surface, context truly is king.

The challenge of tool selection in ASM

The number and types of Attack Surface Management (ASM) tools expand every year, from EASM to ISAM, CAASM, and OSASM.

On the vendor side, you have giants like Palo Alto, Microsoft Defender, and Tenable, but also smaller players like Intruder or Detectify (EASM) and now Escape (releasing next week) or you also have frameworks for external assets like OWASP Amass. Some organizations even use a combination of different types of tools...

Basically, organizations are faced with a difficult decision: with so many options, how do we determine which tools best suit our needs? We have this cloud environment (fill the gap for Azure, GCP, AWS..), which tools should we use to manage our attack surface effectively? And which tools will align with our organization’s risk appetite? Should ASM tools be considered our "basic security requirements"?

With so many options available, it's not an easy feat. And, with several months (even up to a year) that it takes to plug a new security tool into your ecosystem, you don't want to miss the mark or then look for yet another change /complementary software. As one Deputy CISO of a mid-market software development company noted:

"I do have a read list of all external assets. Of course, it's dynamic, changes every day. But at least if I go in and dump my asset list, I can say that's 98%, maybe 96%, which is a kind of respectful coverage, let's put it that way. And then if I need to import it into a new tool.. But it took us nine months to get here... "- Deputy CISO, mid-market Software Development company

So, before implementing/replacing any ASM tool, security practitioners must understand how it fits into their specific organization's needs and how long it will take to fully implement.

A recurring theme that emerged from my conversations with security leaders was the sheer number of ASM tools that overlap in functionality, yet each tool might offer unique results. One product security leader put it simply:

"There are at least 4 different sources that can find valid dangling subdomains, but they all report different things at different times. That means that if we only had one of them, then we would likely miss a lot!" - Head of Product Security, a large group of marketplaces

His comment highlights an important challenge: multiple tools can serve a similar purpose, but the results are not always the same because they were likely designed for different environments. As another senior security leader shared:

"In my previous organization, some tools tend to really struggle to understand our infrastructure since we worked with old medical devices" - Sr. Director, Application and Product Security at a large entertainement provider

It's something we mention often at Escape, too, to be honest. We know our product is best for engineering-driven organizations that often scale rapidly and for whom we're building. Their stacks (and requirements) are very different from those of large corporations that can take time to deploy new features or might have a lot of uncommon legacy systems.

That said, while having a variety of tools may ensure better coverage and reassurance, it can also introduce complexity and anxiety that one tool will never find everything.

"Having overlapping "controls" can be a good thing, especially when you have no guarantee that any of them will always find all the things" - Head of Product Security, a large group of marketplaces

This redundancy ensures that security teams aren’t relying on just one tool. However, it also means organizations must strike the right balance between having too many overlapping tools and maintaining simplicity.

Context is key: The role of organizational environment

As mentioned before, what came up in the conversations is that the most significant factor in selecting the right ASM tool is an organization's unique environment.

The size of the company, its maturity level in terms of security practices, the cloud infrastructure they use, their integrations, the number of legacy assets, and their industry all influence which tools will work best for them.

One of the most important takeaways from my discussions with security leaders was that there is no universal tool that fits all contexts.

"In general, I think attack surface management as a concept will always exist in different spheres. For example: dangling subdomains will always be something to check for in cloud security platforms, and discovering unknown IP/Domains/SaaS your company owns will be a challenge for large corporations." - Head of Product Security, a large group of marketplaces

For large organizations, the complexity of their environments often requires tools that can handle a much larger scale and that integrate deeply with their existing systems. As one security leader put it:

" My whole idea is always - context. What I hate about it is that vendors love to have shiny videos saying "for a global multinational". Yes, I get it. But on the other side, if it's a smaller company or a company that is still starting, I think you need a bit of a more technical sizzle and a different approach. When the team grows and the maturity of processes happens, the full solution also becomes a bit more mature." — Deputy CISO, mid-market Software Development company

"If you are in a state kind of security, what matters is slightly different than when you’re in corporate… what matters in a government or intelligence context is vastly different than in a corporate environment."

This is an important distinction. What works for a multinational corporation, with hundreds or thousands of assets across multiple cloud platforms, will not be the same as what a small startup needs. In smaller organizations, security teams often require tools that are simpler, with more immediate feedback loops, as opposed to the large-scale, complex solutions used in bigger corporations.

Another key point is that it's not just about the size of the organization, but the type of application you're securing.

For API-heavy organizations with which I have most experience, security needs go beyond just managing traditional assets. In these environments, features like monitoring and alerting for exposed Swagger files or other sensitive API documentation become critical parts of their ASM requirements. These are the types of assets that need to be monitored by ASM tools, because for such organizations, APIs are a key part of their attack surface.

"I had an event recently where a developer accidentally exposed a Swagger file to the entire world that they totally did not intend to. That’s exactly the type of API security I would expect an ASM tool to notify us about."
– Application Security Manager at a large AdTech org

Prioritization and visualization: Managing complexity

Once you’ve selected the right ASM tools, managing the massive amounts of data they produce or collecting this data across multiple tools is yet another challenge.

Security leaders I talked with stressed the importance of prioritization and visualization when managing attack surfaces, especially in complex cloud environments. Tools that provide clear dashboards and actionable insights allow security teams to make better decisions about which vulnerabilities to address first.

"Prioritization and dashboards must help understand why something has disappeared over time and suggest if something is wrong, whether it’s a vulnerability or exposed asset." — Application Security Architect at Financial Services Company & OWASP Chapter Leader

Another security leader also shared a useful point about prioritization and how it's important to tie it to a context:

"It's not just about high CVSS/CVE scores, but really looking into how your application is built. The environmental score in your particular situation would really matter for us, then a vulnerability might drop two points."
– Sr. Director, Application and Product Security at a large entertainement provider

In large organizations, the number of vulnerabilities and exposed assets can be overwhelming. Without a way to prioritize which issues to address first, it can be difficult to stay on top of threats.

Visualization, too, plays an important role in making sense of this data. Security leaders expressed how much they appreciated having a visual representation of their attack surface, which simplifies decision-making.

One security professional put it succinctly:

"I would love something to help me resolve things. That's why one of the most important ASM features for me would be probably visualization. It’s always nice to visualize the data. Some people like a JSON output, but I love visualizing things. It makes it easier to act on. Especially, if you can have the ability to create different tagging groups and access levels. This way, I could give certain subsidiaries access to specific portions of the ASM, allowing them to manage operational tasks." — Deputy CISO, mid-market Software Development company

Whether through charts, graphs, or lists with tags and filters, visualization tools help translate raw security data into something actionable.

Potential for innovations: AI-powered ASM and ASM x DAST combo

In my conversations with security leaders, I’ve also been curious about what innovations might be on the horizon for ASM, especially when it comes to how AI can improve current tools. AI has a huge potential to enhance ASM’s capabilities, especially in areas like understanding an organization’s specific context, improving traceability, and more effectively identifying and remediating vulnerabilities tied to each asset:

"Traceability can impact the exploitability factor, and AI can help with that."
– Sr. Director, Application and Product Security at a large entertainement provider

This really got me thinking about how AI can help ASM tools. Perhaps by reducing the need to purchase multiple tools at once, starting to build asset inventory from the code, and combining EASM and IASM more efficiently. And simply not just map the attack surface, but help to understand it better.

Another exciting area we talked about with people with whom I got on the call is combining ASM with DAST (or automated pentesting). While ASM gives you a broad overview of your attack surface, DAST can dig deeper into the specifics, like application-level vulnerabilities.

Imagine a solution that doesn’t just give you an overview of your assets, but also provides proof of how these assets can be exploited by attackers and helps you provide remediations to developers within your specific context?

General sentiments

If there’s one takeaway I have from all my research and conversations, it’s this: ASM can deliver significant value if you choose it well for your specific context.

There is no single ASM tool that fits all organizations, and if your budget allows, you can pick multiple tools for optimal coverage. Just keep in mind that choosing the right one depends on a variety of factors, including company size, security maturity, application types, and infrastructure.

More than that, I do believe that it's never about just getting visibility or having a "single pane of glass". The potential for innovation in combining ASM with DAST could lead to not only just to covering more shadow assets but also defining what can be actually exploited, how attackers can actually access it from outside, and then helping you to prioirize what needs to be fixed first in your environment and who owns the fixes :)