Attack Surface Management (ASM): Best practices guide

Most cybersecurity teams are stretched thin; they’re asked to defend more than they can see. And it makes sense: you’re careful about hiring, while your attack surfaces expand for free. Your cloud projects proliferate, SaaS integrations never die, CI runners come and go, and developers add open-source dependency chains faster than you can track. Exponential attack-surface sprawl means no one knows for sure what production looks like once a security emergency shows up. And it feels like most breach headlines start the same way: someone, somewhere, forgot that something is accessible from prod.

Attack surface management (ASM) exists because this chaos, and the speed at which it’s growing, are facts of life for your security team. It’s your team’s job to understand every system that might be reached from the internet, including internal systems and the supply-chain components your software depends on. If you can’t see it, you can’t track it; if you can’t track it, you can’t defend it.

In the sections ahead, we break down what ASM really means, why it has become table-stakes, and how to use it to turn reactive triage into controlled, predictable risk reduction.

What is Attack Surface Management (ASM)?

Attack Surface Management (ASM) is a disciplined approach to tracking your production landscape and monitoring what an attacker could reach. It goes beyond your contact with the public internet and reaches into cloud resources, internal services, ephemeral workloads, CI systems, artifact stores, and all the dependencies you inherit from your supply chains. Your ASM and Attack Surface Reduction (ASR) work complement each other. With ASR, you work upstream to prevent security exposures from reaching production. ASM is the work you do to manage security after systems are exposed to the world.

Some teams assume that running vulnerability scanners is all it takes to manage their security surfaces. Scanners are a staple, but they’re only one of the inputs into ASM. To be effective, they should be plugged into an entire system: a continuous cycle of discovery, classification, and verification that reveals what exists, how it behaves, and where it drifts over time.

Your organization’s attack surface shifts daily. ASM provides the only reliable way to track that movement in near real-time, identify where exposures occur, and assess their significance before others do.

Why Attack Surface Management matters today

Some teams already invest in ASR, and might assume that’s sufficient. They use minimal images, tighten permissions, cut dead services, and try to shrink the surface area attackers can reach. That helps. When done well, ASR reduces both the base rate and the exponent in an exponential growth problem. No matter how well you keep growth in check with ASR, though, you’ll still be managing exponential and compounding growth for your security surface: clouds automatically spawn resources in response to load, developers introduce new dependencies, and CI systems generate fresh artifacts anytime new code is merged.

This growth is driven by valid requirements, including:

• Hybrid cloud complexity: You can strip your services down, but the cloud keeps generating new edges: regions, VPCs, functions, autoscaled nodes. Cloud products that reach a global audience automatically expand your attack surface. ASM is what catches infrastructure changes that didn’t exist last week.

• Supply-chain compromises: Upstream breaks still affect you, regardless of how well you reduce your surface exposure. Attacks on supply chains, such as Log4Shell, XZ, and dependency poisoning, all bypass “local hardening” and instantly expand risk. You’ll have to manage your dependency chain.

• Regulatory pressure: Frameworks like FedRAMP, NIST, and PCI DSS don’t care that you reduced your footprint. They expect continuous evidence that everything in scope stays visible, patched, and accounted for. Supporting their requirements means launching and maintaining additional systems for logging, monitoring, auditing, and other purposes, all of which expand your attack surface and require management.

• CVE overload: Even if you reduce your attack surface by securing and hardening your components, you inherit alerts from scanners, registries, and dependencies. Without ASM, scanner noise can bury the small fraction of issues that matter most to you.

• Security and engineering team friction: In the best of circumstances, your engineering teams are doing an excellent job of shipping lean systems with curated attack surfaces. These surfaces still need to be managed. The moment a new asset appears or a dependency shifts, vulnerability detection and remediation can stall. It’s hard to inform your security teams quickly when attack surfaces shift fast.

ASM keeps your production picture honest. ASR, if done well, will constrain your footprint’s growth. Without both, your production environments will drift into something no one can defend.

How Attack Surface Management works

Cloud systems behave a lot like a living organism: they’ll grow, mutate, and, unless carefully monitored, forget their own history. Your security team leans on their ASM disciplines to turn this chaos into something they can work with. ASM disciplines are continuous, since that’s what their environment is like, and you can think of them as looping through the following steps:

Discovery and inventory of assets

You start the loop by finding what’s actually live in prod. You can compare what you find to the diagrams and documentation of what teams think they deployed, but your reality focuses on what’s actually live right now. Cloud APIs, DNS records, container registries, identity providers, supply-chain metadata. Find out what can be reached, and make sure it gets inventoried. Keep up at scale by automating the work away; manual audits won’t work.

Classification and risk prioritization

Discovery alone doesn’t get you very far. Tag assets by criticality, ownership, exposure path, and potential impact. Try to shrink your haystack so that the few genuinely dangerous needles become visible. Prioritize spending time on attack paths and vulnerabilities that make a real difference.

