What SLSA Level 4 Means for Container Builds
SLSA (Supply Chain Levels for Software Artifacts) is a framework for evaluating software supply chain security. Level 4 represents maximum security: hermetic builds isolated from external influence, complete provenance documentation, and cryptographic proof of build integrity.
CleanStart achieves SLSA Level 4 through hermetic build environments, provenance attestations, and reproducible container image generation. Every image is built with cryptographic guarantees of integrity and origin.
The following diagram illustrates the SLSA provenance chain from source code through deployment:
graph LR A["Source Code<br/>Repository<br/>git SHA"] -->|Commit<br/>Hash| B["Build<br/>Trigger"] B -->|Hermetic<br/>Isolation| C["Isolated<br/>Build<br/>Environment"] C -->|No Network| C1["No External<br/>Dependencies"] C -->|Explicit| C2["Declared<br/>Inputs Only"] C -->|Deterministic| C3["Same Source<br/>Same Binary"] C1 --> D["Generate<br/>Provenance<br/>Attestation"] C2 --> D C3 --> D D -->|SLSA Level 4| E["Signed<br/>Provenance<br/>Document"] E -->|Documents| F["Source<br/>Repository"] E -->|Documents| G["Build<br/>Environment"] E -->|Documents| H["Build<br/>Parameters"] E -->|Documents| I["Output<br/>Artifacts"] E -->|Cryptographic| J["Cosign<br/>Signature"] J -->|Attestation| K["Container<br/>Registry"] K -->|Deployment| L["Production<br/>Environment"] L -->|Verification| M["Verify<br/>Provenance<br/>Authenticity"] M -->|Success| N["Supply Chain<br/>Integrity<br/>Verified"] style C fill:#ccffcc style E fill:#99ccff style J fill:#ffff99 style N fill:#99ff99SLSA Framework Levels
Level | Requirements | Verification | Time to Implement |
|---|---|---|---|
1 | Build process exists | Source control history | Immediate |
2 | Hosted build service, version control | Signed build logs | 1-2 weeks |
3 | Hermetic builds, signed provenance | Cryptographic verification | 2-4 weeks |
4 | Fully isolated build, offline signing | Zero-trust verification | 4-8 weeks |
CleanStart achieves Level 4, the highest certification level.
Hermetic Builds: What Makes Them Secure
A hermetic build is completely isolated from external input except for the source code being compiled, explicitly declared dependencies, and build configuration parameters. No external network access occurs, no undeclared inputs are used, and no side effects corrupt the build.
Build Hermeticity Checklist
Hermetic Build Isolation requires network access restricted to declared registries only. Filesystem access must be limited to the build container. No privilege escalation can occur during the build. No hardcoded credentials or secrets are present. All dependencies must be explicitly declared. The output must be deterministic, meaning identical source code always produces the same binary.
Verification requires the build log to be signed and immutable. All inputs must be hashed and documented. A provenance attestation must be generated. Reproducibility must be verified. Zero undeclared dependencies must be found.
Example: Building in Hermetic Environment
# Build with hermeticity verificationcleanimg-init \ --build \ --image myapp:1.0.0 \ --slsa-level 4 \ --hermetic-verify \ --offline-sign # Output includes proof:# ✓ Hermetic build environment isolated# ✓ All network calls logged and verified# ✓ Provenance attestation generated (signed offline)# ✓ Build reproducible: same source → same binary hash# ✓ SLSA Level 4 certificationCleanStart SLSA Level 4 Implementation
Build Isolation
CleanStart uses Cloud Build with custom worker pools for hermetic execution:
# terraform/slsa-build-pool.tfresource "google_cloudbuild_worker_pool" "slsa_workers" { name = "slsa-hermetic-builders" worker_config { machine_type = "n2-standard-4" disk_size_gb = 100 no_external_ip = true # Isolated from internet }}Build runs in isolated network with no outbound Internet access, registry access through authenticated private mirror, all build steps executed in single isolated container, and no side-channel access to host system.
Provenance Attestation
Every build generates SLSA provenance attestation documenting what was built, how it was built, where it came from, and who built it.
The attestation includes source information showing exact repository, branch, and commit hash. It documents the builder with build tool version and configuration. It lists all direct and transitive dependencies with versions. It records the build steps and commands executed during build. It captures built artifacts with cryptographic hashes. It includes metadata showing timestamps and build environment identity.
Offline Signing
Provenance is signed offline using hardware security module (HSM):
# Build process:# 1. Generate unsigned provenance# 2. Sign with private key in HSM# 3. Produce signed attestation # Verification process:cosign verify-attestation gcr.io/apk-test-442304/myapp:1.0.0 \ --certificate-identity-regexp "https://github.com/company/myapp" \ --certificate-oidc-issuer "https://token.actions.githubusercontent.com" # Output shows:# ✓ Signature verified# ✓ Certificate issued by trusted OIDC provider# ✓ Subject matches repository# ✓ Attestation is provenance (not re-signed by third party)Reproducible Builds
SLSA Level 4 requires builds to be reproducible: same source produces same binary.
Reproducibility Verification
# Build twice from same sourcecleanimg-init --build --image myapp:1.0.0 --slsa-level 4docker inspect myapp:1.0.0 | jq '.[0].RootFS.Layers[0]'# Output: sha256:layer1abc123... # Build again from same commitgit checkout v1.0.0cleanimg-init --build --image myapp:1.0.0 --slsa-level 4docker inspect myapp:1.0.0 | jq '.[0].RootFS.Layers[0]'# Output: sha256:layer1abc123... ← IDENTICAL # Verify reproducibilityecho "Builds match: $?"# 0 = Success (reproducible)Reproducibility Challenges and Solutions
Challenge | Solution | Implementation |
|---|---|---|
Timestamps in files | Use build date from git |
|
Random UUIDs | Deterministic generation | Use git commit hash as seed |
Sorted dependencies | Explicit ordering |
|
File modification time | Normalize to commit time |
|
Environment variables | Declare explicitly |
|
CleanStart handles all reproducibility challenges automatically through deterministic Dockerfile construction that uses explicit build context, normalizes timestamps to build date, uses explicit dependency installation with sorted ordering, and builds with reproducible output flags.
Verifying SLSA Level 4 Claims
Check Provenance Signature
# Retrieve provenance from imagecosign verify-attestation \ gcr.io/apk-test-442304/myapp:1.0.0 \ --type slsaprovenance # Output shows complete provenance with valid signatureVerify Build Hermeticity
# Extract build metadata from provenancecosign verify-attestation gcr.io/apk-test-442304/myapp:1.0.0 \ --type slsaprovenance | jq '.predicate.buildDefinition' # Check for:# ✓ buildType: slsa/docker/v1 (standard SLSA type)# ✓ externalParameters: source, builder image (explicit)# ✓ resolvedDependencies: all with specific versions# ✗ No network calls outside registry (should be absent)Validate Reproducibility
# Get layer hashes from provenanceoriginal_digest=$(cosign verify-attestation myapp:1.0.0 \ --type slsaprovenance | jq -r '.predicate.byproducts[0].digest.sha256') # Rebuild and comparecleanimg-init --build --image myapp:1.0.0 --slsa-level 4rebuilt_digest=$(docker inspect myapp:1.0.0 | jq -r '.[0].RootFS.Layers[0]') # Verify match[ "$original_digest" = "$rebuilt_digest" ] && echo "REPRODUCIBLE" || echo "NOT REPRODUCIBLE"Integration with Supply Chain Verification
GitHub Actions SLSA Builder
CleanStart integrates with GitHub Actions for SLSA-compliant building:
name: SLSA Buildon: [push] jobs: build: runs-on: ubuntu-latest permissions: contents: read id-token: write steps: - uses: actions/checkout@v4 - name: Build and attest (SLSA Level 4) uses: cleanstart/build-attest@v2 with: image: myapp:${{ github.sha }} slsa-level: 4 hermetic: true offline-sign: true - name: Upload provenance uses: actions/upload-artifact@v3 with: name: provenance path: provenance.jsonVerification in Deployment
# Before deploying, verify SLSA provenancekubectl patch deployment myapp \ --patch "$(cat patch.yaml)" # Admission controller checks:# 1. Image has signed provenance attestation# 2. Provenance shows SLSA Level 4# 3. Signature chain valid# 4. Repository matches policy (company registry only) # If any check fails: reject deploymentCompliance and Certification
CISA Secure Software Development Framework
CleanStart SLSA Level 4 satisfies CISA SSDF practices including practice PO3.2 (build and publish artifacts in controlled environments), PO3.3 (secure the build pipeline), PS2.1 (use processes and tooling to prevent unauthorized code changes), and PS2.2 (use architecture and processes to protect artifact integrity).
FedRAMP SA Controls
SLSA Level 4 satisfies FedRAMP Security Assessment controls including SA-3 (System Development Life Cycle), SA-4 (Acquisition Process), and SA-8 (Security Engineering Principles).
Document compliance:
# Generate SLSA compliance reportcleanimg-init --image myapp:1.0.0 \ --slsa-verify \ --compliance fedramp \ --output compliance-report.json # Report shows:# - Each SLSA requirement and satisfaction level# - Mapping to FedRAMP controls# - Audit trail of all buildsTroubleshooting SLSA Level 4
Build Not Hermetic
If build requires network access:
# Identify undeclared dependenciescleanimg-init --build --image myapp:1.0.0 \ --hermetic-verify \ --verbose # Output shows network calls:# ERROR: Undeclared network access to npm-registry.example.com# FIX: Add to externalParameters.resolvedDependenciesReproducibility Check Fails
If rebuilds produce different hashes:
# Run with reproducibility modecleanimg-init --build --image myapp:1.0.0 \ --slsa-level 4 \ --reproducible-verify # Check for common issues:# - Timestamps in source files# - Random seed not declared# - Transitive dependencies missingProvenance Signature Invalid
If cosign verification fails:
# Check certificate chaincosign verify-attestation myapp:1.0.0 \ --type slsaprovenance \ --insecure-ignore-sct # Temporarily ignore SCT for debugging # Verify OIDC issuer is trusted# Contact CleanStart support with certificate chain detailsSee Also
Provenance Chaining: provenance-chaining.md — End-to-end traceability. Image Signing: image-signing-sigstore.md — Cryptographic signatures. In-Toto Attestation: in-toto-attestation.md — Software artifact verification.