Compare

SLSA v1.0 vs SSDF SP 800-218: how they differ, side by side

How SLSA v1.0 and SSDF SP 800-218 differ: what each is, who owes it, when it applies and who enforces it.

SLSA v1.0Voluntary framework

SSDF SP 800-218Voluntary framework; no government-wide attestation since Jan 2026

Checked21 Oct 2026

01 / Side by side

SLSA v1.0 and SSDF SP 800-218, side by side

	SLSA v1.0	SSDF SP 800-218
What it is	technical specification	federal standard
Jurisdiction	International	United States (federal)
Legal force	Voluntary framework	Voluntary framework; no government-wide attestation since Jan 2026
Status	Superseded	Published standard
Applies from	19 Apr 2023	3 Feb 2022
Who owes it	Software producers and build platform operators that want to show build integrity, and consumers verifying artifacts.	Software producers of all kinds, and in particular vendors whose software is used by US federal agencies.
Enforcement	None; voluntary.	None directly; voluntary. Agencies may require SSDF practices or an attestation by contract, and false contract representations can create False Claims Act exposure.

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.

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

03 / SSDF SP 800-218

What SSDF SP 800-218 requires

SP 800-218A (July 2024) is an SSDF community profile for generative AI and dual-use foundation models; it adds tasks such as protecting training data and model weights and tracking model provenance.

01Define security requirements, roles, training and toolchains for software development (PO).
02Protect code, releases and provenance data from tampering and unauthorized access (PS).
03Design securely, review and test code, and configure software secure by default (PW).
04Identify, analyze and fix vulnerabilities and their root causes after release (RV).
05Apply practices on a risk basis and document how each is met.

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