Remediation and reduction of exposures

Once the surface is mapped and prioritized, the hard work begins. Remediation (closing ports, patching images, revoking keys, and so on) scales with system complexity. While a disciplined approach helps, the time and effort remain very high. Engineering teams are already overloaded. This is where ASM shines: do it well, and your workload will reduce to work that’s worth your engineers’ time. Each remediation effort also feeds into your ASR, giving you ideas for reducing your attack surface.

Continuous monitoring and governance

Everything drifts. Permissions widen, ephemeral jobs stick around longer than expected, and dependency updates introduce new attack paths. Continuous and automated monitoring, when done well, will validate system governance (did we actually mean to launch this in production?) and catch any relapses before they turn into another “how did we miss this?” meeting.

ASM is the not-so-glorious plumbing that keeps your security up to date as you grow.

Types of attack surfaces that organizations must manage

Attack surfaces for cloud systems will extend across external, internal, and supply chain components. The interactions among all three result in an exponential increase in the number of attackable entry points in your production systems. Most teams underestimate how quickly risk accumulates across all three.

External digital assets

Domains, DNS records, exposed cloud services, CDN endpoints, unmanaged SaaS integrations, and any internet-facing service, such as a web page or application. Anything that can be directly accessed intentionally or accidentally from the internet. These assets fail loudly; misconfigurations become public immediately, and attackers find them nearly instantly, much faster than internal teams.

Internal infrastructure and applications

Internal APIs, staging systems, CI runners, dev tunnels, message brokers, debug dashboards, and legacy systems that were never fully retired. These surfaces fail quietly: they’re often reachable through complex pathways that are difficult to map, and they carry high privileges by default.

Software supply chain

Dependencies, base images, package repositories, build systems, artifact stores, and every transitive component your workload inherits. These are the parts of your attack surface that are hardest for you to see and have the highest impact. Attackers know this, and supply chain attacks can cause the most damage when they get through.

All three surfaces move independently, and their changes compound. If you take your eyes off one of them, you’ll leave blind spots that attackers will find before you do.

Common challenges in managing the attack surface

Most organizations think about attack surfaces during planning, and then assume it will all go well once in prod. Especially after a rigorous ASR process, a system can seem very secure at the whiteboard stage. Unfortunately, real systems rarely behave as whiteboard models predict. Production environments move faster than their documentation, security programs, designs, and architecture updates. Small security gaps can, if left unchecked, turn into systemic blind spots.

Lack of visibility

You can easily lose track of what is actually running in your systems. Cloud environments spawn resources automatically, internal systems outlive their owners, and supply-chain components enter through build tooling that isn’t well tracked. “Unknown unknowns” will dominate the risk picture, especially when you’re not regularly inventorying what’s live in prod.

Vulnerability overload

Scanners track and report everything they can see; they typically lack a clear understanding of what can or should be acted upon. Engineers inherit thousands of alerts and security reports. The vast majority of alerts are either irrelevant in context or lack an easy, obvious remediation. The signal can be drowned out by volume, and high-impact issues can get buried in the backlog.

Tool sprawl and gaps between teams

Your security, platform, DevOps, and developer teams might all be monitoring for vulnerabilities and security problems. Their tools often don’t share context, and their outputs are difficult to correlate and reconcile. Each team ultimately examines security alerts through its own “truth,” and so might disagree on priorities and remediation options. This makes it difficult for you to identify the owner for remediation. Your fixes will stall, and the same exposure will show up again across multiple dashboards.

Static processes in a constantly changing environment

In a modern cloud environment, assets appear and disappear hourly. Permissions drift. Dependencies update themselves into new risks. ASM programs built around regularly scheduled scans or quarterly audits often fall behind, creating lags between risk exposure, detection, and remediation that attackers can exploit.

These failure patterns are the default state for teams at first, until they intentionally start building an ASM program to handle the rate of change.

Best practices for effective attack surface management

Most ASM programs struggle because they try to take shortcuts. They start mapping the world before fixing it; they’ll launch monitoring and detection software at scale, then attempt to filter and optimize their output. Your best bet at success is to start with some constraints and careful thought upfront.

Expand ASM to include the software supply chain

Most exposure comes from outside your environment. Dependencies, base images, build tools, and package managers can quietly expand the surface every day. ASM isn’t complete or effective until supply-chain components are included in inventory and monitored for change. Make sure you understand the full scope of work for your ASM effort up front.

Focus on reduction, not just detection

Start by focusing on ASR; seeing the surface doesn’t help if its growth rate is out of control. Focus on ASR techniques, such as using minimal base images, trimming your service count, and enforcing tight IAM boundaries. Shrink the amount of work ASM generates at the system design and architecture levels.

Automate SBOMs and provenance

