In-Toto Attestation

An in-toto attestation is a structured JSON document that follows a standard envelope format. It contains a subject (the artifact being described), a predicate type (the kind of claim being made), and a predicate (the actual metadata). Common predicate types include:

• SLSA Provenance (v1.0): Describes how an artifact was built, including builder identity, source repository, and build commands.
• SPDX: A Software Bill of Materials listing all components and their licenses.
• Vulnerability Scan: Results from a container or dependency scanning tool.
• Test Results: Pass/fail status of a test suite run against the artifact. This separation of the envelope from the predicate allows the same authentication layer to carry diverse, domain-specific claims.

Attestations are wrapped in a Dead Simple Signing Envelope (DSSE). This standard defines a simple, foolproof structure for signing data. The process involves:

• PAE (Pre-Authentication Encoding): The payload and payload type are deterministically serialized to prevent signature confusion attacks.
• Single or Multi-Signature: The envelope supports one or more cryptographic signatures over the PAE string.
• Key Management Agnosticism: DSSE does not prescribe a key management system. It works with Sigstore for keyless signing, raw public/private key pairs, or cloud KMS services. This ensures that the attestation's integrity and authenticity can be independently verified without ambiguity.

In-toto defines a layout, a policy document signed by a project owner that prescribes the entire software supply chain. The layout specifies:

• Steps: Each action to be performed (e.g., clone repo, run tests, build binary).
• Functionaries: The cryptographic identities (public keys) authorized to perform each step.
• Expected Materials and Products: The artifacts consumed and produced by each step, tracked by their cryptographic hashes.
• Inspections: Independent verification steps that can be executed at any time to check the consistency of the supply chain. A verifier replays the entire chain, checking that every step's attestation matches the layout's rules, providing end-to-end integrity guarantees.

To eliminate the burden of long-term private key management, in-toto attestations are commonly generated using Sigstore's keyless signing workflow:

• OIDC Identity Token: The builder authenticates to an OIDC provider (e.g., GitHub Actions) and obtains a short-lived identity token.
• Ephemeral Key Pair: A key pair is generated on the fly. The public key is bound to the identity token in a Certificate Signing Request (CSR).
• Fulcio Certificate Authority: Fulcio issues a short-lived X.509 code-signing certificate after verifying the OIDC token.
• Rekor Transparency Log: The signature and certificate are recorded in the public, append-only Rekor log, providing a timestamped, immutable record of the signing event. This allows verifiers to confirm who signed the attestation and when, without managing secrets.

In-toto verification is not passive; it relies on a policy engine that cryptographically validates the entire attestation graph. Tools like Witness and Kyverno act as admission controllers in Kubernetes environments:

• Witness: Acts as an in-toto client that generates attestations for each step in a CI/CD pipeline and verifies the complete policy before allowing artifact promotion.
• Kyverno: A Kubernetes-native policy engine that can be configured to verify in-toto attestations on container images before they are admitted to a cluster.
• Binary Authorization (Binauthz): GCP's deploy-time security control that enforces policies based on valid attestations. This ensures that only artifacts with a verified, compliant supply chain reach production.

Attestations must travel with the artifact they describe to be useful. The standard distribution mechanism is the OCI (Open Container Initiative) Registry:

• .att and .sig Tags: Attestations are pushed to the same OCI repository as the container image, using a special tag format (e.g., sha256-abc123.att).
• Referrers API: The OCI 1.1 specification defines a standard API for discovering all attestations and signatures associated with a given artifact digest.
• Cosign: A tool from the Sigstore project that handles the bundling, signing, and verification of OCI artifacts and their associated attestations. This co-location ensures that a verifier can always retrieve the provenance data for any artifact it is about to deploy, without a separate metadata store.

A formal, machine-readable inventory of all components, libraries, and modules that constitute a piece of software. An SBOM provides the foundational ingredient list that an in-toto layout verifies. While an SBOM identifies what is inside the artifact, in-toto attestations cryptographically prove how those components were assembled and by whom. The combination of a verifiable SBOM and step attestations creates a complete, tamper-evident provenance trail.

Supply-chain Levels for Software Artifacts (SLSA, pronounced 'salsa') is a security framework that provides a graded checklist of controls to prevent tampering and improve integrity. In-toto attestations are the primary mechanism for achieving SLSA Build Level 2+, as they generate the non-falsifiable provenance metadata required. The framework defines four ascending levels of trust, moving from basic source code versioning up to hermetic, isolated builds with multi-party approval.

An append-only, publicly auditable record that cryptographically tracks the issuance of certificates or attestations. When in-toto attestations are published to a transparency log like Rekor (part of the Sigstore project), they become globally discoverable and immutable. This allows downstream consumers to monitor for unauthorized changes and ensures that an attestation cannot be back-dated or secretly revoked without public detection.

A W3C-standard, tamper-evident digital credential that represents claims made by an issuer about a subject. In-toto attestations can be modeled as verifiable credentials, where a build system (the issuer) makes claims about a software artifact (the subject). This alignment with the W3C Verifiable Credentials Data Model enables selective disclosure of attestation fields and interoperability with broader decentralized identity and trust frameworks.