The most common year one mistake in attack surface management is treating it as an inventory project. A longer asset list is not a smaller risk. Teams that succeed assign an owner to every asset, decide in advance what counts as urgent, and measure how fast unowned things get claimed or removed.
Why does the first year go wrong?
Attack surface management (ASM) starts with discovery, and discovery is satisfying. A tool finds hundreds of hostnames, forgotten test servers and storage buckets nobody remembers. The dashboard fills up. Then nothing changes, because the findings land in a queue with no owner and no deadline.
The pattern is familiar from every scanning program: finding things is cheap, deciding who fixes them is expensive.
Mistake 1: counting assets instead of owners
An asset without an owner is a finding that never closes. Before you buy anything, decide how an asset gets an owner: a tag in the cloud account, a repository that deployed it, a DNS record tied to a team. Report "percent of assets with a named owner" before you report "assets found."
Mistake 2: only looking from the outside
External discovery shows what an attacker can enumerate. It does not show why a service exists. The internal view, meaning repositories, build pipelines, container registries and cloud accounts, tells you who deployed it and what it runs. Teams that only watch the perimeter spend months guessing at owners. Teams that join both views can route a finding in minutes.
Mistake 3: no triage rule
Suppose a constructed example: a scan reports 400 exposed services. Without a rule, the team argues about all 400. With a rule such as "internet reachable, runs software with a known exploited vulnerability, handles customer data," the list drops to a handful that get worked this week. The rest get a longer clock.
CISA publishes the Known Exploited Vulnerabilities catalog, and its entries tell stakeholders to evaluate each asset's internet exposure. That is a ready made starting rule: exposed plus known exploited goes first.
Mistake 4: treating every alert as equal
Exposure is not exploitability. An open port running current software is a different problem from an open port running something with a public exploit. FIRST's EPSS publishes a daily probability that a CVE will be exploited in the next 30 days. Use it as one input beside exposure and business impact, not as the whole decision.
Mistake 5: no removal path
Half the value of ASM is shutting things down. If decommissioning needs three approvals and a ticket nobody watches, old assets stay. Agree on a "default to remove" policy for anything unowned after a set period, with an easy way for an owner to object.
Mistake 6: measuring volume
Findings per week rewards noisy tools. Better measures: median time from discovery to owner assigned, median time from owner assigned to resolved, and the count of assets that reappear after removal.
What does a better first year look like?
Picture a constructed team of eight engineers and one security lead. In month one they do not buy anything. They export cloud accounts, DNS zones and repository lists into one sheet and mark the owner column. About a third of rows are blank. That gap, not the tool, becomes the project.
In month two they write the triage rule and agree it with engineering managers, who now know the criteria before the first alert arrives. Surprises are what turn a security finding into an argument, so removing surprise is worth more than any extra scan.
By month six the question changes from "what do we have" to "what changed since last week." New exposure usually arrives through a deploy, a new vendor integration or an acquisition. Watching for those events is cheaper than rescanning everything, and it ties ASM to the pipelines your engineers already use.
One more habit helps: keep a short list of assets that were removed and later came back. Each one shows a process gap, such as infrastructure code that recreates the thing you deleted.
What to do
- Pick the owner source of truth first (cloud tags, repository ownership files, a service catalog).
- Write a three line triage rule and get engineering leadership to sign it.
- Join external discovery with internal context so every finding has a likely owner.
- Set a clock for unowned assets and a removal default.
- Report owner coverage and time to owner every month.
- Review the rule after one quarter against what was actually exploited or nearly exploited.
Quick check
What is the first metric to track in an ASM program?
Owner coverage: the share of discovered assets with a named, reachable owner. It predicts whether findings will ever be fixed.
Do I need a separate tool for ASM?
Not always. Some teams cover it with cloud inventory, DNS records and repository data. Buy a tool when the gap is discovery you cannot do yourself, not before you have owners and a triage rule.
Sources
Last reviewed: 18 October 2026.