Manual tracking of provenance and SBOM generation is not tenable. Your internal build tools and the attacks you’re protecting against move at machine speed, and so, your security tools have to move just as fast. Effective ASM programs depend on upstream visibility. SBOMs and provenance are core to this work: they help identify the source of and context for your system changes. They are core information you’ll rely on when prioritizing and filtering security issues.

Align security and engineering workflows

Prioritized and filtered security issues are an excellent milestone to reach, but the work isn’t finished until they’re addressed. The most effective way to ensure remediation occurs is to map them cleanly into engineering workflows. That means figuring out the most efficient ways for your team to wire them into CI, issue trackers, PR checks, and other flows your engineering teams use. Enforce a 0-vulnerability policy across your supply chain, signed libraries only, ubiquitous automated monitoring, and so on. The less effort engineers spend on contextualizing issues, the more time they have to actually resolve them. ASM is most successful when the remediation effort becomes routine and avoids the overhead associated with interruption-driven processes.

Track a small set of metrics over time

Make sure that your management and shrinking efforts are impacting real operational metrics. Carefully choose a small set of metrics that are particularly relevant to your systems, such as time exposed, dependency freshness, identity sprawl, and drift frequency, and track them over time. You’ll then be able to notice if your surface is changing in size over time, and if your management efforts are improving your systems.

With these kinds of practices, you can keep your ASM program effective and usable as the environment grows. Avoid drowning your teams in noise and drift by carefully selecting and using tools that align with these best practices.

What to look for in an Attack Surface Management solution

Demos for ASM tools will try to convince you that you can just “solve” your attack surface. They’ll gather mountains of data, throw up fancy-looking dashboards, and help you route alerts to people who might have the time and attention to try to resolve them. Discovery platforms, vulnerability management systems, CI/CD integrations, cloud inventories, and preventive controls will work together to build a thorough inventory of your chaos. You then have to deal with the consequences. Strong ASM solutions go further and help stitch these categories together into a cohesive view. You’ll want a system that starts with detection and alerting, and then automatically opens tickets, routes them to the right teams, suggests likely fixes, tracks when fixes are applied, and re-validates that an exposure is gone afterward.

Continuous discovery and classification

A strong ASM solution won’t be restricted to weekly or other scheduled runs; it can run continuously. It should detect new assets as soon as possible after they appear, help resolve ownership, and classify exposure by business impact. Anything slower than real-time discovery creates blind spots.

Integration with CI/CD and cloud environments

Discovery systems that only look at production are late. Effective tools integrate directly with CI pipelines, pre-production environments, cloud APIs, identity systems, and artifact registries, enabling them to detect changes as they’re created and track vulnerabilities back to their exact source.

Built-in compliance and reporting

Regulated teams need to couple alerts and remediation with evidence of compliance. The solution should generate structured outputs aligned with FedRAMP, NIST, PCI DSS, and similar frameworks, and seamlessly integrate into your existing reporting workflows. You should not be forced to build and maintain parallel reporting workflows just to address compliance requirements.

Preventive controls

The strongest ASM integrates well with ASR. Your ASM tools should feed back into strong controls upstream, including hardened baselines, configuration policies, image restrictions, and guardrails that prevent bad states from shipping. They focus on removing entire classes of alerts and vulnerabilities at the source, where they’re much easier to manage, rather than waiting for detection and remediation cycles.

Reduce your attack surface with Chainguard

Most ASM tools reveal the attack surface and leave you to figure out your own strategy for shrinking it. Chainguard supports ASM in ways deeply integrated with your ASR efforts by delivering hardened, minimal components that integrate into your flows and minimize or eliminate risk before it can impact your monitoring and remediation in prod.

We focus on three principles:

• Secure-by-default design: artifacts start minimal, hardened, and verifiable

• Automation at scale: daily rebuilds and automated patching keep components current

• Developer-aligned workflows: no workflow pivots; teams continue using their pipelines and registries as normal.

Key capabilities for managing and reducing your attack surface:

• Minimal container and VM images with only the required packages that reduce your inherited exposure

• Continuously rebuilt artifacts that remove vulnerabilities upstream, often before scanners catch them, and fit in well with continuous discovery and classification systems

• Built-in SBOMs and signed provenance bring automatic traceability and compliance into your systems from day one

• SLA-backed patch timelines that guarantee fast remediation when issues do arise and are optimized for the metrics you’re likely to want to track

• FIPS-validated and STIG-aligned options easily fit in with the most stringently regulated workloads

• Drop-in CI/CD compatibility supports your existing systems, artifact registries, and scanning tools.

Chainguard starts with ASR: shrinking the supply chain surface upstream for a smaller, cleaner surface to manage. It then supports downstream ASM efforts by improving visibility, including scanner integrations, signed SBOMs, and security advisory reports. Talk to an expert.