On March 29, 2024, Andres Freund, a PostgreSQL developer at Microsoft, noticed SSH logins on a Debian sid box taking roughly 500 milliseconds instead of the usual 100. That anomaly led him to CVE-2024-3094, a backdoor deliberately planted in xz-utils 5.6.0 and 5.6.1 by a contributor using the handle "Jia Tan" after a multi-year social-engineering campaign to gain commit access. The flaw scored a 10.0 on CVSS and, had it shipped in stable Debian and Fedora releases instead of being caught in pre-release testing, would have handed attackers remote code execution on a huge share of internet-facing Linux servers. What makes the case useful for this post is that no single category of supply chain tool would have caught it: it wasn't a known CVE an SCA scanner could match, it shipped with a plausible-looking build process, and it was discovered by a human noticing latency, not a scanner. That gap is exactly why supply chain security tooling has fragmented into four distinct categories, each answering a different question. This post lays out that framework — SCA, SBOM generation, provenance/attestation, and registry/malware scanning — and how to think about which combination you actually need.
What does SCA actually check, and what does it miss?
Software Composition Analysis identifies the open-source components in your codebase and matches them against known-vulnerability databases — the National Vulnerability Database (NVD), OSV, and the GitHub Advisory Database are the three most commonly queried sources. Tools in this category include Snyk, Black Duck, Mend, Dependabot, Trivy, and Grype, and their core mechanic is the same across vendors: parse a manifest or lockfile, resolve the dependency tree, and flag any version range that intersects a published CVE. That mechanic is fast and cheap, which is why SCA became the default entry point for supply chain security over the last decade. But it only works against vulnerabilities that are already known and published. The xz-utils backdoor was invisible to SCA for months after it shipped, precisely because no CVE existed yet — CVE-2024-3094 was assigned only after Freund's manual discovery. SCA answers "is a component with a known flaw present," not "is this component safe."
What problem does SBOM generation solve that SCA doesn't?
An SBOM (Software Bill of Materials) solves the inventory problem: knowing exactly what's in your software before the next CVE drops, not scrambling to find out after. The two dominant machine-readable formats are SPDX, standardized by the Linux Foundation and published as ISO/IEC 5962:2021, and CycloneDX, maintained by OWASP. Executive Order 14028, signed May 12, 2021, made SBOM delivery a requirement for software vendors selling to the U.S. federal government, and NTIA's 2021 "minimum elements" guidance defined the baseline fields — supplier name, component name, version, and dependency relationships — that a compliant SBOM must include. Tools like Syft, cdxgen, and Microsoft's sbom-tool generate these documents directly from source trees, containers, or build artifacts. The distinction from SCA matters operationally: SCA is a point-in-time vulnerability report, while an SBOM is a durable, queryable inventory. When a new CVE lands, a team with current SBOMs across their estate can answer "are we affected, and where" by querying existing documents instead of re-scanning everything from scratch.
Why isn't knowing what's in a package enough — what does provenance add?
Provenance and attestation tooling answers a question neither SCA nor SBOMs can: was this artifact actually built the way it claims to have been, by whom, from what source? SLSA (Supply-chain Levels for Software Artifacts), which originated at Google and is now hosted by the OpenSSF, defines build-track levels 0 through 3 in its current v1.0 specification, each requiring stronger guarantees — from no formal requirements at Level 0, through provenance metadata at Level 1 and non-forgeable, platform-generated provenance at Level 2, up to hermetic, two-party-reviewed builds at Level 3. (An earlier draft of the spec described a fourth level requiring reproducible builds; that requirement was deferred rather than carried into the current standard.) Sigstore, an OpenSSF project that reached general availability in 2022, provides the machinery to make those claims verifiable: cosign for keyless artifact signing, Fulcio as a short-lived certificate authority tied to OIDC identity, and Rekor as a public, tamper-evident transparency log recording every signature. in-toto complements this with a layout format for defining and verifying each step of a multi-party build pipeline. The 2020 SolarWinds Orion compromise, where attackers inserted malicious code directly into a signed, trusted build pipeline, remains the standard reference case for why provenance verification exists as its own category separate from scanning finished artifacts for known flaws.
Why do registries need their own scanning category?
Registry and malware scanning exists because a growing share of supply chain attacks never touch a CVE database at all — they're malicious packages published directly to npm, PyPI, or crates.io, or dependency-confusion attacks that trick a build into pulling an attacker-controlled package instead of an internal one. Security researcher Alex Birsan demonstrated the dependency-confusion technique in 2021 by publishing packages matching internal library names used by more than 35 companies, including Apple, PayPal, and Microsoft, to public registries; internal build systems that resolved by version number rather than source pulled his public packages automatically, and the disclosure earned him over $130,000 in bug bounties. Vendors like Socket and Phylum built entire products around this gap, analyzing package behavior — install-time scripts, obfuscated code, unexpected network calls — rather than matching against a vulnerability list, because a brand-new malicious package by definition has no CVE yet. This is the category that would have had the best shot at catching something like the xz-utils backdoor's install-time build-script tampering, since it looks at behavior rather than known signatures.
How should a team choose between these categories?
The categories aren't substitutes for each other — Log4Shell (CVE-2021-44228, December 2021) is the case that made this concrete for most security teams, since organizations that had an SCA tool but no SBOM inventory spent days manually grepping repositories to find every place log4j-core was pulled in, transitively or directly. A team should map its actual risk before buying: SCA covers known-vulnerability exposure in dependencies you already use; SBOM generation covers inventory and compliance obligations, including federal procurement requirements under EO 14028; provenance and attestation covers build-integrity and tampering risk, which is the category most organizations still underinvest in; and registry scanning covers novel, unpublished malicious packages. Platforms are increasingly spanning more than one category rather than specializing — Safeguard's ESSCM module, for example, generates SPDX and CycloneDX SBOMs across 30-plus export formats and layers a proprietary Safeguard Component Attestation Level (SCAL, rated 0–5, with SCAL 0 meaning a fully verified reproducible build chain and SCAL 5 meaning unknown origin) on top, mapping explicitly to SLSA levels and verifying Sigstore, in-toto, and package-signature evidence. SCAL is a Safeguard-specific rating rather than an industry standard, but it illustrates the direction the market is moving: fewer point tools, more platforms that combine inventory, vulnerability matching, and provenance verification into one queryable system.