IN-TOTO-ATTESTATIONS

in-toto Attestations framework signed supply chain.

Definition

in-toto Attestation Framework structure: (1) Envelope (DSSE): JSON envelope with payload (base64 encoded), payloadType ('application/vnd.in-toto+json'), signatures array (each signature has keyid + sig). (2) Statement (decoded payload): _type ('https://in-toto.io/Statement/v1'), subject array (each subject has name + digest map sha256/sha512), predicateType (URI to predicate spec), predicate (custom JSON document). (3) Standard predicate types: SLSA Provenance v1.0 ('https://slsa.dev/provenance/v1'), SLSA Verification Summary, SPDX SBOM ('https://spdx.dev/Document'), CycloneDX SBOM, OpenVEX Vulnerability Report, SCAI Source Code Analysis, etc. Storage: .intoto.jsonl files (JSON Lines, one attestation per line), published via OCI registry (Cosign attaches attestation alongside image), published with npm/PyPI package registries, sigstore Rekor log immutable. Tools: Cosign (Sigstore), GitHub Attestations API, GitLab Pipeline Attestations.

Origin

in-toto initially by NYU + NJIT academic research 2017 ; in-toto Attestation Framework specification 2020 ; donated CNCF Sandbox 2019 ; in-toto v1.0 2024 ; basis SLSA Provenance + SBOM signed attestations.

Example in context

Docker image build kubernetes/kube-apiserver:v1.30.0 OCI image published, alongside in-toto Attestation .intoto.jsonl contains SLSA Provenance v1.0 + SPDX SBOM, signed Cosign Sigstore via GitHub OIDC ; end users verify via cosign verify-attestation pre-deployment.

Related terms

• Sigstore Cosign — main signing tool.