How do you run an attack surface assessment?

An attack surface assessment lists every way an attacker could reach or influence your systems, such as internet-facing services, APIs, accounts and third party code, then ranks them by exposure and value so you can shrink the riskiest first. Run it as a repeatable inventory, not a one-off report.

What counts as attack surface?

The OWASP Attack Surface Analysis Cheat Sheet describes it as the set of entry points, the data and functionality they reach, and the privileges involved. In practice it includes network-facing services, web pages and API endpoints, user interfaces, file and message inputs, administrative functions, accounts and keys, and the third party components that run inside your app.

There is a human layer too: staff who can be phished, and suppliers with access. A thorough assessment notes them, even if technical work dominates.

How do you build the inventory?

Start from the outside and from the inside, since each view misses things.

1. External view. Domains and subdomains, public IP addresses, open ports, cloud storage, public code repositories and published APIs. Include forgotten test sites, old marketing pages and acquired company systems.
2. Application view. For each app, list routes and endpoints, input types, authentication methods, roles and admin functions. Read the code or API definitions to find ones that exist but are not documented.
3. Component view. List libraries and services your code depends on, including transitive ones. A software bill of materials is the natural format.
4. Identity view. List accounts, service accounts and keys with access to each system, and when they were last used.

Compare these lists. Anything that appears in one and not another is a question: why is it there, and who owns it?

How do you rank what you find?

OWASP suggests focusing on what is accessible, what it can do and what it holds. A simple score uses three questions, each rated low, medium or high: how exposed is it, how easy is it to abuse, and how bad is the result.

Add evidence. Is there a known vulnerability in the exposed component? CISA's Known Exploited Vulnerabilities catalog lists flaws with evidence of active exploitation, so a match there goes to the top of the list. For flaws in dependencies, check whether your code actually calls the vulnerable function, which is the idea behind reachability analysis.

A constructed example. An assessment of a mid-size company finds 140 public hostnames. Ninety map to known apps. Thirty are old test sites. Twenty are unknown. Among the unknown, one is a staging admin panel with a default login, running an outdated library. That single item outranks the other 139 and is fixed the same day, by removal. The assessment found it because the external list was compared with the application owner list.

What do you do with the results?

Reduce first. Remove what is not needed: delete old sites, close ports, disable unused features, revoke unused keys. Every item removed leaves one less thing to defend. Then restrict what remains: put admin functions behind authentication and network limits, apply least privilege. Only then harden and monitor.

Record owners. An entry without an owner will not get fixed, so each item gets a named person or team.

Where can Safeguard help?

For the application and component views, Safeguard can scan dependencies, produce an SBOM and run reachability analysis to show which known vulnerabilities your code can actually reach. It does not replace a review of your external network exposure.

How to check or apply this

1. Assemble the four views: external, application, component and identity.
2. Merge them into one sheet with an owner column.
3. Chase every item with no owner.
4. Score each item for exposure, ease of abuse and impact.
5. Check exposed components against the KEV catalog.
6. Remove or restrict the top ten items within a set deadline.
7. Repeat monthly for external exposure and after each major release.

Quick check

Sources

1. OWASP Attack Surface Analysis Cheat Sheet
2. CISA Known Exploited Vulnerabilities Catalog
3. CISA, Software Bill of Materials

Last reviewed: 18 October 2026.