Skip to main content
INS // Insights

Supply Chain Security: SLSA Framework for Federal Programs

Updated April 2026 · 7 min read

Software supply chain attacks have moved from theoretical to routine threat. NIST SP 800-161 Rev 1 (Cybersecurity Supply Chain Risk Management for Systems and Organizations) now provides the federal framework for addressing this threat category systematically. The SLSA (Supply-chain Levels for Software Artifacts) framework, developed collaboratively by Google, CNCF, and the open-source community, translates 800-161's risk management requirements into concrete, implementable build process controls.

Rutagon implements SLSA as a delivery standard across federal software programs, generating machine-verifiable provenance that satisfies both NIST 800-161 requirements and the emerging DoD software supply chain policy requirements.

Understanding SLSA Levels

SLSA defines four levels of supply chain integrity assurance:

| Level | What's Guaranteed | Key Requirements | |---|---|---| | SLSA 1 | Build process is documented | Provenance exists (unsigned) | | SLSA 2 | Build can be traced to source | Signed provenance, hosted build service | | SLSA 3 | Build can't be falsified | Hardened build environment, non-forged provenance | | SLSA 4 | Full provenance, no human intervention | Two-party review, hermetic builds |

For federal programs, SLSA 3 is the practical target — it provides non-forgeable provenance that survives adversarial scrutiny. SLSA 4 requires hermetic (fully reproducible, no network access during build) builds, which is achievable but requires significant pipeline investment.

SLSA 3 Implementation Architecture

Hardened Build Environment

SLSA 3 requires that the build environment be ephemeral and isolated — builds cannot inherit state from prior builds or access secrets beyond what's explicitly needed for the build:

# GitLab CI configuration — hardened SLSA 3 build environment
build-artifact:
  stage: build
  image: 
    name: registry1.dso.mil/ironbank/redhat/ubi/ubi9:9.3  # Iron Bank hardened base
    entrypoint: [""]
  
  variables:
    # Explicit network isolation — only allow pulls from approved registries
    FF_NETWORK_PER_BUILD: "true"
    DOCKER_NETWORK: "isolated"
    
  before_script:
    # Verify no secrets in environment from prior jobs
    - env | grep -v "^CI_" | grep -v "^GITLAB_" | sort
  
  script:
    - |
      # Capture build inputs for provenance
      BUILD_START=$(date -u +%Y-%m-%dT%H:%M:%SZ)
      SOURCE_COMMIT=$CI_COMMIT_SHA
      BUILDER_ID=$CI_RUNNER_ID
      
      # Actual build
      go build -ldflags="-s -w -buildid=" -trimpath ./...
      
      # Compute artifact digest
      ARTIFACT_DIGEST=$(sha256sum ./bin/mission-service | awk '{print $1}')
      
      # Emit build environment snapshot for provenance
      cat > build-snapshot.json <<EOF
      {
        "builderVersion": "$CI_SERVER_VERSION",
        "buildTriggeredBy": "$GITLAB_USER_LOGIN",
        "sourceRef": "$CI_COMMIT_REF_NAME",
        "sourceCommit": "$SOURCE_COMMIT",
        "buildStart": "$BUILD_START",
        "artifactDigest": "sha256:$ARTIFACT_DIGEST"
      }
      EOF
  
  artifacts:
    paths:
      - bin/
      - build-snapshot.json
    expire_in: 7 days

Provenance Generation and Signing

Provenance is a signed statement about how the artifact was built. Rutagon uses slsa-verifier and custom generators compatible with the SLSA provenance schema:

# provenance_generator.py — generates SLSA provenance document
import json
import hashlib
from datetime import datetime, timezone
from dataclasses import dataclass, asdict

@dataclass
class SlsaProvenanceSubject:
    name: str
    digest: dict  # {"sha256": "<hex>"}

@dataclass  
class SlsaBuilderDef:
    id: str

@dataclass
class SlsaBuildMetadata:
    invocationId: str
    startedOn: str
    finishedOn: str

@dataclass
class SlsaMaterial:
    uri: str
    digest: dict

def generate_slsa_provenance(
    artifact_path: str,
    source_uri: str, 
    source_digest: str,
    builder_id: str,
    invocation_id: str
) -> dict:
    """
    Generate SLSA v0.2 provenance document for an artifact.
    """
    # Compute artifact digest
    sha256 = hashlib.sha256()
    with open(artifact_path, 'rb') as f:
        for chunk in iter(lambda: f.read(8192), b''):
            sha256.update(chunk)
    artifact_digest = sha256.hexdigest()
    
    now = datetime.now(timezone.utc).isoformat()
    
    return {
        "_type": "https://in-toto.io/Statement/v0.1",
        "predicateType": "https://slsa.dev/provenance/v0.2",
        "subject": [
            {
                "name": artifact_path.split('/')[-1],
                "digest": {"sha256": artifact_digest}
            }
        ],
        "predicate": {
            "builder": {"id": builder_id},
            "buildType": "https://gitlab.com/Rutagon/pipeline/v1",
            "invocation": {
                "configSource": {
                    "uri": source_uri,
                    "digest": {"sha1": source_digest},
                    "entryPoint": ".gitlab-ci.yml"
                }
            },
            "metadata": {
                "buildInvocationId": invocation_id,
                "completeness": {
                    "parameters": True,
                    "environment": True,
                    "materials": True
                }
            },
            "materials": [
                {
                    "uri": source_uri,
                    "digest": {"sha1": source_digest}
                }
            ]
        }
    }

