SBOM and Software Supply Chain Security

An SBOM (Software Bill of Materials) is the machine-readable inventory of every component that makes up an application: libraries, transitive dependencies, licenses and versions. Without that inventory, software supply chain security is a blindfolded exercise: when a critical vulnerability appears in a dependency, how do you know how many of your products contain it if you never documented what you ship? This is not a theoretical concern. According to Verizon's 2025 DBIR, third-party involvement in breaches reached 30% of the total, double the previous year, while the average breach cost hit $4.44 million per IBM's report. Attacks on the software supply chain can compromise many victims through a single entry point.

From an offensive security perspective, the supply chain is an extremely high-yield target: compromising a popular library is equivalent to gaining access to thousands of organizations that integrate it without auditing it. This article explains what an SBOM is, how to generate and integrate it in your pipeline, and how it fits with SLSA, artifact signing and regulations such as NIS2 and DORA.

What an SBOM is and why it matters

An SBOM answers a deceptively simple question: what is actually inside this software? The answer is rarely trivial. A modern Node.js or Python application can pull in hundreds of transitive dependencies that the developer never consciously chose. Each one is attack surface. Each one can introduce a known vulnerability (CVE) or, worse, deliberately malicious code.

The SBOM captures that dependency tree in a structured, verifiable format. With it you can answer, in minutes rather than weeks, critical questions such as "are we affected by this CVE?" or "which products include this specific version of the compromised library?". That response capability is the difference between containing an incident in hours or discovering weeks later that you had been exposed the whole time.

The supply chain is not limited to third-party code. It includes container base images, compiled binaries, build system plugins and even the pipeline tools themselves. Any of those links can be the weak spot, as we analyze in more depth in our guide on software supply chain attacks.

Real-world cases that changed the rules

Three incidents illustrate why the industry stopped treating the SBOM as a luxury.

SolarWinds (2020). Attackers compromised the build process of the Orion platform and injected a backdoor (SUNBURST) into legitimately signed updates. Around 18,000 organizations received the trojanized update. The lesson was brutal: an artifact's signature guarantees nothing if the process that produces it is compromised. Signing malicious code merely turns it into signed malicious code.

XZ Utils / CVE-2024-3094 (2024). A backdoor with a CVSS score of 10 was introduced into the xz/liblzma compression library. Debian stable was not affected: the main exposure was in Debian unstable and Fedora 40 beta/Rawhide. The backdoor aimed to compromise SSH authentication and, conditionally, enable remote code execution in sshd. The most unsettling part was the method: an attacker under the alias "Jia Tan" spent almost two years contributing to the project legitimately until earning maintainer privileges, a meticulously planned long-term operation. Andres Freund, a Microsoft engineer, investigated it deliberately after observing anomalous CPU usage, elevated SSH latency and Valgrind errors.

Malicious dependencies in npm and PyPI. Public repositories face constant waves of malicious packages via typosquatting (names nearly identical to popular packages), dependency confusion and maintainer account hijacking. An SBOM alone does not stop you from installing one of these packages, but it does let you quickly detect its presence once an indicator of compromise is published.

In our red team engagements we frequently confirm that organizations cannot say with certainty which versions of which libraries they have in production. That blindness is precisely what an attacker exploits.

SBOM formats: CycloneDX and SPDX

There are two dominant standards, and it pays to understand their strengths to choose well.

CycloneDX

