IN-TOTO-ATTESTATIONS

in-toto Attestations framework signed supply chain.

Définition

in-toto Attestation Framework structure : (1) Envelope (DSSE) : JSON envelope avec 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) Predicate types standard : 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), publi via OCI registry (Cosign attaches attestation alongside image), published with package npm/PyPI registries, sigstore Rekor log immutable. Tools : Cosign (Sigstore), GitHub Attestations API, GitLab Pipeline Attestations.

Origine

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

Exemple en contexte

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.

Termes liés

• Sigstore Cosign — outil signing principal.