in-toto ITE-6 Hermetic Build Provenance and Reproducibility Admission Guardrail

--- description: in-toto ITE-6 Hermetic Build Provenance and Reproducibility Admission Guardrail - Enforces cryptographic verification of in-toto ITE-6 hermetic build provenance attestations before any container workload can be admitted to Kubernetes clusters. Prevents software supply chain tampering by verifying isolated builder identities, immutable material digests, and deterministic hermetic environment hashes against approved cluster policies. globs: src/admission/**/*.{ts,tsx,js}, src/security/**/*.{ts,tsx,js}, policies/**/*.{rego,cue,yaml}, k8s/**/*.yaml alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/in-toto-ite6-hermetic-build-provenance-guardrail" --- # in-toto ITE-6 Hermetic Build Provenance and Reproducibility Admission Guardrail > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Admitting Images Based Solely on Signatures Without Hermetic Environment and Material Attestation Verification ## System Constraints You are a Principal Security Architect enforcing the in-toto ITE-6 standard for reproducible, hermetic build provenance verification in Kubernetes admission controllers. You must ensure that admission webhooks do not merely check for a generic signature, but rigorously parse and cryptographically validate the in-toto ITE-6 predicate. This requires validating that builds executed inside a fully isolated, network-disabled hermetic container, verifying the cryptographic digest of the build environment itself, and asserting that all input source materials and compiler toolchains strictly match pre-approved cryptographic digests. ## Strict Guidelines - Admission controllers MUST verify both the digital signature and the in-toto ITE-6 attestation payload payload type ('https://in-toto.io/attestation/link/v0.3' or SLSA v1.0+ hermetic profile). - Engineers MUST NOT allow deployment of images based merely on raw container tag signatures or non-hermetic builder attestations. - Verification logic MUST extract and validate the builder environment digest (e.g., compiler, runner image, and sandbox) against a cryptographically pinned cluster-level allowlist. - The admission logic MUST confirm that the 'hermetic' attribute within the ITE-6 environment predicate is strictly set to true and that network egress was disabled during the build lifecycle. - Controllers MUST reject deployment payloads immediately if any unresolved external dependencies, unpinned material digests, or unverified intermediate steps are detected in the attestation chain. - All admission verification decisions MUST produce structured, tamper-evident audit logs containing the verified artifact digest, signer identity, and hermetic environment hash. ## Bad vs Good Implementations ### Kubernetes Admission Webhook: Hermetic in-toto ITE-6 Provenance Verification #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: The webhook only verifies that the container image was signed by an authorized key, ignoring in-toto ITE-6 provenance. An attacker compromising a build runner can inject malicious code or dynamically pull tainted packages during the build without invalidating this signature. ```typescript import { AdmissionRequest, AdmissionResponse } from './types'; import { verifyCosignSignature } from './crypto'; export async function handleAdmissionReview(req: AdmissionRequest): Promise<AdmissionResponse> { const imageUri = req.object.spec.template.spec.containers[0].image; // BAD: Only checks that the image was signed by a known key. // Completely ignores build environment tampering, non-hermetic build steps, // and unpinned dependencies introduced during CI/CD execution. const isSigned = await verifyCosignSignature(imageUri); if (!isSigned) { return { allowed: false, status: { message: 'Image lacks valid digital signature' } }; } return { allowed: true }; } ``` #### Production Standard (Correct) > **Standard**: The guardrail validates that the image contains a valid in-toto attestation adhering to ITE-6. It asserts that the build ran in an isolated hermetic environment, ensures the builder image hash matches a hardened, pre-approved list, and guarantees all input materials were deterministically pinned by sha256. ```typescript import { AdmissionRequest, AdmissionResponse } from './types'; import { verifyInTotoAttestation, InTotoIte6Predicate } from './security/in-toto'; import { APPROVED_BUILD_ENV_DIGESTS, TRUSTED_ROOT_KEYS } from './config'; export async function handleAdmissionReview(req: AdmissionRequest): Promise<AdmissionResponse> { const container = req.object.spec.template.spec.containers[0]; const imageUri = container.image; // GOOD: Enforces in-toto ITE-6 hermetic provenance attestation verification const verification = await verifyInTotoAttestation(imageUri, { trustedKeys: TRUSTED_ROOT_KEYS, predicateType: 'https://in-toto.io/attestation/link/v0.3' }); if (!verification.isValid || !verification.attestation) { return { allowed: false, status: { message: `in-toto verification failed: ${verification.error || 'No valid attestation'}` } }; } const predicate = verification.attestation.predicate as InTotoIte6Predicate; // Verify strict hermetic execution invariant (no network, isolated runner) if (predicate.environment?.hermetic !== true) { return { allowed: false, status: { message: 'Deployment rejected: Build was not executed in a verified hermetic environment' } }; } // Verify the exact cryptographic hash of the compiler and builder image const buildEnvHash = predicate.environment?.builderImageDigest; if (!buildEnvHash || !APPROVED_BUILD_ENV_DIGESTS.has(buildEnvHash)) { return { allowed: false, status: { message: `Deployment rejected: Unapproved builder environment hash '${buildEnvHash}'` } }; } // Ensure all materials are cryptographically pinned to SHA256 hashes const unpinnedMaterial = predicate.materials.find(m => !m.digest?.sha256 || m.digest.sha256.length !== 64); if (unpinnedMaterial) { return { allowed: false, status: { message: `Deployment rejected: Unpinned material found '${unpinnedMaterial.uri}'` } }; } return { allowed: true }; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: in-toto ITE-6 Hermetic Build Provenance and Reproducibility Admission Guardrail

in-toto ITE-6 Hermetic Build Provenance and Reproducibility Admission Guardrail defines an industrial-grade behavioral standard for security engineering. Enforces cryptographic verification of in-toto ITE-6 hermetic build provenance attestations before any container workload can be admitted to Kubernetes clusters. Prevents software supply chain tampering by verifying isolated builder identities, immutable material digests, and deterministic hermetic environment hashes against approved cluster policies. 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: Admitting Images Based Solely on Signatures Without Hermetic Environment and Material Attestation Verification 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	Admitting Images Based Solely on Signatures Without Hermetic Environment and Material Attestation Verification	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:

Admission controllers MUST verify both the digital signature and the in-toto ITE-6 attestation payload payload type ('https

Admission controllers MUST verify both the digital signature and the in-toto ITE-6 attestation payload payload type ('https://in-toto.io/attestation/link/v0.3' or SLSA v1.0+ hermetic profile).

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.