Developed under the OWASP umbrella, CycloneDX was born with an explicit security focus. Beyond the component inventory it supports VEX (Vulnerability Exploitability eXchange), which lets you declare whether a known vulnerability is actually exploitable in your context or whether the affected component is never invoked. It also models service relationships, dependencies and pedigree (a component's provenance and modifications). It is the preferred format when the primary goal is risk management and vulnerability response.

SPDX

SPDX (Software Package Data Exchange), standardized by the Linux Foundation and recognized as ISO/IEC 5962, is especially strong in license compliance, with a granular model for representing complex licensing. It is the natural choice when the focus is legal conformance and large-scale interoperability.

In practice, many tools generate both formats. The pragmatic recommendation: use CycloneDX if your priority is vulnerability response and SPDX if it is license compliance. And do not treat it as a mutually exclusive decision, because conversion between formats is feasible.

How to generate and integrate an SBOM in your pipeline

An SBOM that no one generates automatically or consumes is dead documentation. The value appears when it is produced on every build and feeds automated controls. These are the key steps.

1. Automatic generation during the build

Tools such as Syft (Anchore), Trivy or native CycloneDX support for Maven, npm or Gradle generate the SBOM from the real dependency tree during compilation. Timing matters: an SBOM generated after the build, against the final artifact (container image or binary), reflects what is actually deployed, not just what the manifest file declares.

# Generate an SBOM of a container image with Syft (CycloneDX JSON)
syft registry.example.com/api:1.4.2 -o cyclonedx-json > sbom.json

# Scan that SBOM against vulnerability databases with Grype
grype sbom:sbom.json --fail-on high

2. Software Composition Analysis (SCA) over the SBOM

The SBOM feeds software composition analysis (SCA), which cross-references it against vulnerability databases such as the NVD or CISA's KEV catalog. This is where the inventory turns into action: you can configure the pipeline to fail if an unpatched critical vulnerability appears. This logic complements SAST and DAST, as we explain in the OWASP Top 10 2025.

3. Centralized storage and querying

Storing the SBOM alongside the artifact (for example, as an attestation attached in the OCI registry) means that, when a new CVE lands, you can query all historical SBOMs and instantly know which versions are affected. Platforms such as OWASP Dependency-Track centralize this inventory and monitor it continuously.

4. Integration into pipeline hardening

SBOM generation is one more control within CI/CD pipeline hardening. It must run in a trusted build environment, with least privilege and no exposure of secrets, as we detail in CI/CD security and pipeline hardening.

SLSA and artifact signing with Sigstore

The SBOM says what is inside the software. It does not say where it comes from or whether the process that built it is trustworthy. That is where SLSA and Sigstore come in.

SLSA: verifiable provenance

SLSA (Supply-chain Levels for Software Artifacts) is a Linux Foundation framework that defines assurance levels for build process integrity. Its 1.2 version, published in 2025, mainly added the Source Track for reasoning about source code provenance. The core idea is to generate a signed attestation documenting how, where and from what each artifact was built. That way a consumer can verify that the binary came from a specific pipeline.

It is worth distinguishing the levels. SLSA Build L2 provides signed provenance via a hosted build platform, which raises the bar against the most common attack patterns on GitHub Actions or GitLab CI. L3 strengthens isolation between builds and protects provenance against untrusted build steps. That said, L3 presupposes a trusted build platform: it does not on its own cover a compromise of that platform, so it is not a guarantee against an attack on the build system itself of the SolarWinds kind. For most organizations, L2 is a realistic near-term goal and L3 the target to aim for in critical environments.

Sigstore: signing without managing keys

Sigstore, a Linux Foundation project backed by Google and Red Hat, solves the biggest pain of traditional signing: managing long-lived private keys. It offers keyless signing through short-lived certificates tied to OIDC identities. Its three pieces fit together like this:

• cosign: signs and verifies artifacts and containers.
• Fulcio: certificate authority that issues ephemeral certificates.
• Rekor: immutable transparency log that publicly records every signature.

Combined with SLSA provenance, Sigstore strengthens traceability from source code to deployed artifact. Keyless signing reduces the exposure of persistent private keys, one of the problems that classic key management drags on for years. Its limit is worth keeping in mind: a compromised OIDC or CI account can still obtain a certificate and sign, so Sigstore does not on its own guarantee that the software is correct nor does it replace identity controls. This connects with the discipline of managing machine secrets and credentials, a topic we cover in non-human identities and secrets management.

SBOM, SSDLC and its relationship with NIS2 and DORA

The SBOM is not an isolated artifact but a piece of the secure software development lifecycle (SSDLC). Integrating it early, at the build stage rather than as a later audit, is what makes it effective. An SBOM generated late documents the problem; one generated on every build helps prevent it.

On the European regulatory front, regulatory pressure has turned these practices into an expectation, if not an explicit obligation.

• Cyber Resilience Act (CRA). The European cyber resilience regulation incorporates an SBOM requirement for products with digital elements, with full enforcement expected around December 2027. It is, to date, the European regulation that mentions the SBOM most directly.

• NIS2. The directive does not name the SBOM literally, but it mandates risk-management outcomes (supply chain security, secure acquisition and development, vulnerability handling and asset management) that the SBOM is the natural way to evidence. If your organization is subject to NIS2, keeping an up-to-date component inventory is one of the most efficient ways to demonstrate due diligence. We cover the enforcement details in Spain in how to comply with NIS2 in Spain.

• DORA. In the financial sector, DORA focuses on ICT third-party risk. The SBOM provides the visibility into those providers' components that the regulation implies. We explain the boundary between both frameworks in DORA vs NIS2.

The conclusion from an offensive standpoint is straightforward: organizations that do not know what their products are made of cannot defend them or demonstrate compliance. The SBOM turns that uncertainty into an actionable inventory, and with SLSA and Sigstore on top, into a verifiable end-to-end chain of trust.

Frequently asked questions

What is the difference between CycloneDX and SPDX?

CycloneDX, maintained by OWASP, is geared toward security and vulnerability response (it includes VEX and risk modeling). SPDX, standardized by the Linux Foundation and ISO, excels at license compliance. Many tools generate both, so it is not a mutually exclusive choice: your use case's priority (risk or licenses) determines which one to use as primary.

Does an SBOM prevent supply chain attacks?

On its own it does not prevent them, but it is the foundation for responding to them. It drastically reduces response time to a new vulnerability by immediately telling you which products include the affected component. Combined with SCA, artifact signing (Sigstore) and provenance (SLSA), it does form part of an effective defense against these attacks.

Is an SBOM mandatory under NIS2?

NIS2 does not mention the SBOM explicitly, but it mandates supply chain security measures, vulnerability handling and asset management. The SBOM is the most efficient way to evidence those requirements. The Cyber Resilience Act does incorporate an SBOM requirement more directly for products with digital elements.

At what point in the pipeline should I generate the SBOM?

Ideally after the build, against the final artifact (container image or binary), so it reflects what is actually deployed and not only what the manifests declare. It should be generated automatically on every build, stored alongside the artifact, and feed SCA controls that can block deployments with critical vulnerabilities.

Secure your supply chain with Secra

At Secra we assess your software supply chain security from the attacker's perspective: we analyze dependencies, build processes, artifact signing and the real exposure of your pipeline. If you want to know what you actually ship to production and how an adversary could compromise it, contact our team or explore our secure development (SSDLC and DevSecOps) service.