Attack surface management answers "what do we expose?", and vulnerability management answers "what is wrong with it?". ASM belongs upstream: it finds assets, assigns owners and feeds scanners and patch workflows. Without that link, discovery produces a list that nobody fixes.
What problem does the join solve?
Scanners test what they are pointed at. If an old subdomain, a forgotten cloud service or an unlisted application is not on the target list, it is never tested. It still faces the internet. ASM closes that gap by looking from outside and from your own records to find what is missing.
NIST SP 800-137 describes continuous monitoring as giving visibility into organizational assets and awareness of threats and vulnerabilities. The two programs are two halves of that sentence.
What flows from ASM to the vulnerability program?
Think of four outputs:
- New asset records. Hostname, address, technology guess, first seen date.
- Ownership. A named team or person, or an explicit "unowned" flag with a deadline.
- Scan targets. The asset is added to scanning, with the right scan type: network, web, dependency or container.
- Exposure context. Is it internet facing, behind login, or internal only? This feeds priority.
If any of the four is missing, the handoff fails. The usual failure is the second: assets are found, nobody claims them.
What flows back?
Vulnerability results should return to ASM as context. An asset with a known exploited flaw deserves more attention than one with none. CISA's Known Exploited Vulnerabilities catalog is a helpful signal, and CISA says to use it as an input to prioritization. Reachability matters too: a flaw in a component that your code never calls is lower urgency than one on a live path.
A flow you can copy
| Stage | Owner | Output |
|---|---|---|
| Discover | Security | New asset candidates weekly |
| Triage | Security with IT | Ours or not, in use or not |
| Assign | Engineering manager | Named owner and review date |
| Scan | Vulnerability team | Findings with severity and exposure |
| Fix or retire | Asset owner | Patch, config change or removal |
| Verify | Security | Rescan, close, record |
Keep it as one ticket chain so you can time each stage.
Where do programs collide?
Duplicate ownership. Both teams contact the same engineer with different tickets. Merge into one ticket per asset.
Different vocabularies. ASM says "asset," scanning says "host" and "application." Use one register and map names.
Different clocks. ASM may run daily, scans weekly. Agree what triggers an immediate scan when a new asset appears.
Patch policy. NIST SP 800-40 Rev. 4 recommends an enterprise strategy that simplifies and operationalizes patching. Decide how newly discovered assets fit that strategy, including a deadline for unowned ones.
What about software you build?
ASM sees the running service, not the code behind it. When a discovered asset is one of your applications, connect it to the repository, the dependency list and the build pipeline. That is where a fix happens. Without that mapping, a team patches the server and the next deploy brings the flaw back.
What does a good weekly meeting look like?
Keep it to thirty minutes with a fixed agenda. First, new assets found since last week and their owners. Second, assets without owners past their deadline, with a decision on each. Third, internet facing assets with exploited flaws and their status. Fourth, one process fix. Record decisions in the ticket, not in meeting notes. When the same type of asset shows up unowned twice, change the process that creates it, such as project templates that skip a register entry.
Where Safeguard fits
Safeguard offers asset discovery with guardrails on discovered assets, reachability analysis, policies and gates enforced at build, CI and release, and autonomous remediation that opens fix pull requests, off by default with each category starting on Manual. It does not claim external attack surface management coverage and does not replace an ASM tool; it covers the code and delivery side of the chain above.
What to do
- Create one asset register shared by discovery and scanning.
- Require an owner and review date for every new asset.
- Auto add discovered assets to scan targets with the right scan type.
- Return exploited and reachable flaw data to the asset record.
- Map each application asset to its repository and pipeline.
- Time each stage and fix the slowest one.
Quick check
Does ASM replace vulnerability scanning?
No. ASM finds assets. Scanning tests them. Each needs the other to be useful.
What is the most common failure?
Finding assets that nobody owns. Set a deadline and a default action, such as restricting access, for unowned assets.
Sources
- NIST SP 800-137, Information Security Continuous Monitoring
- NIST SP 800-40 Rev. 4, Enterprise Patch Management Planning
- CISA Known Exploited Vulnerabilities Catalog
Last reviewed: 18 October 2026.
