What is in-toto?
An open framework for cryptographically attesting software supply-chain steps. An in-toto Statement bundles a predicate (what happened) with a subject (what it applies to) under a signed envelope. Securie emits in-toto v1 Statements as the attestation payload for every scan.
Full explanation
in-toto (pronounced 'in-toh-toh') is a project from CNCF / NYU's Secure Systems Lab that specifies a cryptographic format for supply-chain attestations. Version 1 Statements have three fields: predicateType (a URI naming the schema), subject (one or more named blobs with their digests), and predicate (the JSON payload). A Statement is then signed via DSSE (Dead Simple Signing Envelope), producing a portable bundle a verifier with the public key can check. SLSA, Sigstore, and Securie's attestation chain all build on in-toto as the underlying format.
Example
Securie's signer produces an in-toto v1 Statement with predicateType `https://securie.com/Predicate/PROOF/v1`, subject `[{ name: "sha256:abc...def", digest: { sha256: "abc...def" } }]`, and predicate `{ scan_id, findings: [...], proof_artifact_sha256, attestation_signer_id }`. The Statement is signed with the tenant's Ed25519 key (or KMS-managed in production), wrapped in a DSSE envelope, optionally published to Sigstore rekor.
FAQ
Why in-toto and not just a JSON-signed bundle?
Standardization. in-toto v1 + DSSE is the de-facto format for supply-chain attestations across SLSA, Sigstore cosign, GitHub Artifact Attestations, and most enterprise compliance tooling. Custom formats require custom verifiers; in-toto verifies with stock cosign + jq.
What's the difference between an in-toto Statement and a SLSA Provenance?
SLSA Provenance is one specific predicateType inside the in-toto envelope (predicateType `https://slsa.dev/provenance/v1`). Securie's Proof predicate (`https://securie.com/Predicate/PROOF/v1`) is a different predicateType describing scan output. Both ride the same in-toto + DSSE wire format.