in-toto

What it is #

in-toto is a framework (a specification plus reference implementations) for recording who did what in a software supply chain, in a way that can be cryptographically verified after the fact. It originated at NYU and is now a CNCF-graduated project. Two parts of the project matter for the landscape.

The original model (layout and link metadata). A project owner writes a layout: a signed document declaring the steps of the supply chain (clone, build, test, package, sign), who is allowed to perform each step (by public key), and what each step’s inputs and outputs are expected to look like (by hash). Each party performing a step (a “functionary”) signs a link metadata file recording the inputs consumed and the outputs produced. Verification combines the layout, all link files, and the final product to check that the supply chain was executed exactly as the owner declared.

The in-toto Attestation Framework. A more recent generalisation that decouples the signed envelope from the claim. An attestation is a DSSE-signed envelope carrying a subject (the artefact the attestation is about, named by hash) and a predicate (the actual claim, in a typed format). Predicate types include SLSA build provenance, SPDX SBOMs, vulnerability scan results, test results, and many others. This is the format most modern provenance schemes emit: SLSA provenance, cosign attest outputs, GitHub Actions artifact attestations, and several SBOM-distribution schemes all encode their data as in-toto attestations.

Trust model #

in-toto itself does not define a trust root; it specifies a metadata format and a verification procedure. The trust anchor depends on how in-toto is deployed. In the original layout model, trust is rooted in the layout signer (typically the project owner): the layout names the keys allowed to perform each step, and verification is against those keys. In Attestation Framework deployments, trust depends on the signing scheme wrapping the attestation: Sigstore-signed attestations inherit Sigstore’s trust roots (Fulcio, Rekor, OIDC providers); attestations signed with long-lived keys inherit whatever PKI those keys participate in.

What in-toto attests, in either model, is something about the process by which an artefact came to exist (which steps ran, by whom, with which inputs and outputs). It does not attest to the properties of the inputs themselves, nor that the produced output is correct, only who produced it.

Comparison to OpenVet #

in-toto and OpenVet are both signed-metadata frameworks for making verifiable claims about software artefacts, but they sit at different points on the supply chain.

What is being attested. in-toto attests process: which steps ran, in what order, by which parties, producing which artefacts. OpenVet helps you make attestations about the code itself: whether it is malicious, whether it is implemented correctly, whether there are findings consumers should know about. An in-toto chain that verifies end-to-end is consistent with the supply-chain layout, but says nothing about whether anyone read the source.

Trust set. in-toto’s trust roots depend on the deployment: a layout signer in the classic model, or the signing scheme wrapping an attestation in the modern one. OpenVet consumers list one or more log URLs in openvet.toml, each independently signed by its owner.

Distribution. in-toto attestations are typically attached to the artefact they describe (alongside a container image, or as files in a release). OpenVet audits live in append-only logs that consumers subscribe to by URL, so a consumer pulls audits relevant to its lockfile rather than fetching alongside every artefact.

Claim shape. in-toto attestations carry typed predicates with schemas defined per predicate type (SLSA provenance, SPDX SBOM, and so on). OpenVet audits carry structured claims drawn from a shared vocabulary, each an atomic observable property of the audited code. Both formats can express “X is true about artefact Y, signed by Z”; the catalogues are scoped differently.

Using alongside OpenVet #

in-toto and OpenVet compose at the audit step, not at consumer evaluation: in-toto attestations are evidence an auditor consumes and re-surfaces as OpenVet claims.

Source-code audits. The auditor reads the source directly and asserts claims about what is in the code. in-toto attestations are not particularly useful here; the source itself is the evidence.

Audits touching binary artefacts. Compiled blobs, vendor-shipped libraries, and model weights cannot be read meaningfully. An auditor can still verify any in-toto attestations attached to the artefact and re-surface what those prove as OpenVet claims. “The binary is reproducible and I have reproduced it from the published source”, or “the binary’s SLSA provenance verifies against the upstream CI workflow”, are not equivalent to “this binary is benign”, but they are concrete claims a consumer can require, anchored in evidence the auditor consumed during the review.

Format reuse. OpenVet does not encode its audits as in-toto attestations; it uses its own envelope format, optimised for append-only log storage and content-addressed lookups. The conceptual overlap (signed envelope, subject plus claim, hash-bound artefact) is significant, but the storage and distribution model is intentionally different.