In-Toto Attestation

The core of an in-toto attestation is the predicate, a JSON object that describes the specific event or material. This is wrapped in an envelope containing the subject (the artifact being described) and the statement linking them. Common predicate types include:

• SLSA Provenance: Describes how an artifact was built, including builder ID, source repo, and build recipe.
• Vulnerability Scan: Records the results of a security scan at a specific point in time.
• Test Result: Captures which tests passed or failed against a specific artifact digest. This decoupling of the generic wrapper from the specific claim allows the framework to be extended to any supply chain event.

Attestations cryptographically link an artifact's subject digest (e.g., a container image SHA256 hash) to the exact source materials used. This creates a non-repudiable record proving that a specific binary was produced from specific source code. Key properties include:

• Immutable References: Materials are referenced by their cryptographic hashes, not mutable tags like 'latest'.
• Transitive Verification: By chaining attestations, you can verify the integrity of dependencies recursively, ensuring the entire dependency tree is tamper-free.
• Non-Repudiation: The signing key used to generate the attestation provides strong evidence of the actor or system that performed the step.

Attestations are not merely documentation; they are machine-readable inputs to a policy engine. Before deploying an artifact, an admission controller can query an attestation store and evaluate policies such as:

• 'Require two code reviewers': The policy checks for attestations proving code review completion.
• 'Block high-severity CVEs': The policy rejects artifacts with a vulnerability scan attestation containing critical findings.
• 'Allow only specific build systems': The policy verifies the builder ID in the SLSA provenance attestation. This shifts security from manual audit to automated, continuous enforcement.

In-toto attestations are wrapped in a Dead Simple Signing Envelope (DSSE). This standard wrapper provides a simple, foolproof structure for signing arbitrary payloads. The structure consists of:

• payloadType: A string identifying the type of the serialized body (e.g., application/vnd.in-toto+json).
• payload: The Base64-encoded serialized attestation body.
• signatures: An array of one or more cryptographic signatures over the payload. DSSE avoids canonicalization issues that plagued earlier signing schemes, ensuring that verification is deterministic and robust across different programming languages.

To prevent attackers from hiding malicious activity by simply deleting an attestation, in-toto attestations are often published to a transparency log like Rekor (part of the Sigstore project). This provides:

• Verifiable Timestamping: Proof that an attestation existed at a specific point in time.
• Append-Only Immutability: Once logged, an attestation cannot be removed or altered without detection.
• Global Auditability: A public, tamper-resistant record of all supply chain operations, enabling post-incident forensic analysis. This closes a critical gap where a compromised pipeline could simply suppress evidence of tampering.

The original in-toto specification defines a layout, a signed policy document that describes the intended sequence of steps in a supply chain. A layout specifies:

• Steps: The individual operations (e.g., 'clone', 'build', 'test') and the authorized functionaries (keys) for each.
• Inspections: Commands run during verification to independently check the final product's state.
• Thresholds: The minimum number of authorized signatures required for a step to be considered valid. The final verification process walks the entire chain of link metadata, ensuring every step was executed by an authorized functionary in the correct order.

A nested inventory listing all open-source and third-party components, libraries, and dependencies used in a software artifact. SBOMs provide the material context that in-toto attestations reference when verifying provenance.

• Standard formats: SPDX, CycloneDX
• Enables vulnerability management and license compliance
• Required by U.S. Executive Order 14028 for federal software

Supply-chain Levels for Software Artifacts provides a graded checklist of controls to prevent tampering and ensure integrity throughout the build and distribution process. In-toto attestations serve as the cryptographic evidence layer that proves SLSA compliance.

• Levels range from SLSA 0 (none) to SLSA 3 (auditable)
• Requires hermetic builds and isolated signing at higher levels
• Defines provenance attestation format compatible with in-toto

An open-source project enabling automated, keyless signing and verification of software artifacts. Sigstore uses short-lived ephemeral certificates linked to OpenID Connect identities, eliminating long-term key management.

• Integrates with in-toto for signing attestation payloads
• Uses Fulcio (certificate authority) and Rekor (transparency log)
• Powers cosign for container image signing

A deploy-time security control that enforces strict validation by requiring cryptographically signed signatures before a container image or binary is allowed to execute in production. In-toto attestations provide the verifiable metadata that binary authorization policies evaluate.

• Common in Kubernetes via admission controllers
• Prevents deployment of unsigned or tampered artifacts
• Enforces policy-as-code for supply chain gates