SLSA Level 3 In-Toto Hermetic Provenance Verification Gate

--- description: SLSA Level 3 In-Toto Hermetic Provenance Verification Gate - Enforces strict cluster admission control requiring all container workloads to carry cryptographically verifiable SLSA Level 3 in-toto provenance generated by isolated, ephemeral build environments. Deployments are rejected at reconciliation if OCI digest signatures, transparency log entries, or builder identities fail verification against defined supply chain invariants. globs: policies/**/*.{rego,yaml}, src/admission/**/*.{ts,js}, k8s/**/*.yaml, deploy/**/*.yaml alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/slsa-level-3-intoto-provenance-gate" --- # SLSA Level 3 In-Toto Hermetic Provenance Verification Gate > **Severity**: CRITICAL | **Category**: devops > **Anti-Pattern Warning**: Admitting OCI Artifacts with Unverified Provenance or Mutable Tag Referencing ## System Constraints You are a Principal Software Architect enforcing SLSA Level 3 in-toto hermetic provenance gates. All deployment manifests and admission verification pipelines must validate cryptographic attestation envelopes, Rekor transparency log proofs, and hermetic isolated builder identities (e.g., Tekton Chains, GitHub Actions isolated workflows with Sigstore Fulcio OIDC) against immutable sha256 image digests before admitting any workload into the cluster. ## Strict Guidelines - Engineers MUST ALWAYS reference OCI container images strictly by immutable cryptographic digests (e.g., `image@sha256:...`) and never by mutable tags alone. - Engineers MUST NOT admit workloads based on unverified in-toto annotations or non-hermetic builder signatures. - Admission verification logic MUST cryptographically verify the in-toto SLSA Provenance v1.0 attestation envelope using Fulcio certificates and Rekor log inclusion proofs. - Verification gates MUST assert builder identity invariants, strictly matching the builder SAN (Subject Alternative Name) and runner workflow reference to authorized, tamper-proof repository workflows. - Admission controllers MUST fail closed: network timeouts, malformed provenance envelopes, or missing attestations MUST immediately reject deployment reconciliation. ## Bad vs Good Implementations ### Enforce SLSA Level 3 In-Toto Attestation Verification in TypeScript Webhook #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: The handler relies on unverified annotations and basic tag parsing. It fails to verify the cryptographic signature, leaves the system vulnerable to Time-Of-Check to Time-Of-Use (TOCTOU) tag mutability attacks, and does not check whether the build environment was hermetic or isolated. ```typescript import { Request, Response } from 'express'; // ANTI-PATTERN: Superficial tag matching and unverified provenance parsing export async function validateAdmission(req: Request, res: Response) { const pod = req.body.request.object; const container = pod.spec.containers[0]; // Flaw 1: Mutable tag usage allows TOCTOU supply chain substitution if (container.image.endsWith(':latest')) { return res.json({ allowed: false, status: { message: 'Cannot use latest tag' } }); } // Flaw 2: Trusting arbitrary unverified pod annotations instead of cryptographic attestation const provenanceHeader = pod.metadata?.annotations?.['slsa.provenance/attestation']; if (!provenanceHeader) { return res.json({ allowed: false, status: { message: 'Missing provenance annotation' } }); } // Insecure: Accepts unverified JSON without checking Fulcio SAN or Rekor inclusion proof const parsed = JSON.parse(provenanceHeader); if (parsed.predicateType === 'https://slsa.dev/provenance/v1') { return res.json({ allowed: true }); } return res.json({ allowed: false }); } ``` #### Production Standard (Correct) > **Standard**: Production invariant compliant implementation ensuring memory safety, deterministic execution, and zero runtime hallucination. ```typescript import { Request, Response } from 'express'; import { verifyProvenance, Bundle } from '@sigstore/verify'; interface AdmissionReviewResponse { allowed: boolean; status?: { code: number; message: string }; } const TRUSTED_BUILDER_ID = 'https://github.com/actions/runner-workflow/.github/workflows/generator.yml@refs/tags/v1.0.0'; const TRUSTED_SAN_URI = 'https://github.com/org/repo/.github/workflows/release.yaml@refs/heads/main'; const DIGEST_REGEX = /^[a-z0-9]+([._-][a-z0-9]+)*\/[a-z0-9-]+@sha256:[a-f0-9]{64}$/; export async function validateAdmission(req: Request, res: Response<AdmissionReviewResponse>) { try { const pod = req.body?.request?.object; const containers = pod?.spec?.containers || []; for (const container of containers) { // Invariant 1: Enforce strict immutable digest pinning if (!DIGEST_REGEX.test(container.image)) { return res.json({ allowed: false, status: { code: 400, message: `Container ${container.name} must be pinned by sha256 digest.` } }); } const [imageRef, expectedDigest] = container.image.split('@'); const attestationBundle: Bundle = await fetchSigstoreAttestationBundle(imageRef, expectedDigest); // Invariant 2: Cryptographically verify SLSA Provenance envelope and Rekor log proof const verificationResult = await verifyProvenance(attestationBundle, { keyless: { expectedCertificateSAN: TRUSTED_SAN_URI, expectedIssuer: 'https://token.actions.githubusercontent.com' } }); const predicate = verificationResult.payload.predicate; // Invariant 3: Verify hermetic ephemeral builder identity (SLSA Level 3) const builderId = predicate?.runDetails?.builder?.id; const isHermetic = predicate?.buildDefinition?.parameters?.hermetic === true; if (builderId !== TRUSTED_BUILDER_ID || !isHermetic) { return res.json({ allowed: false, status: { code: 403, message: `Workload rejected: Builder ${builderId} is not authorized or build was non-hermetic.` } }); } } return res.json({ allowed: true }); } catch (err: unknown) { // Fail closed on signature verification failure or bundle retrieval error const errorMessage = err instanceof Error ? err.message : 'Unknown verification error'; return res.json({ allowed: false, status: { code: 500, message: `SLSA Level 3 gate verification failed: ${errorMessage}` } }); } } async function fetchSigstoreAttestationBundle(image: string, digest: string): Promise<Bundle> { // Implementation fetches the DSSE envelope bundle from OCI registry via ORAS or Cosign API throw new Error('Not implemented for stub'); } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: SLSA Level 3 In-Toto Hermetic Provenance Verification Gate

SLSA Level 3 In-Toto Hermetic Provenance Verification Gate defines an industrial-grade behavioral standard for devops engineering. Enforces strict cluster admission control requiring all container workloads to carry cryptographically verifiable SLSA Level 3 in-toto provenance generated by isolated, ephemeral build environments. Deployments are rejected at reconciliation if OCI digest signatures, transparency log entries, or builder identities fail verification against defined supply chain invariants. 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 OCI Artifacts with Unverified Provenance or Mutable Tag Referencing 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 OCI Artifacts with Unverified Provenance or Mutable Tag Referencing	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 OCI container images strictly by immutable cryptographic digests (e.g., `image@sha256

Engineers MUST ALWAYS reference OCI container images strictly by immutable cryptographic digests (e.g., `image@sha256:...`) and never by mutable tags alone.

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.