SLSA SBOM

Stefan Coetzeecreated 2026-05-12updated 2026-06-082 min readMOC
Vault note, not reviewed against the source. Written in the knowledge vault on 2026-05-12 by models working with Stefan Coetzee and published as it stands, with private addresses, e-mail addresses and an employer name redacted. Check claims against the primary source before relying on them.

SLSA + SBOM Cluster

Software supply chain integrity. SLSA (Supply-chain Levels for Software Artifacts) — Google-originated, OpenSSF-stewarded framework. SBOM (Software Bill of Materials) — formal inventory of components. Both increasingly required by CRA, NIS2, US Executive Orders, NIST guidance.

Anchors

Provenance

SLSA

  • Google-developed internally, then open-sourced ~2021.
  • OpenSSF (Open Source Security Foundation) stewardship since 2021.
  • SLSA v0.1 through SLSA v1.0 (2023) — current major version.

SBOM

  • Concept decades-old.
  • Executive Order 14028 (May 2021, US) — mandated SBOM for federal software.
  • NTIA Minimum Elements for SBOM (July 2021).
  • CISA SBOM work ongoing.
  • EU CRA requires component identification.

What SLSA is

Framework for software supply chain security with assurance levels (SLSA levels) and requirements:

  • Build integrity: how artifact was built.
  • Source integrity: where source came from.
  • Provenance: cryptographically signed metadata.

SLSA levels (SLSA v1.0)

Four levels:

  • L0: no requirements.
  • L1: provenance exists. Process documented.
  • L2: provenance authenticated. Build platform integrity.
  • L3: provenance non-forgeable. Hardened build platform. Strict isolation.

Higher levels = stronger guarantees.

What SBOM is

Machine-readable inventory of software components:

  • Component name + version.
  • Supplier.
  • Hash / identifier.
  • Relationships (dependencies).
  • License.
  • Other metadata.

SBOM formats

Three primary standards:

  • SPDX (Software Package Data Exchange) — Linux Foundation. ISO/IEC 5962.
  • CycloneDX — OWASP-stewarded.
  • SWID Tags — ISO/IEC 19770-2. Used in some federal contexts.

SPDX and CycloneDX dominant.

Detail in SLSA Levels and SBOM Formats.

Regulatory drivers

  • US EO 14028 (May 2021) — federal software SBOM.
  • EU CRA (2024) — vulnerability identification including components.
  • EU NIS2 (2022) — supply chain security.
  • US CMMC (2.0) — defense contractor supply chain.
  • Many sector regulations referencing SBOM.

Tooling ecosystem

SBOM generation

  • Syft (Anchore).
  • CycloneDX CLI.
  • SPDX tools.
  • Build-system integrations (Bazel, npm, pip, Cargo, Maven, Gradle).
  • Container scanners generating SBOMs.

SLSA implementation

  • Sigstore — code signing.
  • in-toto — supply chain attestation.
  • GitHub Actions provenance — automatic SLSA L2/L3 provenance.
  • Tekton Chains — Tekton SLSA support.

Why this matters

  • Regulatory pressure real and rising.
  • Supply chain attacks (SolarWinds, Kaseya, XZ Utils) demonstrate concrete risk.
  • AI model supply chain — emerging concern; ML-SBOM concept.
  • Cloud-native build practice increasingly SLSA-compatible.
  • CRA — product cybersecurity.
  • NIS2 — supply chain security.
  • ISO 27001 — A.5.21 ICT supply chain.

See also

SLSA SBOM Cluster (pillars MOC) · position · anchors · Cyber Resilience Act Cluster · NIS2 Cluster