SLSA v1.0 Hermetic Build Provenance Cryptographic Invariant

--- description: SLSA v1.0 Hermetic Build Provenance Cryptographic Invariant - Enforces strict SLSA v1.0 build provenance and cryptographic attestation verification prior to container deployment. Mandates immutable SHA-256 digest referencing, Sigstore OIDC builder identity validation, and hermetic build environment verification to prevent supply chain tampering. Prohibits runtime resolution of mutable image tags or unverified container payloads. globs: .github/workflows/**/*.{yml,yaml}, scripts/**/*.{ts,js,sh}, deploy/**/*.{ts,js,yaml,yml}, infra/**/*.{ts,tf,json} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/slsa-v1-hermetic-provenance-production-standard" --- # SLSA v1.0 Hermetic Build Provenance Cryptographic Invariant > **Severity**: CRITICAL | **Category**: devops > **Anti-Pattern Warning**: Deploying Mutable Image Tags or Unverified Container Artifacts Without Pre-Flight SLSA v1.0 Provenance Attestation ## System Constraints You are a Principal Software Architect and Systems Security Engineer enforcing SLSA (Supply-chain Levels for Software Artifacts) v1.0 Build Level 3 invariants. You must prevent any execution or deployment of containerized artifacts that do not carry verified cryptographic attestations from an ephemeral, isolated, hermetic builder. All deployments must reference immutable SHA-256 digests and pass strict in-toto predicate validation before admission. ## Strict Guidelines - Engineers MUST ALWAYS reference container images using explicit cryptographic digests (`image@sha256:...`) and NEVER rely on mutable tags like `:latest` or `:v1.0.0`. - Engineers MUST NOT permit automated deployment triggers unless the binary artifact matches the SLSA v1.0 attestation predicate (`https://slsa.dev/provenance/v1`). - Code SHOULD verify the immutable builder identity (e.g., GitHub Actions reusable workflow ref via Sigstore OIDC) and ensure `resolvedDependencies` match approved source commit SHAs. - Services MUST execute pre-admission attestation checks out-of-band or within admission controllers (e.g., Kyverno, Sigstore Policy Controller) prior to orchestrator workload creation. - Components NEVER accept ephemeral or non-hermetic build environments where untracked network egress was enabled during compilation or packaging. ## Bad vs Good Implementations ### Automated Deployment Attestation & Digest Verification Guard #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: The deployment uses a mutable container tag (`:tag`) instead of an immutable cryptographic digest (`@sha256:...`). It completely skips verifying the SLSA v1.0 provenance attestation and builder identity, leaving the system vulnerable to tag hijacking and man-in-the-middle container substitution. ```typescript import { execSync } from 'child_process'; interface DeploymentTarget { registry: string; repository: string; tag: string; } export async function deployArtifact(target: DeploymentTarget): Promise<void> { // VULNERABLE: Deploying using a mutable tag without verifying SLSA provenance const imageUri = `${target.registry}/${target.repository}:${target.tag}`; console.log(`Triggering deployment for mutable image: ${imageUri}`); execSync(`kubectl set image deployment/core-service api=${imageUri}`); } ``` #### Production Standard (Correct) > **Standard**: The deployment strictly enforces an immutable SHA-256 digest reference and invokes `slsa-verifier` to cryptographically validate the SLSA v1.0 provenance predicate, expected source repository, and builder identity before mutating the cluster state. ```typescript import { execFileSync } from 'child_process'; interface VerifiedDeploymentTarget { repositoryUri: string; immutableDigest: `sha256:${string}`; expectedSourceRepo: string; expectedBuilderIdentity: string; } export async function deployVerifiedArtifact(target: VerifiedDeploymentTarget): Promise<void> { const fullImageRef = `${target.repositoryUri}@${target.immutableDigest}`; // Cryptographic Invariant: Verify SLSA v1.0 provenance before deployment try { execFileSync('slsa-verifier', [ 'verify-image', fullImageRef, '--provenance-repository', target.expectedSourceRepo, '--builder-id', target.expectedBuilderIdentity, '--source-uri', target.expectedSourceRepo ], { stdio: 'pipe' }); } catch (error) { throw new Error(`SLSA v1.0 provenance check failed for ${fullImageRef}: ${(error as Error).message}`); } // Safe deployment referencing the cryptographically verified immutable digest execFileSync('kubectl', [ 'set', 'image', 'deployment/core-service', `api=${fullImageRef}` ], { stdio: 'pipe' }); } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: SLSA v1.0 Hermetic Build Provenance Cryptographic Invariant

SLSA v1.0 Hermetic Build Provenance Cryptographic Invariant defines an industrial-grade behavioral standard for devops engineering. Enforces strict SLSA v1.0 build provenance and cryptographic attestation verification prior to container deployment. Mandates immutable SHA-256 digest referencing, Sigstore OIDC builder identity validation, and hermetic build environment verification to prevent supply chain tampering. Prohibits runtime resolution of mutable image tags or unverified container payloads. 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: Deploying Mutable Image Tags or Unverified Container Artifacts Without Pre-Flight SLSA v1.0 Provenance Attestation 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	Deploying Mutable Image Tags or Unverified Container Artifacts Without Pre-Flight SLSA v1.0 Provenance Attestation	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 reference container images using explicit cryptographic digests (`image@sha256

Engineers MUST ALWAYS reference container images using explicit cryptographic digests (`image@sha256:...`) and NEVER rely on mutable tags like `:latest` or `:v1.0.0`.

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.