Compare

SLSA v1.0 vs SBOM: how they differ, side by side

How SLSA v1.0 and SBOM differ: what each is, who owes it, when it applies and who enforces it.

SLSA v1.0Voluntary framework
SBOMGuidance; binding only where a contract or sector rule requires it
Checked21 Oct 2026

01 / Side by side

SLSA v1.0 and SBOM, side by side

SLSA v1.0SBOM
What it istechnical specificationguidance
JurisdictionInternationalUnited States (federal)
Legal forceVoluntary frameworkGuidance; binding only where a contract or sector rule requires it
StatusSupersededPublished standard
Applies from19 Apr 202312 Jul 2021
Who owes itSoftware producers and build platform operators that want to show build integrity, and consumers verifying artifacts.Software producers selling to federal agencies or regulated buyers, and organizations that procure or operate software.
EnforcementNone; voluntary.No general penalty. Federal agencies may require SBOMs by contract (OMB M-26-05); other mandates come from sector rules and foreign law.

02 / SLSA v1.0

What SLSA v1.0 requires

Build provenance can apply to model training or packaging pipelines that produce AI artifacts, but SLSA does not address models or data specifically.

  1. 01Build L1: follow a consistent build process and generate and distribute provenance describing platform, process and top-level inputs.
  2. 02Build L2: run builds on a hosted build platform that signs the provenance.
  3. 03Build L3: use a hardened platform that isolates runs and keeps signing secrets from user-defined build steps.
  4. 04Consumers verify provenance against expected builder, source and parameters before use.

03 / SBOM

What SBOM requires

The 2026 baseline expressly covers AI software but adds no AI-specific fields; CISA and G7 partners issued separate AI SBOM minimum elements in May 2026 as a supplement.

  1. 01Produce SBOMs with the 17 minimum data fields, including component producer, version, identifiers, hash value and license.
  2. 02Record SBOM author, timestamp, tool name and version, and generation context (lifecycle phase).
  3. 03Sign the SBOM so recipients can confirm it is unaltered (SBOM Author Signature).
  4. 04Use machine-processable formats such as SPDX or CycloneDX and update the SBOM when components change.
  5. 05For federal cloud contracts with SBOM terms, provide an SBOM of the runtime production environment on request.

Optional evidence · where Planisphere fits

Keep a record anyone can check

When your team meets a duty, Planisphere can seal the event it reports as a receipt.

01 · Your teamRecord the event

A disclosure shown, a review signed, a model change approved: the event your system reports.

02 · PlanisphereSeal it

The event becomes a sealed receipt, dated and attributed to whoever is signed in.

03 · AnyoneCheck it

Paste the receipt into Verify. No account or key.

A record supports your compliance evidence process. It is not a legal finding or a certification. Systems that call Planisphere's gate API can also hold or refuse an action before it runs.

SOURCES

Go back to the source

PRIMARY
SLSA v1.0 Security levels

OpenSSF SLSA project

PRIMARY
SLSA v1.0 final announcement

OpenSSF SLSA project

PRIMARY
Announcing SLSA v1.2

OpenSSF SLSA project

PRIMARY
2026 Minimum Elements for a Software Bill of Materials (SBOM)

CISA, NSA, FBI and international partners (hosted by FBI IC3)

RELATED

Related: SLSA v1.0: the full guide · SBOM: the full guide · SBOM vs SLSA v1.0 · All comparisons