SBOMs and SLSA: making the software supply chain verifiable

What they are

Modern applications are mostly assembled from open-source libraries, container base images and third-party services. Attacks on this software supply chain take several forms: a vulnerable library nobody knew was present, a malicious package published under a look-alike name, a compromised maintainer account, or a tampered build server that inserts code into otherwise legitimate releases.

Two complementary ideas address this:

• A Software Bill of Materials (SBOM) is an inventory: which components, which versions, from which supplier, with which identifiers and relationships. The two main formats are SPDX (an ISO/IEC standard, 5962) and CycloneDX (standardised by Ecma as ECMA-424).
• SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is an OpenSSF framework that defines increasing levels of assurance about how an artefact was produced, backed by signed provenance attestations.

Why it matters

When a critical vulnerability appears in a widely used library, the first question is "where do we use it?". Without SBOMs, organisations search manually for days. With SBOMs, the answer is a database query. Provenance, meanwhile, lets a consumer verify that a binary really came from the expected repository and build system, which defends against tampered builds and swapped packages. Supply chain failures are now significant enough that the OWASP Top 10:2025 gives them their own category, A03.

Key ideas

• SBOM minimum elements. In 2021 the US NTIA defined baseline data fields (supplier, component name, version, unique identifiers, dependency relationship, author and timestamp). In 2025 CISA published a draft update for comment that adds fields such as component hash, licence, tool name and generation context (for example, whether the SBOM was produced from source, at build time or from a binary), and distinguishes the SBOM author from the software producer.
• VEX (Vulnerability Exploitability eXchange) statements accompany SBOMs to say whether a known vulnerability actually affects the product, which reduces false alarms.
• SLSA Build levels. Build L1 means provenance exists; L2 means it is signed by a hosted build platform; L3 means the build platform is hardened so that builds cannot influence each other or forge provenance.
• Attestations use common formats (in-toto) and are often signed with keyless signing services, so consumers can verify them with standard tools.

What changed recently

• SLSA v1.1 (April 2025) clarified the threat model and verification process and remained compatible with v1.0.
• SLSA v1.2 (24 November 2025) added the Source track, covering threats in how code is written, reviewed and managed, such as unreviewed changes or tampered history. Work continues on tracks for build environments and dependencies.
• CISA SBOM minimum elements were proposed for update in 2025, reflecting improved tooling since 2021.
• EU Cyber Resilience Act (CRA). Manufacturers of products with digital elements sold in the EU must identify and document components, including drawing up an SBOM, as part of essential requirements that apply from December 2027. Duties to report actively exploited vulnerabilities and severe incidents started on 11 September 2026.

How practitioners apply it

1. Generate SBOMs in the pipeline at build time, for every release and container image, in SPDX or CycloneDX.
2. Store and query them in a dependency tracking platform that matches components against vulnerability feeds.
3. Ask suppliers for SBOMs and VEX in procurement, especially for network appliances and security tools.
4. Move builds to a hosted, isolated CI service that emits signed provenance (SLSA Build L2, then L3).
5. Verify before deploy. Admission controls in Kubernetes or deployment scripts can refuse artefacts without valid provenance from the expected repository.
6. Protect source. Enforce code review, branch protection and strong authentication for maintainers (see passkeys).

Tip: An SBOM generated from a container image after the fact often misses components. Build-time generation, using the real dependency resolution, is far more accurate.

For a student project, a good exercise is to take a small web application, generate an SBOM with an open-source tool, scan it for known vulnerabilities, then rebuild it in a hosted CI system that produces signed provenance and verify the signature locally. The whole loop takes an afternoon and covers most of the concepts in this article.

Limitations and open questions

• Quality varies widely. Different tools produce different SBOMs for the same software; naming and identifiers are inconsistent.
• SBOMs do not prevent attacks. They speed up response and support risk decisions, but a malicious component can appear in an SBOM like any other.
• Sharing at scale (how consumers receive, store and act on thousands of SBOMs) is still immature.
• Legacy and embedded software is hard to inventory, especially binary-only firmware.