In-Toto v1.0 & CycloneDX 1.6 Cryptographic Build Reproducibility Verification

--- description: In-Toto v1.0 & CycloneDX 1.6 Cryptographic Build Reproducibility Verification - Enforces strict bit-for-bit determinism validation across independent isolated build workers before publishing compiled artifacts to registries. Requires mutual cross-verification of CycloneDX 1.6 Cryptographic Bill of Materials (CBOM/SBOM) digests against signed in-toto v1.0 attestation envelopes containing hardware-rooted enclave measurements. globs: scripts/verify-build/**/*.{ts,js}, src/release/**/*.{ts,js}, src/pipeline/**/*.{ts,js}, build/attestation/**/*.{ts,js} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/in-toto-cyclonedx-reproducible-build-attestation" --- # In-Toto v1.0 & CycloneDX 1.6 Cryptographic Build Reproducibility Verification > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Publishing Binaries Lacking Multi-Worker Determinism Consensus or Signed Hardware Attestation Envelopes ## System Constraints You are a Principal Engineer and Security Architect enforcing in-toto v1.0 and CycloneDX 1.6 cryptographic build verification standards. You mandate that no binary or compiled artifact may be promoted to staging or production registries without bit-for-bit consensus across independent rebuilders, corroborated by signed DSSE in-toto v1.0 envelopes and CycloneDX 1.6 hashes tied to hardware root-of-trust measurements (TPM 2.0 / Nitro / SGX). Reject unverified builds and flag non-deterministic toolchains. ## Strict Guidelines - Engineers MUST compute bit-for-bit cryptographic hashes (SHA-256 and BLAKE3) of build artifacts across at least two isolated, independent rebuilders prior to registry promotion. - Engineers MUST NOT allow promotion of any artifact whose byte stream fails byte-for-byte consensus across independent rebuild runs. - Code MUST validate CycloneDX 1.6 SBOM artifact component hashes against in-toto v1.0 subject digests inside a Dead Simple Signing Envelope (DSSE). - Services MUST verify hardware attestation quotes (e.g., TPM 2.0 PCR values, AWS Nitro Enclave attestation documents) embedded in the in-toto v1.0 predicate before trusting build metadata. - Components NEVER execute registry upload commands (e.g., OCI push, npm publish) if any signature, hash verification, or reproducibility check fails. ## Bad vs Good Implementations ### Build Promotion Consensus and Attestation Verification #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: The code blindly publishes an artifact from a single build run. It lacks bit-for-bit multi-worker reproducibility checks, ignores in-toto v1.0 DSSE attestation, does not validate CycloneDX 1.6 cryptographic hashes, and leaves the supply chain vulnerable to compromised build workers. ```typescript import { execSync } from 'node:child_process'; import * as fs from 'node:fs'; interface PromotionRequest { artifactPath: string; registryUrl: string; } export async function promoteBuild(request: PromotionRequest): Promise<void> { // Flaw: Single-build reliance without deterministic consensus verification // Flaw: Unauthenticated and unsigned SBOM, no in-toto attestation envelope if (!fs.existsSync(request.artifactPath)) { throw new Error('Artifact missing'); } console.log(`Pushing artifact directly to ${request.registryUrl}...`); execSync(`crane push ${request.artifactPath} ${request.registryUrl}`); } ``` #### Production Standard (Correct) > **Standard**: The production-grade code enforces bit-for-bit deterministic consensus across build workers using timing-safe comparisons, validates the DSSE Pre-Authentication Encoding (PAE) against an authorized key, and verifies that the in-toto v1.0 statement subject and CycloneDX 1.6 metadata match the exact computed hash. ```typescript import * as crypto from 'node:crypto'; import * as fs from 'node:fs'; export interface AttestationPayload { _type: 'https://in-toto.io/Statement/v1'; subject: Array<{ name: string; digest: Record<string, string> }>; predicateType: 'https://cyclonedx.org/bom/v1.6'; predicate: { bomFormat: 'CycloneDX'; specVersion: '1.6'; components: Array<{ name: string; hashes: Array<{ alg: string; content: string }> }>; attestation?: { hardwareQuote?: string }; }; } export interface DsseEnvelope { payloadType: string; payload: string; // Base64-encoded AttestationPayload signatures: Array<{ keyid: string; sig: string }>; } export interface VerificationContext { primaryArtifactPath: string; reproducedArtifactPath: string; envelopePath: string; trustedVerificationKey: crypto.KeyObject; } export async function verifyReproducibilityAndAttestation( ctx: VerificationContext ): Promise<void> { const primaryBytes = await fs.promises.readFile(ctx.primaryArtifactPath); const reproducedBytes = await fs.promises.readFile(ctx.reproducedArtifactPath); // Invariant 1: Bit-for-bit multi-worker deterministic consensus if (primaryBytes.length !== reproducedBytes.length || !crypto.timingSafeEqual(primaryBytes, reproducedBytes)) { throw new SecurityError('Build determinism failure: Primary and reproduced outputs diverge'); } const computedSha256 = crypto.createHash('sha256').update(primaryBytes).digest('hex'); const rawEnvelope = await fs.promises.readFile(ctx.envelopePath, 'utf-8'); const dsse: DsseEnvelope = JSON.parse(rawEnvelope); if (dsse.payloadType !== 'application/vnd.in-toto+json') { throw new SecurityError(`Invalid DSSE payloadType: ${dsse.payloadType}`); } // Invariant 2: DSSE cryptographic envelope verification (in-toto v1.0) const paeBuffer = Buffer.concat([ Buffer.from(`DSSEv1 ${dsse.payloadType.length} ${dsse.payloadType} `), Buffer.from(`${Buffer.from(dsse.payload, 'base64').length} `), Buffer.from(dsse.payload, 'base64') ]); const isSignatureValid = dsse.signatures.some(sig => crypto.verify('sha256', paeBuffer, ctx.trustedVerificationKey, Buffer.from(sig.sig, 'base64')) ); if (!isSignatureValid) { throw new SecurityError('in-toto DSSE signature validation failed: Untrusted hardware signature'); } // Invariant 3: CycloneDX 1.6 CBOM component hash alignment with in-toto subject const statement: AttestationPayload = JSON.parse(Buffer.from(dsse.payload, 'base64').toString('utf-8')); const subjectEntry = statement.subject.find(s => s.digest.sha256 === computedSha256); if (!subjectEntry) { throw new SecurityError('Subject digest in in-toto attestation does not match computed consensus digest'); } const cdxValid = statement.predicate.components.some(comp => comp.hashes.some(h => h.alg.toUpperCase() === 'SHA-256' && h.content === computedSha256) ); if (!cdxValid) { throw new SecurityError('CycloneDX 1.6 component manifest does not contain matching cryptographic hash'); } } export class SecurityError extends Error { constructor(message: string) { super(`[CRITICAL_SECURITY_GUARDRAIL] ${message}`); this.name = 'SecurityError'; } } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: In-Toto v1.0 & CycloneDX 1.6 Cryptographic Build Reproducibility Verification

In-Toto v1.0 & CycloneDX 1.6 Cryptographic Build Reproducibility Verification defines an industrial-grade behavioral standard for security engineering. Enforces strict bit-for-bit determinism validation across independent isolated build workers before publishing compiled artifacts to registries. Requires mutual cross-verification of CycloneDX 1.6 Cryptographic Bill of Materials (CBOM/SBOM) digests against signed in-toto v1.0 attestation envelopes containing hardware-rooted enclave measurements. 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: Publishing Binaries Lacking Multi-Worker Determinism Consensus or Signed Hardware Attestation Envelopes 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	Publishing Binaries Lacking Multi-Worker Determinism Consensus or Signed Hardware Attestation Envelopes	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 compute bit-for-bit cryptographic hashes (SHA-256 and BLAKE3) of build artifacts across at least two isolated, independent rebuilders prior to registry promotion.

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.