To measure an attack surface, count entry points by type, mark which are reachable without login, and track age and ownership. Trend the numbers month to month. A single composite score hides the detail you need to act, so keep the counts separate and tie each to a decision.
What OWASP suggests counting
OWASP's guidance says to group attack points into types by function, design and technology, such as login entry points, admin interfaces, search, forms and integrations, then count each type and pick representative cases to review rather than examining every endpoint. It also mentions published research metrics that sum entry points, channels and untrusted data items, weighted by damage potential and effort, to compare risk over time.
You do not have to adopt a formal model to use the idea. The practical lesson is to count by type and review samples.
Five counts worth keeping
- Internet-facing assets by type: web apps, APIs, mail, remote access, storage.
- Anonymous entry points: pages and endpoints reachable without login.
- Admin interfaces reachable from outside.
- Unowned assets: items with no named owner.
- Unused items still deployed: old versions, backups, features nobody uses. OWASP lists these as part of the surface.
Two ratios
- Share of assets with an owner. Aim for all of them.
- Share of internet-facing assets behind single sign-on or another strong authentication.
Ratios are easier to explain to management than raw totals, and they move in a useful direction when you do the work.
Why not one number
A composite score mixes things that need different fixes. A rise in the score could mean more unowned hosts, more anonymous endpoints, or a bigger product. You would not know which to fix. It also invites gaming: remove a few easy items and the score drops while the dangerous ones remain.
How to use the counts
- Review monthly, as in the monthly review checklist.
- Explain any increase in terms of real projects.
- Set targets for ratios, not totals.
- Ask which count would surprise the leadership team, and show that one.
Risk ranking on top of counts
OWASP recommends prioritising internet-facing or network-facing code, public anonymous access, web forms, files from outside the network, legacy interfaces, custom APIs, and security-critical code such as cryptography, authentication, authorization and session management. Compensating controls such as firewalls and intrusion detection can lower the ranking of an item.
Present the counts with one sentence on what you will do about each. A number without an action tends to become a chart nobody reads.
Where Safeguard fits
For the software side, Safeguard offers dependency scanning and reachability analysis, which separate flaws your code can reach from flaws in code it never calls. It does not produce external attack surface scores.
Quick check
Is a lower count always better?
Not automatically. A small number of unprotected entry points can be worse than many protected ones. Count, then rank by risk.
Sources
Last reviewed: 19 October 2026.
