EASM from alert to fix, a worked example of one exposed asset

EASM (external attack surface management) finds internet-facing assets you may not know you own and flags exposure. This is a constructed example, not a real case. It follows one alert from discovery to closure so you can see the decisions a team has to make at each step.

The setup (constructed)

Company X sells a scheduling app. Its EASM tool runs a daily discovery pass from public sources: DNS records, certificate transparency logs, and open port checks against known ranges. On Thursday morning it reports a new hostname, staging-old.example.test, resolving to a cloud address, serving a login page over HTTPS, with a certificate issued three weeks ago. Nobody on the security team recognizes it.

The names, addresses and details here are invented for illustration.

Step 1: Is it ours?

Attribution comes first, and it is often the slowest step. The analyst checks the DNS zone for who created the record, the cloud account tags on the address, and the certificate request history. The record was created by a contractor account that ended last spring. The cloud address sits in a project owned by the product team, tagged with a ticket number from an old migration.

Result: it is ours, it has an owner team, and the owner never decommissioned it. Write that down in the alert record. If you cannot attribute within a set time, treat it as hostile until proven otherwise and escalate.

Step 2: What is exposed?

The analyst does a light, authorized check. The page is a login for a staging copy of the app. The server header reveals an old web framework version. A directory path returns a default error page that discloses a framework debug mode. No sensitive file is retrieved. The analyst does not try credentials.

What matters is the evidence list: outdated framework, debug output on, login reachable from the internet, unknown data inside. The data question goes to the owner.

Step 3: What is the risk call?

Staging copies often hold production data copies or live API keys. The owner confirms two facts: a database snapshot from production was loaded here for testing, and an integration key to a payment sandbox is in the environment file. The framework version has a published advisory. The team checks whether the vulnerable feature is enabled. It is.

The risk call is high. Reasons: internet reachable, known flaw with the feature on, real customer data likely present. Severity was not set by a score alone. It came from exposure plus data plus a reachable flaw, which is also how you should write it in the ticket.

Step 4: Contain, then fix

Containment first. The owner removes the public DNS record and blocks inbound traffic at the cloud firewall within the hour. This stops new exposure without destroying evidence. A snapshot of the machine is taken for review.

The fix is decommissioning, not patching. A staging copy that nobody uses should not be patched, it should be deleted. The owner deletes the instance, the database copy and the key, then rotates the payment sandbox key since it sat on an exposed host.

Step 5: Was anyone there before us?

The team pulls access logs for the three weeks. They look for requests to the debug path, unusual login attempts, and large downloads. In this constructed case they find automated scanning traffic and failed logins but no evidence of success. They record that conclusion with its limits: logs only covered what the server kept.

If they had found signs of access, the incident process would take over, following the preparation, detection, response and recovery practices in NIST SP 800-61 Rev. 3.

Step 6: Close with proof and prevention

The alert closes only when three things are attached: DNS record removed, instance deleted, and a re-scan showing the hostname no longer resolves. Then the team asks why this happened. Findings: no expiry on contractor-created DNS records, no required owner tag for cloud projects, and no cleanup step in the migration checklist.

Each cause gets a change. Records get an owner field and a review date. Cloud projects without an owner tag trigger a weekly report. The migration checklist gets a decommission step.

What does this example teach?

Discovery was the easy part. Attribution, risk framing, containment before deletion, log review and root cause were the work. A tool that only lists hostnames leaves all of that to you. Measure the process by time to attribute, time to contain and recurrence, not by number of assets found.

Safeguard focuses on the application and software supply chain side and does not replace an EASM tool. Findings in application dependencies, like the old framework above, are where its reachability analysis and fix pull requests help.

What to do

1. Define an attribution deadline and an escalation path for unknown assets.
2. Require an owner and review date on every DNS record and cloud project.
3. Contain first by removing exposure, then collect evidence, then delete.
4. Record why you rated severity, using exposure, data and a reachable flaw.
5. Close alerts only with a re-scan as proof.
6. Turn each root cause into a control change.

Quick check

Sources

1. NIST SP 800-61 Rev. 3, Incident Response Recommendations
2. CISA BOD 23-01, asset visibility and vulnerability detection

Last reviewed: 18 October 2026.