Abstract

Supply chain security has moved from a niche concern to a board-level risk since the SolarWinds incident in 2020 and the Log4Shell disclosures a year later. Supply-chain Levels for Software Artifacts (SLSA, pronounced “salsa”) is the framework that Google open-sourced in 2021 and that the OpenSSF has since shepherded into a well-defined v1.0 specification. SLSA defines four levels of build integrity assurance, each with concrete, verifiable requirements. Getting to even SLSA Level 2 in a typical CI/CD pipeline requires deliberate tooling choices, and this article works through what that actually means for a team already running GitHub Actions or GitLab CI.

What the Four Levels Actually Require

SLSA Level 1 simply demands that the build process is scripted and that a provenance document exists - a machine-readable attestation describing what source revision was built, on which platform, and by which workflow. The OpenSSF’s slsa-github-generator can emit this attestation as a signed DSSE envelope alongside any artifact published to a release or container registry. Level 2 adds the requirement that provenance is generated and signed by the build platform itself, not by developer-controlled scripts that could be tampered with after the fact. GitHub Actions generates OIDC tokens that the slsa-github-generator uses to sign provenance with Sigstore’s Fulcio CA, placing the signature in the public Rekor transparency log. This is the practical entry point for most teams. Levels 3 and 4 require hardened, isolated build environments - ephemeral VMs, hermetic builds with no network access, and hardware-attested build platforms - which are meaningfully harder to reach and currently best exemplified by Google’s own SLSA Level 4 infrastructure.

Verifying Provenance Downstream

Generating provenance is half the work. Verification must happen at consumption points: the container registry pull step, the Helm chart fetch, the dependency resolution. The slsa-verifier CLI from the SLSA project can check provenance on any artifact given its digest and expected source repository. For container images, cosign verify-attestation --type slsaprovenance checks the attestation stored in the registry’s referrers API (OCI 1.1). Policy enforcement belongs in admission controllers: Kyverno and OPA Gatekeeper both support policies that reject pod admission if the image’s provenance fails verification or is absent entirely. Writing that policy correctly requires pinning to image digests, not tags, because a tag can be silently repointed to a different digest with no audit trail.

Dependency Provenance and the SBOM Gap

SLSA addresses build provenance but does not itself solve the problem of knowing what is inside an artifact. That gap is filled by Software Bills of Materials (SBOMs) in SPDX or CycloneDX format, generated by tools like Syft or trivy’s SBOM mode. An artifact that carries both SLSA provenance and a signed SBOM gives consumers two complementary signals: the provenance proves the build was not tampered with; the SBOM enumerates the components inside so vulnerability scanners like Grype can match against the CVE database. The CISA Secure Software Development Attestation Form, required for software sold to US federal agencies, now expects both signals. Treating SLSA and SBOM generation as separate pipeline steps wired together by a signing and attestation layer is the pattern that scales across polyglot repositories.