Provenance Signing with Cosign

The provenance document is signed using Cosign (integrating with the container image signing pipeline):

# Sign provenance document
cosign attest \
  --predicate provenance.json \
  --type slsaprovenance \
  --key $SIGNING_KEY \
  $REGISTRY/$IMAGE:$DIGEST

# Verify at deployment time
cosign verify-attestation \
  --type slsaprovenance \
  --key $VERIFICATION_KEY \
  $REGISTRY/$IMAGE:$DIGEST

The signed provenance is stored in the OCI registry alongside the artifact — content-addressable and accessible to any downstream system that needs to verify build integrity.

Dependency Supply Chain (SBOM Integration)

SLSA addresses build process integrity. SBOM (Software Bill of Materials) addresses the dependency supply chain — knowing exactly what open-source components are incorporated and their vulnerability status.

Rutagon generates SPDX-format SBOMs at build time using syft and attaches them as signed attestations:

# Generate SBOM
syft $REGISTRY/$IMAGE:$TAG -o spdx-json > sbom.json

# Attach SBOM as signed attestation
cosign attest \
  --predicate sbom.json \
  --type spdxjson \
  --key $SIGNING_KEY \
  $REGISTRY/$IMAGE:$TAG

# Scan SBOM for vulnerabilities
grype sbom:sbom.json --output sarif > vuln-results.sarif

The SBOM attestation enables downstream programs to audit dependencies without access to source code — a key requirement for prime-sub delivery chains where the prime needs to verify the sub's software supply chain posture.

NIST 800-161 Control Coverage

| 800-161 Control | SLSA Implementation | |---|---| | SR-3 (Supply Chain Controls) | Provenance attestations demonstrate build controls | | SR-4 (Provenance) | SLSA provenance documents artifact origins | | SR-11 (Component Authenticity) | Container image signing (Cosign) | | SI-7 (Software Integrity) | Admission controller enforcement of signed artifacts | | SA-12 (Supply Chain Risk) | SBOM + vulnerability scanning at build time |

These controls are documented in the SSP with links to the actual provenance artifacts — providing auditors with machine-verifiable evidence rather than policy assertions.

SLSA implementation is most valuable when integrated into an end-to-end DevSecOps pipeline rather than added as a standalone check. Rutagon delivers this as part of the full managed DevSecOps pipeline — SLSA provenance, container signing, SBOM generation, and ATO evidence collection in a single delivery package.

Discuss supply chain security for your program →

Frequently Asked Questions

What SLSA level should DoD software programs target?

SLSA 3 is the practical target for most DoD software programs — it provides non-forgeable provenance and hardened build environments that satisfy current DoD software supply chain policy requirements. SLSA 4 (hermetic builds, two-party review) is achievable but requires significant pipeline investment; programs should evaluate the cost-benefit against their threat model and ATO requirements.

How does SLSA provenance differ from a standard build log?

Standard build logs are self-referential — the build system reports its own behavior, which provides weak integrity guarantees if the build system is compromised. SLSA provenance is signed by the build infrastructure using keys controlled separately from the build process itself, making it cryptographically verifiable by parties without access to the build system. This separation of signing authority from build execution is what makes SLSA attestations meaningful to auditors.

Does SLSA satisfy DoD CMMC supply chain requirements?

SLSA directly addresses NIST 800-161 requirements that map to CMMC's supply chain risk management practice area. Specifically, SLSA 3 provenance satisfies aspects of practices related to ensuring software integrity and managing software supply chain risk. For full CMMC compliance, SLSA is one component of a broader supply chain risk management program.

How are SLSA attestations stored and accessed?

Rutagon stores SLSA provenance and SBOM attestations in the OCI container registry alongside the artifact they describe — they're discoverable via the same registry APIs used to pull images. This co-location means any system pulling a container image can also retrieve and verify its provenance without additional infrastructure. For programs with air-gapped registries, the attestations travel with images during registry mirroring operations.

Can SLSA be applied to binary artifacts beyond containers?

Yes. SLSA provenance can be applied to any software artifact — executables, libraries, infrastructure templates, deployment packages. The signing mechanism (Cosign or equivalent) supports generic binary artifacts through the cosign sign-blob command. For programs delivering Terraform modules, Helm charts, or compiled Go binaries to primes, provenance attestations on these artifacts satisfy the same supply chain integrity requirements as container signing.