On December 9, 2021, Apache disclosed CVE-2021-44228 — Log4Shell — a maximum-severity (CVSS 10.0) remote code execution flaw in Log4j that had been privately reported by Chen Zhaojun of Alibaba Cloud two weeks earlier. The vulnerability itself was patchable within a day. The problem most organizations actually had was different: they could not answer the question "which of our services run log4j-core, and where?" Security teams without a dependency inventory spent weeks running manual grep sweeps and asking every engineering team to self-report, while teams with an existing software bill of materials queried the same answer in minutes. That gap is not unique to Log4Shell. Gartner-cited research from IBM/Randori's State of Attack Surface Management found that only 17% of organizations can inventory 95% or more of their assets, just 9% monitor their full attack surface continuously, and 69% have been compromised through an asset they didn't know they had, had lost track of, or were managing poorly. Most AppSec programs buy a scanner before they build a map. This post makes the case for reversing that order — and for what a real code, cloud, container, and API inventory looks like in practice.
Why does asset inventory matter more than tool selection?
Asset inventory matters more than tool selection because a scanner can only cover what it's pointed at, and most organizations don't actually know the full list. A SAST tool wired into three known repositories is worthless against the fourth repository nobody registered. This is the core failure mode Gartner's Innovation Insight for Attack Surface Management research describes: attack surfaces grow continuously through cloud sprawl, M&A, contractor access, and shadow IT, while inventory practices stay static and manual. The IBM/Randori data quantifies the resulting exposure — under 10% of organizations have adopted dedicated attack-surface-assessment tooling at all, meaning most security teams are prioritizing based on an incomplete picture by default. Buying a better scanner doesn't fix a coverage problem; it just runs a better process against the wrong denominator. Inventory has to come first because every downstream AppSec decision — what to scan, how often, at what severity threshold — is a function of what you know exists, and teams consistently underestimate that number by a wide margin.
What counts as an asset in an AppSec inventory?
An AppSec-relevant inventory spans at least four categories: source code repositories, cloud resources, container images, and APIs, plus the ownership and sensitivity metadata that makes any of them prioritizable. Source repositories are the starting point — every Git provider, every fork, every archived-but-still-deployed branch. Cloud resources cover compute, storage, and managed services across every account and subscription, not just the ones a team remembers to list. Container images span every registry an org pushes to, since an image can outlive the repository that built it. APIs are the hardest category because they're often undocumented — a service can expose an internal endpoint years after the team that built it moves on. Industry frameworks converge on a fifth and sixth category worth tracking alongside these: third-party/SaaS dependencies and runtime workloads, since a vulnerability in a vendor's code or a workload nobody remembers is running reaches production the same way a first-party bug does. OWASP's asset-management guidance and Gartner's CAASM (Cyber Asset Attack Surface Management) category both treat ownership and environment tagging as required fields, not optional metadata — an asset with no owner is an asset nobody will patch.
What's the difference between CAASM and EASM?
CAASM and EASM are the two Gartner-named market categories for asset visibility, and the difference is where the discovery starts. CAASM — Cyber Asset Attack Surface Management — aggregates internal data sources you already have API access to: cloud provider APIs, Git provider APIs, container registries, CMDB records, and endpoint agents, then reconciles them into one queryable inventory. EASM — External Attack Surface Management — starts from the outside, discovering internet-facing assets the way an attacker would: DNS enumeration, certificate transparency logs, port scanning, and subdomain discovery, with no assumption of prior access or credentials. The two are complementary rather than competing: EASM is good at finding the forgotten subdomain or the staging environment someone left internet-facing; CAASM is good at telling you which internal repository and which team own it once found. A mature asset inventory program typically runs both, because an asset discovered externally still needs to be reconciled against internal ownership records before anyone can act on it.
How did SBOMs become a regulatory requirement, not just a best practice?
SBOMs became a regulatory anchor point through Executive Order 14028, signed in May 2021 in direct response to the SolarWinds and Colonial Pipeline incidents, which directed NIST and NTIA to define software supply-chain security requirements for federal contractors. NTIA published its "Minimum Elements for a Software Bill of Materials" later in 2021, specifying that an SBOM must include, at minimum, the supplier, component name, version, and dependency relationships for every piece of software — the baseline definition the industry still cites. CISA has since issued its own SBOM guidance building on that foundation. The practical effect is that any organization selling into the federal government, or into a supply chain that touches it, now has a compliance reason to maintain a live software inventory, not just a security one. That regulatory pressure is useful leverage for security teams: SBOM generation is one of the few asset-inventory investments that has an explicit federal mandate behind it, which makes it easier to fund than a general "asset visibility" initiative.
How should an asset inventory drive AppSec prioritization?
An asset inventory should drive prioritization by feeding two inputs into every triage decision: what is reachable from the internet or from untrusted input, and what the asset's ownership and sensitivity tags say about blast radius. A finding in a container image with no owner and unknown environment tagging is a research problem; the same CWE class in a repository tagged production, PCI-scoped, and owned by a named team is a ticket with an SLA. This is the practical alternative to the common failure mode of routing every scanner alert to a shared queue and triaging by CVSS score alone — a maximum-severity finding in a decommissioned staging asset is lower real risk than a medium-severity finding in a production payment path. Coverage metrics matter here too: tracking what percentage of running workloads have a fresh SBOM, what percentage of assets have an identified owner, and what percentage of third-party components are covered by vendor risk records gives a security team a trend line to manage against, instead of a one-time snapshot that goes stale the day after it's taken.
How Safeguard helps
Safeguard's asset discovery treats this as infrastructure rather than a report: it continuously catalogs seven asset classes — source repositories, container images, packages, AI models, SBOMs, vendors, and runtime workloads — through agentless integrations with Git providers and registries, lightweight collectors on Kubernetes and Linux hosts, and direct SBOM ingestion via the Portal, CLI, or API. Every discovered asset is stitched into a typed asset graph and assigned an owner, business unit, environment, and sensitivity tag, so a query like "which production workloads contain log4j-core 2.17.1" or "which vendors ship AI models with unsigned weights" returns an answer instead of requiring a fire drill. Assets that exist without governance — an unconnected repository, an image with no SBOM, a vendor API called from production but absent from TPRM records — surface as UNGOVERNED status on the Asset Discovery dashboard, and SBOM, vendor, and ownership coverage are tracked as time-series metrics rather than one-off audits. That's the asset-first foundation this post argues for: know what you have, own it, tag it, and only then decide what to scan and how urgently.