{"id":2850,"date":"2026-08-30T02:46:54","date_gmt":"2026-08-30T09:46:54","guid":{"rendered":"https:\/\/www.cycognito.com\/blog\/?p=2850"},"modified":"2026-08-30T03:03:07","modified_gmt":"2026-08-30T10:03:07","slug":"asm-has-a-silent-c-and-it-stands-for-change-management","status":"publish","type":"post","link":"https:\/\/www.cycognito.com\/blog\/asm-has-a-silent-c-and-it-stands-for-change-management\/","title":{"rendered":"ASM Has a Silent C, and It Stands for Change Management"},"content":{"rendered":"\n

If you run a security team, a large part of the job is responding to change. Something in the environment moves, and you have to work out whether risk moved with it, and how quickly you need to act. Those changes arrive from two different directions, external<\/strong> and internal<\/strong>.<\/p>\n\n\n\n

Of course, we’re all familiar with the external ones. A new CVE drops, a proof of concept goes public, a ransomware group starts naming your sector.<\/p>\n\n\n\n

The internal ones start inside your own organization. Someone connects an MCP server to critical data, a product team ships an API change to a public endpoint, a storage bucket loses its access policy.<\/p>\n\n\n\n

Attack surface management (ASM) has always tried to cover both ends, but usually in the service of vulnerability management. Not really the best way to look at it, but it is how many saw this category so far.<\/p>\n\n\n\n

Thankfully, things are starting to change, and teams are beginning to see ASM in its fuller role: not only protection against the next vulnerability, but also a governance tool for tracking asset proliferation. A sprawl that now gets sprawlier by the day, thanks to AI.<\/p>\n\n\n\n

In this post I want to explain why I think that shift is happening. And what an ASM program needs to be, to keep pace.<\/p>\n\n\n\n

The Exploit Window Nobody Talks About<\/h2>\n\n\n\n

Let’s start with the exploit window we all know about: the time between a vulnerability being disclosed and it being exploited in the wild. The industry tracks that window obsessively, treating it as a benchmark for how attackers grow more sophisticated, and every year brings new reports on how much shorter it has become.<\/p>\n\n\n\n

The other exploit window, which doesn’t get enough attention, is the one running from the moment a misconfiguration goes live to the moment an attacker finds it and goes in. <\/p>\n\n\n\n

The misconfiguration here can take many shapes, but the most common scenarios fall into one of two buckets: a new asset appearing, or an existing one becoming less secure. The exact issue is really not important for the purpose of this discussion. <\/p>\n\n\n\n

What matters is that, much like the regular exploit window, this one is also shrinking.<\/p>\n\n\n\n

On top of that, these gaps are opening more often, simply because the number of people who can deploy to production has gone through the roof. Behind that is a new kind of self-service infrastructure, with AI as the catalyst.<\/p>\n\n\n\n

A few years ago, the only ones with a key to production were the development teams. Today everyone in the org can deploy an MCP server just by asking AI to do it, without so much as a pretty please. This turns everyone into an agent of change<\/strong> and, lacking the appropriate guardrails, they double as agents of chaos<\/strong>.<\/p>\n\n\n\n

Most companies have AI adoption in this year’s goals, so the people spinning up these tools are following the new North Star. Security is caught in the middle, unwilling to block what the business just prioritized, and accountable for the risk anyway. <\/p>\n\n\n\n

All of this chaos is adding up under the surface, building toward more tech debt than organizations are prepared to deal with. Not even close. Reining it in takes an ASM program that stands on five pillars, and the first of those is knowing what you are running against in the first place.<\/p>\n\n\n\n

1. Structural Discovery<\/strong><\/h3>\n\n\n\n

An attack surface is often presented as a list of assets, and a list is a comfortable thing to look at. But your attack surface isn’t a list. It’s a graph, with dependencies running between the nodes.<\/p>\n\n\n\n

\"\"
Your attack surface is a graph.\u00a0<\/em><\/figcaption><\/figure>\n\n\n\n

Discovery starts at the organization, finds the subsidiaries, finds the domains those subsidiaries own, and works its way down to the assets sitting behind them.<\/p>\n\n\n\n

Every level of that path is a place where change can enter. A certificate turns up and reveals four more systems using it. An application starts resolving to new infrastructure and takes its dependencies along with it. At the far end of the scale a company gets acquired, and your attack surface grows significantly.<\/p>\n\n\n\n

Keeping that graph current requires re-deriving the relationships between the nodes, over and over.<\/p>\n\n\n\n

Doing that at the scale of environments running into millions of assets, and keeping the result steady enough that the picture doesn’t shift under your feet from one day to the next, is a serious engineering undertaking. <\/p>\n\n\n\n

Which brings us to the second pillar, which is how often you redraw that picture.<\/p>\n\n\n\n

2. Rapid Run Frequency<\/strong><\/h3>\n\n\n\n

To be responsive to changes, the first no-brainer requirement is seeing the change as close as possible to the time in which it occurs. Which means discovery has to run on a rapid cycle. The only question worth arguing about is how rapid that cycle should be, and the answer here largely depends on how often you think changes in your environment occur.<\/p>\n\n\n\n

In our own analysis of the surfaces we monitor, the size of an organization’s attack surface can fluctuate by as much as 10% in a single month<\/a>. Note this is the first key decision to take, since everything downstream inherits that number, which dictates how quickly assets are not only discovered, but also validated, tested and fixed.<\/p>\n\n\n\n

The trap to avoid here is to stop at “continuous”, which became the marketing message that nearly all ASM vendors adopted, us included. The job you need to do here is to find out what “continuous” means in practice. If you dig down you will find that for some platforms it means periodic runs, spaced weeks or more apart and scoped to a portion of the surface. Technically speaking, those partial, spread-out runs still carry the “continuous” label, but they probably fall short of what most security teams actually think they need.<\/p>\n\n\n\n

Case in point, daily scanning has become the baseline expectation, and the survey data backs us up. In the 2025 SANS ASM Survey<\/a>, 59% of respondents named daily as their preferred scan frequency, compared with 25% for weekly and 10% for on-demand.<\/p>\n\n\n\n

\"\"
Preferred scan frequency, 2025 SANS ASM Survey.\u00a0<\/em><\/figcaption><\/figure>\n\n\n\n

3. Business and Stack Context<\/strong><\/h3>\n\n\n\n

Once ASM hands you a list of what you have and what has moved, its next task should be to help you work out which of those changes carry real risk.<\/p>\n\n\n\n

The good news is that in most environments they turn out to be a small fraction of the total. The problem is that you need a platform that can filter through the noise, and dynamic IPs are the obvious example, since CDNs, load balancers and IaaS\/PaaS providers rotate them constantly<\/a>.<\/p>\n\n\n\n

If your platform doesn’t know to recognize that change for what it is, this week’s alerts can end up being last week’s applications wearing nothing but a fresh set of addresses. What’s worse, the noise they make can bury the findings that do matter, and over time it leaves teams numb to the alerts in general.<\/p>\n\n\n\n

So separating infrastructure churn from the change security needs to track is where this pillar starts. What follows should be a series of deeper questions that help provide additional context:<\/p>\n\n\n\n