In-Toto Attestation

Attestations follow a structured JSON schema with a defined subject (the artifact) and a predicate (the metadata claim). Common predicate types include:

• SLSA Provenance v1.0: Describes how an artifact was built, including builder ID, source repos, and build commands.
• SPDX: A Software Bill of Materials detailing all components and licenses.
• Vulnerability Scan: Results from container image scanning tools.
• Test Results: Pass/fail status of a test suite run against the artifact. This standardization allows policy engines to parse and validate claims automatically.

A layout is a cryptographically signed policy document that defines the required steps and functionaries for a software supply chain. It specifies:

• Steps: The actions that must be performed (e.g., 'clone-repo', 'run-tests', 'build-container').
• Functionaries: The public keys of identities authorized to perform each step.
• Thresholds: The minimum number of authorized signatures required for a step to be valid.
• Inspections: Commands run by the verifier to independently audit the final product. The layout acts as the root of trust, and its signature chain must remain unbroken for verification to succeed.

A link is the fundamental unit of evidence in in-toto. Each link captures:

• Materials: The cryptographic hashes (SHA256) of all input files and artifacts before a step executes.
• Products: The cryptographic hashes of all output files and artifacts after a step executes.
• Byproducts: Standard output, standard error, and return codes from the command.
• Environment: Information about the host system, including environment variables.
• Command: The exact command string that was executed. Each link is signed with the functionary's private key, creating a non-repudiable chain of custody from source code to final artifact.

In-toto decouples attestation generation from attestation verification, enabling offline validation. The verification process:

• Requires only the final product, the signed layout, and the collection of signed link files.
• Walks the directed acyclic graph defined in the layout, matching materials to products across steps.
• Cryptographically verifies every signature against the authorized functionary keys.
• Fails closed if any link is missing, signed by an unauthorized key, or if material hashes do not match the previous step's product hashes. This model allows any consumer to independently verify the integrity of an artifact without trusting the build system.

Modern in-toto implementations integrate with Sigstore to eliminate long-lived private key management. This works by:

• Using OpenID Connect (OIDC) tokens from CI/CD platforms (GitHub Actions, GitLab CI) to authenticate the builder's identity.
• Requesting a short-lived ephemeral X.509 certificate from the Fulcio certificate authority, binding the OIDC identity to a public key.
• Recording the signing event in the Rekor transparency log, providing a public, append-only audit trail.
• Signing the in-toto link or attestation with the ephemeral key, which is immediately discarded. This approach provides strong identity binding without the operational burden of securing static signing keys.

In-toto attestations serve as the decision-making input for deploy-time policy engines. The enforcement flow:

• A Binary Authorization system intercepts a deployment request for a container image.
• It queries the image's digest and retrieves all associated attestations from a metadata store.
• An Open Policy Agent (OPA) or similar engine evaluates the attestations against a Rego policy.
• Example policy: 'Require a SLSA Provenance attestation signed by a trusted builder with a source repository from the my-org GitHub organization.'
• If the policy evaluates to false, the deployment is blocked, preventing unverified artifacts from reaching production.

A deploy-time security control that enforces cryptographic signature validation before allowing container images to run in production. Binary Authorization policies can be configured to require valid in-toto attestations proving the image passed specific CI/CD steps—such as vulnerability scanning or code review—before admitting it into the runtime environment. This creates a continuous chain of verification from source to execution.

Verifiable information about the origin, build steps, and source materials that produced a specific software artifact. In-toto provenance attestations follow the SLSA provenance v1.0 schema, capturing details such as:

• Builder identity and environment
• Source repository and commit hash
• Build invocation parameters
• All input artifacts and dependencies This allows downstream consumers to assess trustworthiness based on objective, cryptographically verified evidence.

A development practice where compiling identical source code in an identical environment always produces a bit-for-bit identical output. When combined with in-toto attestations, reproducible builds enable independent verifiers to rebuild an artifact and compare the resulting hash against the attested digest. This provides the strongest possible guarantee that no tampering occurred during the build process, as any discrepancy is immediately detectable.