Your CISO asked you to “stand up an ASM capability.” You have a cloud-native stack, a small team, and a lot of conference talk abstracts but very little operational guidance. Where do you actually start?
This is the practical answer.
Why Most ASM Programs Stall at Phase One?
Attack surface management sounds tractable in vendor decks. In practice, teams get stuck because the starting point is unclear. Do you begin with external asset discovery? Internal inventory? Vulnerability scanning? Cloud configuration assessment?
The answer depends on where your highest-risk unknowns are. For cloud-native organizations, that answer is almost always the same: your container images.
“The most common ASM program failure mode is breadth without depth — discovering 10,000 assets and being able to act on none of them. Start narrow, go deep, then expand.”
Phase One: Discovery
Before you can manage your attack surface, you need to know what it is. In a cloud-native environment, discovery has distinct layers.
Network and Endpoint Discovery
Map your external-facing assets: domains, IP ranges, API endpoints, load balancers. This is where traditional EASM tools excel. It gives you your perimeter, but not your interior.
Container Image Inventory
Pull a complete list of images from every registry you operate. This is your cloud-native asset inventory baseline. Every image in your registry is a potential deployment target and a potential attack surface. Secure software supply chain practices require knowing every image, not just the ones currently running.
Infrastructure Configuration Discovery
Map your cloud resource configurations: IAM policies, storage bucket permissions, network rules, Kubernetes RBAC bindings. These configuration assets carry their own attack surface that image-level scanning does not capture.
Phase Two: Inventory and Baseline
Discovery gives you a list. Inventory gives you a system. The difference is metadata, ownership, and continuity.
For each discovered asset, establish:
- Owner (team or individual responsible for security decisions)
- Criticality (what systems does this touch? what data does it access?)
- Current vulnerability state (CVE count, severity distribution, age)
- Last assessed date (staleness is a risk multiplier)
Your image inventory is particularly important here. Images with no known owner are your highest-risk assets. They accumulate CVEs with no one responsible for remediation.
Phase Three: Prioritization
You now have more vulnerability data than your team can act on. Prioritization is how you decide what to fix first.
Apply these filters in sequence:
- Exploitability – Is there a known exploit in the wild?
- Reachability – Can an attacker reach the vulnerable component?
- Blast radius – If exploited, what can the attacker access next?
- Asset criticality – What is the business impact if this asset is compromised?
CVSS scores alone fail at this step. A CVSS 9.8 vulnerability in an air-gapped development container is lower priority than a CVSS 6.5 vulnerability in a public-facing image with database access. Container security software that incorporates reachability analysis makes this prioritization measurable rather than subjective.
Phase Four: Continuous Reduction
A one-time assessment is not a program. A program has continuous discovery, continuous scanning, and continuous remediation.
Automate image scanning on every build. Any image that enters your registry should be scanned before it is deployable. Gate deployment on policy thresholds.
Track surface reduction metrics over time. Total CVE count, high-severity count, mean time to remediation, and percentage of images meeting baseline standards are your program health indicators.
Establish a hardening baseline and enforce it. Define what a “passing” image looks like: maximum CVE count by severity, required scan recency, prohibited packages. Enforce this at admission control.
Review your asset inventory quarterly. Cloud environments change fast. Images that were not in your registry last quarter are now. Images that were running are now abandoned. Your inventory decays if you do not maintain it.
Frequently Asked Questions
What are three key components of attack surface monitoring?
The three key components of attack surface monitoring are continuous discovery, continuous scanning, and continuous remediation. Discovery ensures new assets entering your environment are captured immediately — in cloud-native organizations, this means scanning every image entering your registry. Scanning assesses vulnerability state across the full inventory. Remediation requires a programmatic path from finding to fix, not just a report that the team must act on manually.
How to build a security program from scratch for cloud-native environments?
Start narrow and go deep rather than trying to achieve breadth across all asset types at once. For cloud-native organizations, the highest-risk unknowns are almost always container images — pull a complete registry inventory first, establish ownership and criticality metadata for each image, then build continuous scanning and hardening gates into your CI/CD pipeline. Expand to external asset discovery and infrastructure configuration assessment once the image layer is under control.
What are the 5 steps of vulnerability management in an attack surface management program?
The five steps map to the ASM program phases: discovery (identify all assets), inventory (establish metadata, ownership, and baseline vulnerability state), prioritization (apply exploitability, reachability, blast radius, and criticality filters), remediation (reduce the attack surface through hardening and patching), and continuous monitoring (track metrics like CVE-free image rate and mean time to remediation over time). CVSS scores alone fail the prioritization step — a CVSS 6.5 in a public-facing image with database access outranks a CVSS 9.8 in an air-gapped dev container.
Metrics That Demonstrate Program Progress
Your ASM program needs to produce numbers that leadership can understand. These are the right ones:
- Total attack surface reduction (percentage of components removed from images)
- Mean CVE age (average time a CVE exists in your environment before remediation)
- Image compliance rate (percentage of running images meeting your baseline standard)
- Discovery coverage (percentage of running images with a known owner and current scan)
These metrics give you a trajectory. They give your board a way to see progress. And they give you an honest view of where the gaps remain.
Start with discovery. Build the inventory. Prioritize ruthlessly. Reduce continuously.
