How the v0.3.0 release pipeline maps to NIST and SLSA

If you have to explain our release pipeline to a security reviewer, start here. This page does two jobs: how each stage lines up with NIST SP 800-204C and 800-204D, and how the pipeline lines up with SLSA.

DRAFT for v0.3.0, not published and never merged before v0.3.0 is live.

How we line up with NIST

We used two documents: SP 800-204C (Implementation of DevSecOps for a Microservices-based Application with Service Mesh), mainly sections 3.3, 4.6 and 4.8, and SP 800-204D (Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines), mainly sections 5.1.1 and 5.2. Both also cover running services in your own cluster; that is your environment, so the table covers our release pipeline only.

The stages are described step by step on how we build. "Signs" means the stage records what it did and signs it with a short-lived key, under its own workflow identity, logged in a public transparency log.

Stage	What it does	NIST practice	How much
Build	Checks that the tag is signed, then builds the binaries and both images once. The image is assembled from those packages, with no base image.	800-204D 5.1.1 "Secure Build"; 800-204C 3.3.3 (SBOM generation and code signing as pipeline tasks)	Matches the practice as we read it.
Sign	A separate stage records the build and signs it under its own identity, from the build's digest list only.	800-204D 5.1.1 (signing outside the build steps); 800-204C 4.6 (signing during each required stage)	Partly. 4.6 prefers multi-party signing; every signature here is made by automation in one repository.
Rebuild	Assembles the image again, independently, on a separate machine. The digests must match or the release fails.	No direct match in either document.	Not mapped. It repeats the image assembly; it does not rebuild the binaries from source.
Check	Scans and acceptance tests run against the exact candidate images, and the stage signs a verdict for those digests.	800-204C 4.8 and 800-204D 5.2	Partly. The pipeline runs no static or dynamic application security testing itself, and the signed verdict records a pass, not the full scan report.
Release	Verifies every stage's signature together, then publishes the same digests.	800-204C 4.6 (verify that all required signatures are present); 800-204D 5.1.1 (policy checks that the required attestations are found) and 5.2 DEPLOY-REQ-3	Partly. The policy is code in the workflow file, not a separate signed policy document as 5.1.1 describes.

In one line: signed at every stage, verified together at release.

How we line up with SLSA

SLSA is a public scale for how far you can trust the way software was built. Its Build track runs from Level 0 to Level 3. We assess v0.3.0 at Build Level 3.

Level 3 asks that the build runs on a hosted platform and that its provenance, the signed record of how the build ran, cannot be forged by the build itself. Here, the Build stage runs on a hosted CI platform and does not hold the signing identity. The Sign stage receives only the build's digest list, records the build and signs it under its own identity. The Release stage accepts a build only if that signature verifies. You can check this yourself: see verify a release yourself.