In September 2024, a mid-size fintech company spent 11 days manually grepping through build logs to answer a simple question: "Do we run the vulnerable version of XZ Utils?" They didn't have an answer because they didn't have an inventory. A software bill of materials (SBOM) is that inventory — a structured, machine-readable list of every open-source library, container base image, and dependency baked into an application, along with its version and license. Without one, security teams are stuck reverse-engineering their own software during an active incident. With one, the same question takes seconds. As software supply chain attacks have moved from theoretical risk to routine headline — Log4Shell, the XZ Utils backdoor, SolarWinds — SBOMs have shifted from a compliance checkbox to operational necessity. This post breaks down what SBOMs actually contain, why they matter, and how tools like JFrog and Safeguard fit into generating and using them.
What Is a Software Bill of Materials?
A software bill of materials is a formal, machine-readable record of every component — direct and transitive — that makes up a piece of software, typically including the component name, version, supplier, and cryptographic hash. Think of it as an ingredient label for code: a single modern web application can pull in 150-500 open-source packages through transitive dependencies, and most engineering teams can name maybe a dozen of them from memory. The National Telecommunications and Information Administration (NTIA) formalized the "minimum elements" for an SBOM in July 2021, specifying seven required data fields: supplier name, component name, version, unique identifiers, dependency relationships, author of the SBOM data, and timestamp. An SBOM is not a one-time document — because dependencies update constantly, a useful SBOM is regenerated on every build and tied to the specific artifact it describes, not just the source repository.
Why Does SBOM Matter for Software Supply Chain Security?
SBOMs matter because they compress incident response time from weeks to minutes when a new vulnerability is disclosed in a widely-used library. The clearest illustration is Log4Shell (CVE-2021-44228), disclosed on December 9, 2021: Apache Log4j 2 was embedded — often several layers deep through transitive dependencies — in an estimated hundreds of thousands of Java applications across finance, retail, and government. Organizations without dependency inventories spent an average of several weeks scanning codebases and asking vendors "are you affected?" over email. A more recent example is the XZ Utils backdoor (CVE-2024-3094), discovered on March 29, 2024, when a Microsoft engineer noticed anomalous SSH login latency. The malicious code was hidden in liblzma versions 5.6.0 and 5.6.1 and could have compromised SSH authentication on a huge swath of Linux systems had it shipped in stable distributions. Teams with accurate, version-pinned SBOMs could query "do we have xz 5.6.0 or 5.6.1 anywhere" and get a definitive answer immediately, rather than guessing.
What Standards and Formats Do SBOMs Use?
The two dominant SBOM formats are SPDX and CycloneDX, and most enterprise tooling today supports both. SPDX (Software Package Data Exchange) originated at the Linux Foundation and became an ISO/IEC standard (ISO/IEC 5962:2021), with strong roots in license compliance reporting. CycloneDX, maintained under OWASP, was designed security-first and includes native support for vulnerability data (via VEX — Vulnerability Exploitability eXchange) and component-level risk scoring, which makes it the more common choice for security-focused pipelines. A third format, SWID tags (ISO/IEC 19770-2), is used mainly in software asset management contexts. The practical difference matters: an SBOM in SPDX format optimized for license audits may be missing the dependency-graph depth a security team needs to trace an exploit path, so organizations increasingly generate both — or a CycloneDX SBOM enriched with VEX statements — from the same build.
What Triggered the Push for Mandatory SBOMs?
The mandate came from the U.S. federal government after a catastrophic supply chain breach. The SolarWinds Orion compromise, disclosed in December 2020, saw attackers insert malicious code into a legitimate software update that reached roughly 18,000 organizations, including multiple federal agencies. In direct response, President Biden signed Executive Order 14028 on May 12, 2021, which required any software vendor selling to the U.S. federal government to provide a SBOM for their products. CISA has since taken over stewardship of SBOM guidance from NTIA, publishing updated minimum-element guidance and a 2024 framework for SBOM sharing and tooling maturity. The ripple effect has moved well beyond government contracts: Gartner has predicted that by 2025, a majority of software buyers globally would make SBOM provision a contractual requirement in vendor agreements, and regulated industries — banking, healthcare, critical infrastructure — are folding SBOM requirements into their own third-party risk assessments.
How Does JFrog Approach SBOM and Supply Chain Security?
JFrog addresses SBOMs primarily as an extension of its existing binary repository and artifact management platform, generating component inventories through JFrog Xray as artifacts move through Artifactory. This makes sense for organizations already standardized on JFrog for artifact storage, since SBOM data is a natural byproduct of the metadata Xray already collects during scanning. JFrog has also invested in package-level risk gating through JFrog Curation, launched in 2023, which blocks known-malicious or policy-violating open-source packages before they enter a build. The tradeoff for teams evaluating this approach is coupling: SBOM generation and supply chain visibility are tied closely to the Artifactory ecosystem, which is a heavier lift for organizations that use a mix of registries, build systems, or that want SBOM and provenance data as a standalone capability rather than a feature of their artifact repository. Teams with polyglot toolchains or multi-cloud build pipelines often need SBOM tooling that doesn't assume a single repository manager sits at the center of the pipeline.
How Does an SBOM Actually Get Used During an Incident?
An SBOM earns its value the moment a new CVE drops, by turning "which of our 200 applications are affected" into a query instead of a fire drill. When CVE-2024-3094 broke, the fastest-responding organizations queried their SBOM inventories for the exact package-version pair (xz-utils 5.6.0/5.6.1) across every production artifact and had a definitive affected/not-affected list within the hour. Contrast that with organizations still relying on spreadsheets or tribal knowledge, some of which took over a week to confirm they were clean — a delay that, for an actively-exploited vulnerability, is the difference between patching proactively and explaining a breach to a board. This is why SBOM value is inseparable from freshness and searchability: a PDF generated once at release time and stored in a compliance folder answers none of these questions during a live incident.
How Safeguard Helps
Safeguard treats the SBOM as a living security artifact rather than a compliance deliverable, generating a CycloneDX and SPDX-compatible SBOM automatically on every build across your CI/CD pipelines, container images, and infrastructure-as-code, without requiring you to standardize on a single artifact repository first. Every component is continuously matched against live vulnerability feeds and threat intelligence, so when a new CVE is disclosed — whether it's the next Log4Shell or the next XZ Utils — Safeguard can tell you within minutes exactly which services, containers, and deployed environments contain the affected version, down to the specific transitive dependency and build hash. Safeguard also attaches provenance and VEX data to each SBOM, so security teams aren't just seeing "you have package X," but whether the vulnerable code path is actually reachable and exploitable in your specific configuration, cutting down on alert fatigue from theoretical findings. For teams managing federal contracts or regulated-industry vendor requirements, Safeguard exports SBOMs in the NTIA minimum-elements format on demand, keeping audit and procurement responses fast instead of a scramble. And because Safeguard is built to sit across heterogeneous toolchains — multiple registries, multiple cloud providers, multiple build systems — it delivers a single, unified SBOM inventory instead of fragments scattered across whichever repository manager happens to own a given pipeline. The result is an SBOM program that functions the way the format was always meant to: as a real-time map of what's actually running in production, ready the moment you need it most.