Article · Continuum Attest
in-toto, SLSA, Sigstore: who does what?
These names often appear together in software supply chain security. They operate at different points: statement structure, production description and signing.
in-toto: express the statement
The in-toto attestation framework connects a statement to identified artifacts. The Statement carries the subject and predicate type. The predicate contains the information specific to the claim.
A tool can recognize provenance and find the artifacts it concerns. The in-toto specifications describe this framework, which is distinct from the full set of mechanisms in the in-toto project.
SLSA: provenance and production requirements
SLSA provides a provenance format and requirements organized into levels. The format describes the build; the levels concern guarantees associated with production and its protections.
A document using the SLSA Provenance predicate does not automatically establish a level. Applicable requirements and supporting evidence must be examined. See the SLSA specification for that distinction.
Sigstore: sign and verify
Sigstore includes Cosign for signing and verifying artifacts and attestations. Verification material can travel in a bundle. Depending on the mode and prepared materials, verification can happen offline.
It would therefore be inaccurate to present Sigstore as inherently incompatible with offline verification. The Sigstore bundle documentation describes the contents; the verification documentation explains their use.
Where Continuum Attest fits
The CLI produces a build receipt and can sign it. Its in-toto export uses a Statement v1, a SLSA Provenance v1 predicate and a DSSE envelope. Those format choices do not make the CLI a security certification.
To examine a release, ask three questions: what does the statement say, which artifact does it concern and how is its signature checked? The receipt format describes the native record; the CLI reference provides exchange commands.