Asset Exposure Discovery Tools Compared: 4 Approaches
This comparison names at least one weakness of every approach and product discussed. It is written for change and risk managers, not as legal or compliance advice. Some outbound links may be affiliate links; they never change which tools we cover or how we assess them.
Why this matters right now
When CISA’s BOD 26-04 reorganized the KEV deadline around a risk table, it made one variable your own responsibility: whether the affected asset is publicly exposed. The directive and the KEV catalog tell you a CVE is being exploited; they cannot tell you whether you are running the vulnerable software on an internet-reachable host. That answer decides whether a three-day clock applies to a live emergency change or to a routine patch you can schedule.
Most teams discover the answer the hard way, during an incident, by asking around. That is inventory debt, and a compressed remediation deadline exposes it instantly, because you cannot emergency-change an asset you cannot list. The fix is to decide, before the CVE lands, which discovery approach answers the exposure question fast enough to matter. Four categories dominate: internet-scan query engines like Shodan, managed external attack surface management (EASM) platforms like Censys, active-and-passive network discovery like runZero, and the cloud provider’s own asset inventory. Each sees a different slice, and the gaps between them are where exposed assets hide.
What is external attack surface management, and what does it not cover?
NIST defines the attack surface as the set of points on the boundary of a system where an attacker can try to enter, affect, or extract data from it (NIST SP 800-53 glossary). External attack surface management is the practice of discovering the internet-facing subset of that boundary — the assets an attacker can find and probe without any inside access, including systems you did not know were exposed. The federal baseline for the underlying inventory is concrete: CISA’s BOD 23-01 requires agencies to perform automated asset discovery every seven days across the entire IPv4 space they use, and to run vulnerability enumeration across all discovered assets every fourteen days.
The distinction that matters for a CAB is perspective. EASM answers “what can an attacker see,” which is exactly the exposure variable BOD 26-04 leaves to you. Internal discovery answers “what do I actually run,” which is what you need to confirm the vulnerable version is present. Neither answers the other’s question. An EASM platform that reports a clean external footprint says nothing about an internal jump host running the same flawed middleware, and an internal inventory that finds the vulnerable package says nothing about whether it is reachable from the internet. The exposure decision needs both views reconciled.
How does Shodan answer the exposure question?
Shodan is the query-first option: an internet-wide scan database you search by IP, service, or banner through its REST API at api.shodan.io, with on-demand scanning that lets you crawl a specific network or even the whole internet for a given port and protocol (Shodan API reference). Authentication is a single API key passed as a query parameter, which makes it fast to wire into a script or a change-triage workflow. For the BOD 26-04 exposure variable, you can query Shodan for the affected product banner across your known IP ranges and get an attacker’s-eye answer in minutes.
The weakness is the scan-credit economy and freshness. Shodan meters on-demand scanning by scan credits, where each IP scanned consumes one credit, and forcing a re-crawl of a recently scanned IP requires an Enterprise subscription’s --force option (Shodan on-demand scanning). That means the free or low-tier view you query may be days old, and a service you stood up yesterday may not appear until Shodan’s crawlers reach it. For a same-day KEV decision, stale banner data can produce a false negative, so Shodan is strongest as a rapid first pass, not a system of record.
How does Censys ASM compare?
Censys sells the managed EASM experience: rather than you querying a scan database, its Attack Surface Management platform continuously attributes and monitors your external footprint and combines internet-scan data with a live feed of your cloud inventory. Its Cloud Connectors keep the picture current by refreshing cloud data as often as every four hours, covering S3 buckets, GCP, Azure blobs, virtual instances, and databases (Censys Cloud Connectors). The connectors need only read-level permissions such as Reader, Reviewer, Viewer, or Audit, which view asset metadata without touching the assets themselves, so the security review to enable one is modest.
The weakness Censys itself acknowledges is attribution. Accurately deciding which internet-facing asset actually belongs to your organization is the hard part of managed EASM, and a mis-attributed asset either inflates your surface with someone else’s host or, worse, drops one of yours from the inventory (Censys Cloud Connectors). The four-hour refresh also applies to the cloud-connector feed, not to a guaranteed re-scan of every external host on demand, so like Shodan it is an external view that can lag a brand-new exposure. It is a strong continuous monitor, less so as an instant on-demand oracle.
Where does runZero fit, and where does it fall short?
runZero flips the perspective inward. It gathers asset data through unauthenticated active scanning, passive traffic sampling, and inbound integrations, using network protocols to discover and fingerprint everything connected to specified networks, and it can run scans once or on a schedule (runZero data gathering). Because the active scan needs no credentials on the target, it finds unmanaged and forgotten devices that an authenticated tool or an EDR agent would miss entirely, which is precisely why runZero positions itself as a way to meet BOD 23-01’s asset-inventory requirement where agents and authenticated scans are “no longer sufficient” (runZero on BOD 23-01). For confirming that the vulnerable version is actually present on your networks, this is the strongest of the four.
The weakness is that runZero’s native strength is the internal and physical network, not the attacker’s external view. runZero itself notes that its API-query discovery is recommended only for software-defined infrastructure such as cloud or virtualized environments and not for physical networks, so its cloud coverage leans on integrations rather than direct scanning (runZero on BOD 23-01). It tells you what you run; it does not, on its own, tell you what the internet can reach. Pair it with an external view to close the exposure question.
Where does cloud-native inventory help, and where does it blind you?
The fourth approach is the one you already own: the cloud provider’s asset inventory, queried through its API with IAM read credentials. It is authoritative and near real-time for resources inside accounts you know about, and it costs nothing beyond the cloud account. For a KEV affecting a managed service, this is the fastest confirmation of both presence and exposure, because the provider knows which load balancers and instances carry public IPs.
The blind spot is definitional: cloud-native inventory only sees accounts and subscriptions that are enrolled in your inventory tooling. A team that spun up a separate project on a personal card, a subsidiary’s unlinked organization, or a forgotten legacy account is invisible to it. That is the shadow-asset gap EASM exists to catch, and it is why the exposure variable in BOD 26-04 cannot be answered by cloud inventory alone. Treat cloud-native inventory as ground truth for known accounts and as silent about everything outside them.
Original comparison: four approaches, five axes
We mapped the four approaches against the axes that decide a KEV exposure call. The pattern is that no column is green across all four rows, which is the whole point: they are complements, not substitutes.
| Approach | External view | Internal view | Best single use |
|---|---|---|---|
| Shodan (query API) | Strong | None | Rapid attacker’s-eye first pass |
| Censys ASM | Strong | Cloud only | Continuous external monitoring |
| runZero | None | Strong | Confirming the vulnerable version is present |
| Cloud-native inventory | Partial | Cloud only | Ground truth for known cloud accounts |
The takeaway for a change program: the exposure question needs one external view and one internal view, run against each other, with the delta treated as unconfirmed assets to chase. A single tool leaves a gap an attacker can use.
What to do about it
- Decide your two default tools now, before a KEV lands: one external (Shodan or Censys) and one internal (runZero or cloud-native inventory). Write both into your emergency-change runbook.
- When a KEV drops, query the external tool for the affected product banner across your known IP ranges to get the attacker’s view in minutes.
- In parallel, query the internal tool to confirm the vulnerable version is actually installed and to find instances the external view cannot see.
- Reconcile the two lists. Any asset in one but not the other is an unconfirmed exposure; treat it as in-scope until proven otherwise.
- Feed the reconciled, exposed asset list into your change risk score so the emergency-change decision is driven by confirmed exposure, not a guess.
- Record which tool answered the exposure variable and when, so the deferral or emergency-change decision is defensible if an auditor asks.
Frequently asked questions
What is the difference between EASM and asset discovery? EASM discovers internet-facing assets from an attacker’s perspective and surfaces unknown systems; internal asset discovery finds everything on your networks regardless of reachability. EASM answers what an attacker sees; asset discovery answers what you run. A complete exposure picture needs both.
Can Shodan tell me if my asset is vulnerable to a specific CVE? It tells you which internet-facing hosts expose a service and banner, a strong exposure proxy, but does not authenticate to confirm the exact patch level and may be days old. Treat it as a rapid first pass, not definitive confirmation.
How often does Censys refresh cloud asset data? As often as every four hours once a Cloud Connector is configured, across S3, GCP, Azure blobs, instances, and databases. That is the cloud feed, not an on-demand re-scan of every external host.
Does runZero require credentials to scan? No. It uses unauthenticated active scanning to find unmanaged devices, plus passive traffic sampling. Its API-query discovery is meant for software-defined infrastructure, not physical networks.
Why can’t I just use my cloud provider’s asset inventory? It is authoritative for enrolled accounts but blind to unlinked subsidiaries, shadow projects, and legacy accounts — the shadow assets attackers find first.
What does BOD 26-04 require me to determine about exposure? Whether you run the affected software on an internet-reachable host, which decides whether a compressed KEV deadline is a live emergency change or a scheduled patch.
How fast can these tools answer during a KEV deadline? Shodan and cloud APIs answer in minutes for known ranges; Censys monitors continuously on a cadence; runZero returns as fast as a scan completes. Pre-wiring the queries into your runbook is what makes them fast enough.
For more tool-by-tool breakdowns like this, see our tools comparisons beat.
Sources
- NIST — Attack surface (SP 800-53 glossary)
- CISA — BOD 23-01: Improving Asset Visibility and Vulnerability Detection
- Shodan — REST API reference
- Shodan — On-demand scanning and scan credits
- Censys — ASM Cloud Connectors documentation
- runZero — Gathering data (active scanning and passive sampling)
- runZero — Meeting CISA BOD 23-01 asset-inventory requirements
Published August 31, 2026.