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 and internal.
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.
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.
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.
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.
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.
The Exploit Window Nobody Talks About
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.
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.
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.
What matters is that, much like the regular exploit window, this one is also shrinking.
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.
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 and, lacking the appropriate guardrails, they double as agents of chaos.
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.
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.
1. Structural Discovery
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.
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.
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.
Keeping that graph current requires re-deriving the relationships between the nodes, over and over.
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.
Which brings us to the second pillar, which is how often you redraw that picture.
2. Rapid Run Frequency
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.
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. 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.
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.
Case in point, daily scanning has become the baseline expectation, and the survey data backs us up. In the 2025 SANS ASM Survey, 59% of respondents named daily as their preferred scan frequency, compared with 25% for weekly and 10% for on-demand.
3. Business and Stack Context
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.
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.
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.
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:
- Is the port open?
- Is authentication required?
- Does this version have known vulnerabilities?
And so on. Some of those answers will raise further red flags, and where it goes wrong next is in mistaking a theoretical issue for an exploitable one.
A classic example is a new application coming online carrying a SQL injection CVE that applies to the version it happens to be running. The easy move here would be to create an alert. The smart play, however, is to check whether a WAF sits in front of that application. A WAF that catches the injection attempt drops the alert far below where it first ranked.
In other words, what it all boils down to is context, and the value of that context climbs with your cadence. Run discovery daily without it and you are just drowning faster.
4. Change-aware Prioritization
Some of that context only comes from testing, which is not a capability most ASM platforms offer, and even fewer can execute it at any meaningful scale and rapid cadence.
That leaves two things you need to get right. First, the cadence of security testing has to match what you assumed you need. Next, to test the right assets at full depth, that testing needs to be pointed by a prioritization mechanism that is change aware.
By change aware here I mean a ranking that recalculates every time your environment moves, driven by signals like:
- What are the asset’s technical attributes?
- How attractive and discoverable is it from the outside?
- What threats is your industry facing right now?
- How valuable is this asset to the business?
To demonstrate how these and other signals drive change-aware prioritization, here is a widget that walks through a few scenarios:
🕹️ Simulator: Changes and Prioritization
Re-scored each cycle
This is an oversimplification of course, but it does a good job of showing the prioritization decisions our own ASM makes in response to external and internal shifts. It is also the foundational logic behind our new Target Graph™, now used for the more complex task of delegating objectives to AI pentesting agents.
Notice that the widget shows the reasoning and not just the score. That is the evolution of change-aware prioritization, and what AI opened up here, because change is dynamic and unpredictable, and interpreting it flexibly holds up where rigid scoring does not.
Context is the mechanism that builds that trust, and it also moves a team off the handful of priority assets they picked themselves. What they get instead is an awareness of the underlying changes happening across the perimeter, and a better basis for allocating resources than any list drawn up in advance.
5. Confirmed RemediationÂ
Once risk is validated, the issue has to reach the right owner with enough evidence attached for them to act on it. But this is not where the job ends, since the one final change you need to observe is the moment that fix lands.
The reason we watch for it is that roughly 25% of issues marked resolved still leave the underlying risk wide open. That is 1 in 4 tickets telling you a story that is not true.
The fix may have been incomplete, applied in the wrong environment (staging instead of production), or closed out because the owner could not reproduce the issue on their own system.
Of course, the reason doesn’t really matter. What matters is that a closed ticket with an unresolved issue creates a particularly dangerous gap, a ticking timebomb wrapped in a false sense of security.
To avoid those, closing the loop means re-validating the issue and raising the red flag if it can still be reproduced.
From a change management perspective, this means covering the whole process end to end, which starts with spotting the change and ends only once you have confirmed the fix actually held.
TLDR; Build a Program Around Change Management
If you stuck with me this far, or just skipped down to this section, here are the four questions worth asking about your current ASM solution, or your next one.
- What kinds of change do you see?
- How quickly do you see a change?
- What tells you which changes matter?
- What decides where deeper testing goes?
- How do you know a fix actually held?
And let me close with some shameless self-promotion. At CyCognito we run that whole loop continuously (discovery, assessment, validation, prioritization and remediation) at a daily cadence, and at whatever scale you need it.
We work with some of the world’s largest organizations, many of them holding millions of assets, keeping up with change in the most complex environments there are. If you’d like to see it run against your own surface, book a tech demo.
