SLSA v1.0 Level 3 Hermetic Container Build & In-Toto Attestation Standard

--- description: SLSA v1.0 Level 3 Hermetic Container Build & In-Toto Attestation Standard - Enforces SLSA (Supply-chain Levels for Software Artifacts) v1.0 Level 3 compliance across all production container images. Mandates isolated, ephemeral build environments with strict network sandboxing during compilation and requires non-forgeable, cryptographically signed in-toto provenance generated by an authenticated build platform. globs: .github/workflows/**/*.{yml,yaml}, build/ci/**/*.{yml,yaml}, Dockerfile*, Containerfile*, scripts/build/**/*.{sh,ts} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/slsa-v1-level-3-hermetic-container-build-attestation" --- # SLSA v1.0 Level 3 Hermetic Container Build & In-Toto Attestation Standard > **Severity**: CRITICAL | **Category**: devops > **Anti-Pattern Warning**: Non-Hermetic Container Builds with Self-Generated, Mutable Provenance ## System Constraints You are a Principal Security Architect enforcing the SLSA v1.0 Level 3 Hermetic Container Build Attestation Standard. Every containerized artifact built for production must guarantee strict source-to-binary determinism. You must reject any CI/CD workflow, Dockerfile, or build script that executes external network calls during compilation phases, uses self-hosted untrusted runners without hardware attestation, or relies on self-signed provenance generated inside the build container itself. Require ephemeral runners, pinned dependency digests, isolated network phases (BuildKit network=none), and detached signing via OIDC-based ambient credentials into public/private Rekor and Fulcio transparency logs. ## Strict Guidelines - Engineers MUST ALWAYS isolate the compilation and build phases from external networks by pre-fetching dependencies into explicit, hash-pinned vendor stages and passing them via cache mounts or context. - Engineers MUST ALWAYS generate SLSA v1.0 provenance using a trusted, non-forgeable platform orchestrator (such as the SLSA GitHub Generator or Tekton Chains) rather than generating attestations inside the container build environment itself. - Engineers MUST NEVER execute raw `RUN curl`, `RUN wget`, or unpinned package installations (`npm install`, `go get`, `apt-get upgrade`) during container assembly; all external inputs must be pinned by immutable cryptographic content hashes (SHA-256). - CI/CD workflows MUST run build jobs in single-use, hardened ephemeral execution environments that are destroyed immediately after build completion to prevent state retention or cross-build contamination. - Attestations MUST use the standard in-toto statement specification wrapping SLSA v1.0 predicate (`https://slsa.dev/provenance/v1`), capturing buildDefinition, externalParameters, and resolvedDependencies with full cryptographic digest parity. ## Bad vs Good Implementations ### GitHub Actions Workflow: SLSA v1.0 Level 3 Hermetic Build vs Non-Compliant Ad-Hoc Build #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: The build runs on a long-lived self-hosted runner with live network egress, allows non-deterministic network downloads inside the build step, and self-generates/signs its own provenance within the build environment, violating SLSA L3 build isolation and non-forgeability invariants. ```yaml # INSECURE: Ad-hoc runner, unpinned network downloads, self-attested/forgeable provenance name: Insecure Release Build on: push: tags: ['v*'] jobs: build-and-push: runs-on: self-hosted steps: - uses: actions/checkout@v4 - name: Build Container run: | # Dockerfile runs network downloads at build time docker build -t ghcr.io/org/app:${{ github.ref_name }} . docker push ghcr.io/org/app:${{ github.ref_name }} - name: Self-Sign Image Inside Same Runner run: | # Anti-pattern: Build runner signs its own output; easily compromised if build script was poisoned cosign sign --key ${{ secrets.COSIGN_KEY }} ghcr.io/org/app:${{ github.ref_name }} # Self-minting provenance inside untrusted runner context cosign attest --key ${{ secrets.COSIGN_KEY }} --predicate ./provenance.json ghcr.io/org/app:${{ github.ref_name }} ``` #### Production Standard (Correct) > **Standard**: Adheres to SLSA v1.0 Level 3: network access is disabled during compilation (`--network=none`), runner security is audited, and provenance is minted by a separate, out-of-band trusted SLSA generator job using GitHub OIDC ambient credentials rather than being self-signed inside the build context. ```yaml # SECURE: SLSA v1.0 Level 3 Compliant Hermetic Build & Attestation Workflow name: SLSA L3 Container Pipeline on: push: tags: ['v*'] permissions: {} jobs: build: permissions: contents: read packages: write id-token: write runs-on: ubuntu-latest outputs: image-uri: ${{ steps.build.outputs.image-uri }} image-digest: ${{ steps.build.outputs.image-digest }} steps: - name: Harden Runner Security uses: step-security/harden-runner@v2 with: egress-policy: audit - uses: actions/checkout@v4 with: persist-credentials: false - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 - name: Build & Push by Digest (Isolated Network Phase) id: build uses: docker/build-push-action@v5 with: context: . push: true tags: ghcr.io/org/app:latest provenance: false # Provenance deferred to trusted out-of-band SLSA builder sbom: false extra-args: --network=none # Hermetic: compile without network connectivity # Dedicated, trusted generator job outside the build workload execution provenance: needs: [build] permissions: id-token: write packages: write actions: read uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected] with: image: ${{ needs.build.outputs.image-uri }} digest: ${{ needs.build.outputs.image-digest }} registry-username: ${{ github.actor }} secrets: registry-password: ${{ secrets.GITHUB_TOKEN }} ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: SLSA v1.0 Level 3 Hermetic Container Build & In-Toto Attestation Standard

SLSA v1.0 Level 3 Hermetic Container Build & In-Toto Attestation Standard defines an industrial-grade behavioral standard for devops engineering. Enforces SLSA (Supply-chain Levels for Software Artifacts) v1.0 Level 3 compliance across all production container images. Mandates isolated, ephemeral build environments with strict network sandboxing during compilation and requires non-forgeable, cryptographically signed in-toto provenance generated by an authenticated build platform. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Non-Hermetic Container Builds with Self-Generated, Mutable Provenance Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Non-Hermetic Container Builds with Self-Generated, Mutable Provenance	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS isolate the compilation and build phases from external networks by pre-fetching dependencies into explicit, hash-pinned vendor stages and passing them via cache mounts or context.

Engineers MUST ALWAYS isolate the compilation and build phases from external networks by pre-fetching dependencies into explicit, hash-pinned vendor stages and passing them via cache mounts or context.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.