Continuum Academy
Understanding software evidence
Software can be built, tested and shipped without giving its recipient a reliable way to establish how it was produced.
This Academy takes you step by step through connecting an artifact to its origin, creating a verifiable attestation, and working with standards such as in-toto and SLSA.
No prior knowledge of cryptography or software supply chain security required.
Start here
You receive a software archive: this is the delivered artifact. How can you tell whether it is the expected file, how it was built and who makes that claim? This example will guide the learning paths, from a practical problem to the concepts and then to hands-on verification.
The artifact
What do we actually know about the file we received?
The hash
What a hash proves — and what it does not.
The attestation
Turning a claim into something verifiable.
Build provenance
Connecting an artifact to the process that produced it.
The signature
Establishing who stands behind a claim.
Verification
Checking the evidence independently of the producer.
Three learning paths
The first chapter is available. The remaining eleven will be developed over time. Selected existing resources already provide an introduction to some topics.
Learning path 1
Fundamentals
Start with a delivered file and understand the evidence that can accompany it.
From source code to shipped software: where is the evidence?
From source code to shipped software: where is the evidence?Hashes, signatures, attestations and provenance
Why a hash is not enough to explain software originsAnatomy of an in-toto attestation
in-toto and Continuum Attest signed receiptsUnderstanding SLSA Provenance
Build provenance: connect artifacts to their build
Learning path 2
Hands-on practice
Produce evidence, verify it and observe what happens when the file changes.
Create your first verifiable evidence with Continuum Attest
CLI documentation · Getting startedModify an artifact and watch verification fail
Verify a software delivery on another machine
Can software be verified without trusting the platform that built it?Verify a software delivery offline
Offline verification of signed receipts
Learning path 3
Going deeper
Understand complementary records, trust decisions and the limits of verification.
SBOMs and provenance
SBOM vs attestation: composition, provenance and signaturesTrust models and key management
What an attestation does not prove
in-toto, SLSA and Sigstore: how they fit together
in-toto, SLSA, Sigstore: who does what?
An attestation records a claim about an artifact. Even when signed, it does not guarantee that the claim is true, that the software has no vulnerabilities or that it meets compliance requirements. Understanding what is checked and whom you trust is part of the learning journey.