On May 31, 2023, Progress Software disclosed CVE-2023-34362, a SQL injection in MOVEit Transfer with a CVSS score of 9.8. The Cl0p ransomware group had already been exploiting it as a zero-day, and Rapid7 published its first exploitation analysis a single day later, on June 1, after observing the same attack pattern across multiple customer environments. What made MOVEit a watershed case wasn't the vulnerability class — SQL injection is decades old — it was where the vulnerability lived: a single internet-facing file-transfer appliance that most of the organizations running it, and virtually none of the thousands of organizations breached through their vendors' MOVEit instances, had ranked as a high-priority asset. That gap between "what's exposed" and "what we're actually watching" is the entire problem attack-surface management exists to solve. It isn't a scanning tool category so much as a discipline: continuously discovering every asset an organization owns, exposes, or depends on, then ranking the resulting list by what an attacker could actually reach and exploit today. This post lays out that methodology step by step — inventory, categorization, exploitability scoring, and continuous re-evaluation — and where a platform like Safeguard automates each stage.
What counts as attack surface, and why does "external" undercount it?
Attack surface is every point where an untrusted party could interact with, or depend on, your systems — and external-only scanning undercounts it because most real intrusions in the last decade didn't start with a port scan of your own IP ranges. MOVEit victims weren't breached through their own MOVEit servers in most cases — they were breached because a third party they used ran one. A complete inventory has to span at least four categories: internet-facing infrastructure (web apps, APIs, VPN gateways, file-transfer tools), cloud resources and misconfigurations (public S3 buckets, over-permissioned IAM roles, exposed Kubernetes dashboards), identity and credential exposure (leaked API keys, reused passwords, stale service accounts), and third-party/vendor systems that touch your data but that you don't operate. Shadow IT — infrastructure nobody registered — cuts across all four. Any methodology that stops at "assets we know we own" is measuring the wrong thing.
How do you actually discover the full asset inventory?
You discover the full inventory by combining three collection modes, because no single one sees everything: agentless integration, lightweight agents, and ingested bills of materials. Agentless integration connects via OAuth or IAM roles to Git providers, container registries, cloud accounts, and model registries, then continuously enumerates new repositories, images, and releases rather than scanning once. Lightweight agents — a Kubernetes DaemonSet, a host collector, a CI/CD runner hook — catch what agentless connections can't see from outside, like loaded shared libraries or admission events on a cluster. SBOM ingestion closes the vendor gap: when a supplier hands you a CycloneDX or SPDX document instead of source access, that document becomes a queryable node in your inventory the moment it's uploaded. Safeguard's asset-discovery layer, for example, tracks seven asset classes this way — source repositories, container images, packages, AI models, SBOMs, vendors, and runtime workloads — and stitches them into a typed graph so a query like "which production workloads contain a specific vulnerable package version" returns an answer instead of requiring a fresh manual audit.
How do you find the assets nobody registered?
You find unregistered assets by treating the absence of governance data as a signal in its own right, not by scanning harder. A repository that exists in your GitHub org but was never connected to your security tooling, a container image sitting in a registry with no accompanying SBOM, a workload observed running in production that matches no image in any SBOM, a vendor API your application calls in production that never went through third-party risk review — each of these is discoverable precisely because it's missing something every governed asset has. This is the practical definition of shadow-asset detection: cross-reference what's running against what's registered, and flag the delta. It matters because the MOVEit pattern repeats at smaller scale constantly — an internal team stands up a file-transfer or admin tool, nobody adds it to the vendor registry or the vulnerability-scanning scope, and it sits unpatched until an incident forces someone to ask "did we know this existed?" Safeguard surfaces these as an explicit UNGOVERNED status on its Asset Discovery dashboard, which can trigger automation like ticket creation or a deployment block until the asset is properly onboarded.
Once you have a full inventory, how do you decide what to fix first?
You decide what to fix first by layering exploitability signals on top of severity, because CVSS alone tells you almost nothing about which findings an attacker is currently using. CISA's Known Exploited Vulnerabilities (KEV) catalog, running continuously since November 2021, is the most direct signal available: it lists only CVEs CISA has confirmed are being actively exploited in the wild, and it's updated on a rolling basis — batches of a handful of new entries in a typical alert. A finding that's KEV-listed should outrank a higher-CVSS finding that isn't. FIRST.org's Exploit Prediction Scoring System (EPSS) adds a probabilistic layer on top, estimating the likelihood a given CVE will be exploited in the next 30 days across a dataset covering the great majority of published CVEs — useful precisely because most CVEs, even serious-looking ones, are never exploited at all. Combining CVSS severity, KEV status, and EPSS score with business context (is this asset internet-facing, does it hold regulated data, who owns it) turns an undifferentiated backlog of a thousand findings into a short list an engineer can act on this sprint.
Why is a point-in-time scan not enough?
A point-in-time scan isn't enough because your attack surface changes every time a new CVE is disclosed, a container ships, or a vendor rotates their infrastructure — none of which wait for your next scheduled scan. The MOVEit vulnerability existed in production systems for an unknown period before disclosure; what mattered afterward was how fast affected organizations could tell whether they were exposed at all. A continuous model re-evaluates the existing inventory against live vulnerability feeds — NVD, CISA KEV, EPSS deltas — instead of waiting for the next scheduled crawl. Safeguard's continuous-scanning architecture illustrates the mechanics: new advisories are matched against components already stored as nodes in a knowledge graph via package URL and version-range resolution, so only the assets actually affected get re-scored, with a stated latency of under 60 seconds from a new CISA KEV addition to a scored finding appearing in the product, and under 2 minutes for a new NVD CVE. That architecture is what makes "rescan everything when the world changes" cheap enough to run continuously rather than on a monthly cadence.
How does prioritized attack-surface data change incident response?
Prioritized attack-surface data changes incident response by replacing "search everything" with "check this specific list," which is the difference between hours and days when a new CVE breaks. When a MOVEit-scale disclosure happens, the first question every security team faces is "are we exposed, and where" — and the answer speed depends entirely on whether asset ownership, environment, and sensitivity were already tagged before the incident, not looked up during it. An inventory that already knows which workloads are production, which touch regulated data, and who owns each one lets a KEV addition or a new advisory route directly to the right engineer with the right urgency, rather than generating a mass email asking "does anyone run this software." That's the actual payoff of the methodology: not a prettier dashboard, but the ability to answer "are we affected" in minutes instead of days the next time a vendor's file-transfer server turns out to be everyone's problem.