Attack surface management is the ongoing work of finding every place an attacker could try to get into your systems, keeping that list accurate, and reducing it where you can. It covers internet-facing assets, cloud accounts, applications, APIs and the code and dependencies behind them.
What is an attack surface?
Think of the doors and windows of a building. Every public web page, API endpoint, login form, open port, cloud storage bucket, mobile app and connected partner system is an entry point. Add less obvious ones: forgotten test servers, old subdomains, exposed code repositories, third-party scripts on your pages, employee accounts.
The bigger the list, the more places for something to go wrong. And the list you remember is usually shorter than the list that exists.
What does managing it involve?
Four activities, repeated.
Discover. Find the assets. Use your cloud accounts' own views, DNS records, certificate logs, code repositories and device management. NIST SP 800-53 control CM-8 asks organizations to keep an inventory of system components that is accurate, includes all components and is reviewed and updated. Discovery is how you test whether yours is.
Assess. Check each asset for weaknesses: missing patches, weak login, exposed admin pages, vulnerable libraries. Control RA-5 covers vulnerability monitoring and scanning, and asks for scanning both on a schedule and when new vulnerabilities are reported.
Prioritize. Not every weakness deserves the same urgency. Consider what data sits behind the asset, whether the vulnerable code is reachable and used, and whether the flaw is known to be exploited. CISA maintains a Known Exploited Vulnerabilities Catalog and FIRST publishes EPSS exploitation likelihood scores, both free.
Reduce. Remove what you do not need: close ports, delete old sites, retire unused accounts, drop unused dependencies. Fixing a weakness helps. Removing the thing is better.
Is it only about the internet side?
No. The external view is one lens, often called external attack surface management. Inside, there are internal services, identity systems and SaaS tools. In software, there is a chain of dependencies, build systems and registries. An attacker who cannot get in through your website might get in through a compromised package or a leaked token.
What are the common sources of surprise?
Cloud resources created for a test and never deleted. Marketing sites run by agencies. Acquired companies' systems. Developer tools exposed with default settings. APIs that were meant to be internal. Each is an inventory failure first, and a vulnerability second.
How should a small team start?
Keep it small and regular. Write one list of domains, cloud accounts and public services, with an owner for each. Review DNS records and cloud public access settings monthly. Run dependency checks on your main applications. Keep a short register of things you decided to accept, with dates to revisit.
You do not need a platform to begin. You need a list, owners and a schedule. Tools help when the list outgrows manual effort.
How do you know it is working?
Look for decreasing surprises. Measure the share of public assets with owners, time from discovery to fix, and the number of assets removed. NIST SP 800-137 describes continuous monitoring as providing visibility into assets and vulnerabilities and the effectiveness of controls, which is the aim here.
What are the traps?
Counting assets as success. A higher count may mean better discovery or growing sprawl.
Scanning what you do not own. Test only systems you own or have permission to test.
Ignoring the application layer. An exposed application with a vulnerable library it never calls ranks below one with a live call. Reachability analysis tells you which.
One-time projects. The surface changes weekly. Treat it as a routine.
What to do
- Write one list of public assets with owners.
- Compare it with DNS, cloud and repository views each month.
- Scan main applications and their dependencies on a schedule.
- Rank findings by data, reachability and exploitation evidence.
- Remove unneeded assets, not just patch them.
- Record accepted risks with a review date.
Open the dependency inventory demo
Where Safeguard fits
Safeguard covers the application and software supply chain part of the surface: dependency inventory, reachability analysis to show whether vulnerable code is used, asset discovery with guardrails on discovered assets, and policies enforceable at build and release. These are generally available. It does not replace dedicated external attack surface tools.
Quick check
Is attack surface management a product?
It is a practice. Products can support it, and a small team can run the basics with lists and a calendar.
What shrinks the attack surface fastest?
Removing unused assets, such as old test sites, unused accounts and dependencies you do not need.
Sources
- NIST SP 800-53 Rev. 5, controls CM-8 and RA-5 (OSCAL catalog)
- NIST SP 800-137, Information Security Continuous Monitoring
- CISA Known Exploited Vulnerabilities Catalog
- FIRST, Exploit Prediction Scoring System
Last reviewed: 18 October 2026.
