Attack surface management: an alert to resolution example

An attack surface alert is resolved when a named owner either fixes, retires or accepts the exposed asset, and the record shows when and why. This constructed example follows one alert from discovery to closure so you can see the decisions at each step.

This is a constructed example. The company, domains, people and timings are invented for illustration. It is not a real incident or customer.

The setting

ExampleCo is a fictional 200 person software company. Its security lead, Maya, runs a weekly review of newly discovered internet facing assets. The domain used here is example.com, reserved for documentation.

Step 1: The alert

On Monday the discovery process lists a new host, old-demo.example.com. It answers on a web port, shows a login page for a customer demo application, and its certificate was issued for the company domain. It is not in the asset register.

Maya asks three questions before anything else:

• Is it ours? The certificate and DNS record say yes.
• Is it in use? Traffic logs from the DNS provider show a few requests a week.
• Who owns it? Unknown.

Writing these three down matters. Many teams jump to scanning and skip ownership.

Step 2: Find the owner

Maya searches the code hosting platform for the hostname and finds a repository for a sales demo built two years earlier. The last commit author left the company. The sales engineering manager, Dev, owns the team that used it.

She opens a ticket assigned to Dev with a plain summary: what the asset is, why it matters, and a decision due by Friday. The ticket offers three options: fix, retire or accept.

Step 3: Assess the exposure

Before Dev answers, Maya checks the basics, using only safe, passive checks and the company's own systems:

• The login page uses an old application version. The version is noted in the page footer.
• The software's maintainers list newer releases. Whether the old version carries known flaws can be checked in the CISA Known Exploited Vulnerabilities catalog and vulnerability databases.
• The demo uses sample data, but the login page also accepts company single sign on, which means an attacker who finds a flaw might reach a path toward real accounts.

That third point turns a low priority asset into a priority one. NIST SP 800-137 talks about visibility into assets and awareness of vulnerabilities; this is the practical form of it.

Step 4: Decide

Dev says the demo is not used by sales any longer. Maya and Dev choose to retire.

The retirement checklist:

1. Take a snapshot of the data for the retention period set by policy.
2. Remove the DNS record.
3. Revoke the certificate and remove the host.
4. Delete the single sign on application entry.
5. Archive the repository.

Order matters. Removing the DNS record first, then the host, avoids leaving a dangling record that could be claimed by someone else, a known risk for abandoned subdomains.

Step 5: Verify and close

On Thursday, Maya reruns discovery. The host no longer resolves. The single sign on entry is gone. She adds a closing note: asset retired, owner Dev, root cause "demo environment without end date."

The register now carries a record: discovered Monday, owner assigned Tuesday, retired Thursday.

Step 6: Fix the process

The record shows the real problem. Demo environments had no owner field or expiry. Maya adds two rules: every new internet facing host needs an owner and review date in the register, and expired review dates raise a ticket.

What would have changed the outcome?

If Dev had said the demo was in use, the choice would be fix: update the application, remove single sign on access, restrict it by network rules and set a review date. If nobody could decide, the default after a deadline would be to restrict access, not to leave it open.

Where Safeguard fits

Safeguard offers asset discovery with guardrails on discovered assets, plus reachability analysis and policies at build and release. In an example like this, those help decide whether an old application's flaws are reachable and keep new builds from shipping with the same weaknesses. Safeguard does not claim external attack surface management coverage and does not replace that tool.

What to do

1. Ask three questions first: ours, in use, owner.
2. Open a ticket with fix, retire or accept options and a due date.
3. Do passive checks only and note anything touching single sign on.
4. Retire in order: data snapshot, DNS record, host, access entries.
5. Rerun discovery to verify closure.
6. Change the process so the same gap cannot recur.

Quick check

Sources

• NIST SP 800-137, Information Security Continuous Monitoring
• CISA Known Exploited Vulnerabilities Catalog
• NIST SP 800-40 Rev. 4, Enterprise Patch Management Planning

Last reviewed: 18 October 2026.