Attack surface management for your CFO and board: a plain briefing

Attack surface management is the practice of keeping a current list of everything about your company that is reachable by an attacker, such as websites, cloud accounts and online services, and making sure each item has an owner and a reason to exist. For a board, it answers: do we know what we have exposed?

What is the problem it solves?

Companies grow by accident. Teams launch a campaign site, a test environment or a cloud account, and then move on. Years later it is still running, nobody owns it and nobody patches it. Attackers do not need to be clever to find it.

NIST defines an attack surface as the set of points on the boundary of a system, a system element or an environment where an attacker can try to enter, cause an effect on, or extract data. The practice is simply about knowing where those points are.

Why is this a board matter and not just an IT task?

Three reasons. Exposure creates liability, since an unknown system that leaks customer data is still your responsibility. The cause is often organisational, with teams creating things outside any central process. And fixing it needs decisions about ownership and retirement that no technical tool can make.

CISA's Binding Operational Directive 23-01 for federal agencies begins from the statement that continuous and comprehensive asset visibility is a basic precondition for managing cybersecurity risk. It is aimed at federal civilian agencies, not companies, but the reasoning applies to any organisation.

What does the work look like?

Four repeating steps.

1. Discover. Find assets, including ones nobody told security about. The directive above describes this as identifying network addressable assets, and notes it is non intrusive and usually needs no special access.
2. Assign. Give each asset an owner. Unclaimed ones go to a review queue with a rule: claim it or retire it.
3. Assess. Check what is exposed on each asset and whether known flaws are present.
4. Reduce. Close what is not needed. Remove old sites, accounts and open services.

What does it cost?

We are not quoting prices. The drivers are:

• Tools or services for discovery, priced by assets, domains or similar units, which grow as discovery finds more.
• People to review findings, find owners and chase fixes. This is usually the larger cost.
• Engineering time from the teams that retire or fix assets.
• Growth. Acquisitions and new cloud accounts add assets.

A useful question: what do we already pay for that finds assets, such as cloud provider tools or existing scanners?

What numbers should the board ask for?

1. Assets without an owner. The count, and the age of the oldest.
2. Newly discovered assets this quarter, and how many were ours. A large number is not bad news. It means discovery is working.
3. Exposed services that need no exposure. Trend over time. This should fall.
4. Age of the oldest known exploited flaw on an exposed asset. CISA's Known Exploited Vulnerabilities catalog lists flaws with evidence of exploitation, so this number is concrete.

What are the warning signs?

• Asset counts that never change. Real estates change.
• A dashboard of findings with no owners.
• Scope that excludes subsidiaries, acquisitions or marketing sites.
• Reports with no mention of what was retired.

What does it not cover?

It sees what is reachable from outside. It does not see inside your applications. A fully patched web server can still run an application with a vulnerable library. Ask management how application dependencies are tracked, and how they check that flagged flaws are reachable before ranking them.

What to do

1. Ask management for the current list of public assets, and where it comes from.
2. Ask how many have no owner, and the plan to retire or claim them.
3. Request the four numbers each quarter, with trends.
4. Ask how acquisitions and new cloud accounts are added to the list.
5. Ask how application dependencies are covered.
6. Review after two quarters to see whether the unowned count falls.

Where Safeguard fits

Safeguard focuses on the application and software supply chain side. It offers asset discovery with guardrails on discovered assets, and reachability analysis to show whether a vulnerable dependency is used. It does not replace an external attack surface tool, which gives the outside view described above, and the two complement each other.

Quick check

Sources

• NIST glossary: attack surface
• CISA BOD 23-01
• CISA Known Exploited Vulnerabilities catalog

Last reviewed: 18 October 2026.