Software attestation answers a fundamental question: can you prove that this artifact was built from this source code, by this build system, using this process? Not just claim it -- prove it, with cryptographic evidence.
Three frameworks dominate the attestation landscape in 2025: SLSA (Supply-chain Levels for Software Artifacts), in-toto, and Sigstore. They are complementary rather than competing, but the overlap in their capabilities creates confusion. Here is a practical comparison.
Why Attestation Matters
Before comparing frameworks, let us establish why this matters with a concrete scenario.
An attacker compromises your CI/CD system and injects a backdoor into a build artifact. The artifact has the correct version number, passes all tests (because the attacker also modified the test), and is deployed normally. Without attestation, there is no way to detect that the artifact does not correspond to the source code in your repository.
With attestation, the build process generates a cryptographically signed statement that records: what source code was used, what build system produced the artifact, what steps were executed, and what the resulting artifact's hash is. If any of these change -- including an attacker modifying the build -- the attestation either fails to verify or is absent entirely.
Framework 1: SLSA (Supply-chain Levels for Software Artifacts)
SLSA (pronounced "salsa") is a framework developed by Google that defines progressive levels of build integrity assurance. It is more of a maturity model than a specific tool.
The Levels
SLSA Level 1 (Build L1): Provenance exists. The build process generates a record of how the artifact was built, but the provenance is not necessarily complete or verifiable. This is the "we have some documentation" level.
SLSA Level 2 (Build L2): Hosted build platform. The build runs on a hosted service (GitHub Actions, Google Cloud Build, etc.) that generates provenance automatically. The provenance is signed by the build platform, not just the developer.
SLSA Level 3 (Build L3): Hardened build platform. The build service provides strong isolation between builds, prevents builds from influencing each other, and generates provenance that is resistant to tampering by the build service's own operators.
What SLSA Actually Produces
A SLSA provenance attestation is a JSON document following the in-toto attestation format (yes, the frameworks overlap) that records:
{
"buildType": "https://github.com/slsa-framework/slsa-github-generator/...",
"builder": { "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml" },
"invocation": {
"configSource": {
"uri": "git+https://github.com/your-org/your-repo@refs/tags/v1.0.0",
"digest": { "sha1": "abc123..." }
}
},
"materials": [
{ "uri": "git+https://github.com/your-org/your-repo", "digest": { "sha1": "abc123..." } }
]
}
This tells you: the artifact was built by GitHub Actions, from this specific commit of this specific repository, using this specific workflow.
Practical Reality
SLSA L1 is trivial to achieve -- just generate build metadata. SLSA L2 is achievable for any team using a major CI/CD platform with SLSA generators (GitHub Actions, Google Cloud Build). SLSA L3 is currently only fully achievable on a few platforms with specific configurations.
The SLSA ecosystem is most mature in the Go and container image spaces. The SLSA GitHub generator can produce L3 provenance for GitHub Actions builds. For other languages and platforms, L2 is more realistic.
Framework 2: in-toto
in-toto is a framework for securing the entire software supply chain -- not just the build step, but every step from source commit to deployment. It was developed at NYU and is now a CNCF graduated project.
How in-toto Works
in-toto models the supply chain as a series of steps, each performed by a specific functionary (person or automated process). Each step produces a link -- a signed attestation of what happened during that step.
A supply chain layout defines:
- What steps must happen
- Who is authorized to perform each step
- What artifacts each step should produce
- What inspections should be run to verify the results
At verification time, in-toto checks that: all required steps were performed, each step was performed by an authorized functionary, the outputs of each step match the inputs of the next step, and all inspections pass.
What Makes in-toto Different
The key differentiator is in-toto's concept of a supply chain layout. SLSA focuses on build provenance -- proving that a build happened correctly. in-toto models the entire pipeline, including steps that happen before and after the build.
For example, you can define that:
- A code review must happen before the build (performed by an authorized reviewer)
- The build must use the reviewed code (artifact hash matching)
- Security scanning must happen after the build (performed by the scanning tool)
- Only scanned artifacts can be deployed
This is more expressive than SLSA provenance alone, but it is also more complex to set up and maintain.
Practical Reality
in-toto's expressiveness is both its strength and its adoption barrier. Defining a complete supply chain layout requires understanding every step in your pipeline and modeling it formally. For organizations with simple, well-defined pipelines, this is manageable. For organizations with complex, evolving pipelines, maintaining the layout is ongoing work.
in-toto is the foundation that SLSA provenance is built on (SLSA uses the in-toto attestation format), so organizations using SLSA are already partially using in-toto.
Framework 3: Sigstore
Sigstore is the infrastructure layer. Where SLSA and in-toto define what attestations to produce, Sigstore provides the mechanisms for signing, storing, and verifying those attestations.
Sigstore Components
Cosign -- signs and verifies container images and other artifacts. Uses short-lived certificates tied to OIDC identities rather than long-lived GPG keys.
Fulcio -- a free certificate authority that issues short-lived signing certificates based on OIDC authentication. You prove you are who you say you are through your identity provider (GitHub, Google, etc.), and Fulcio issues a certificate valid for 10 minutes.
Rekor -- a transparency log that records all signing events. Once a signing event is recorded in Rekor, it cannot be removed or modified. This provides a tamper-evident record of all attestations.
What Makes Sigstore Different
Sigstore solves the key management problem that has plagued software signing for decades. Traditional code signing requires managing long-lived private keys -- generating them securely, storing them safely, rotating them periodically, revoking them when compromised. Most developers do not do this well (or at all).
Sigstore's keyless signing model eliminates private key management. You authenticate with your identity provider, get a short-lived certificate, sign your artifact, and the signing event is recorded in the transparency log. There are no keys to manage, store, or lose.
Practical Reality
Sigstore is the most practically adoptable of the three frameworks because it focuses on reducing friction rather than adding requirements. Signing a container image with cosign is a single command. Verifying a signed image is another single command.
The limitation is that Sigstore is infrastructure, not policy. It can tell you that an artifact was signed by a specific identity at a specific time. It cannot tell you whether the build process that produced the artifact was trustworthy. That is where SLSA and in-toto come in.
How They Work Together
The best approach combines all three:
- in-toto defines your supply chain layout -- what steps must happen and who can perform them
- SLSA provides specific guidance for the build step, including provenance generation and build platform requirements
- Sigstore provides the signing and verification infrastructure for all attestations
In practice, a mature attestation pipeline looks like this:
- Developer commits code (signed commit via Sigstore/gitsign)
- CI/CD builds the artifact (SLSA L2/L3 provenance generated)
- Security scanning runs (in-toto link attestation)
- Artifact is signed (cosign via Sigstore)
- Provenance is recorded (Rekor transparency log)
- Deployment verifies all attestations before accepting the artifact
Getting Started
If you are starting from zero, here is a pragmatic path:
Month 1: Add Sigstore signing to your container images. One command in your CI pipeline. Immediate verifiability for your artifacts.
Month 2: Add SLSA L1 provenance generation. Record basic build metadata. For GitHub Actions, use the official SLSA generator.
Month 3: Upgrade to SLSA L2. Ensure provenance is generated by the build platform rather than your own scripts.
Months 4-6: Define an in-toto layout for your most critical pipeline. Start with the steps that carry the most risk.
How Safeguard.sh Helps
Safeguard.sh integrates with software attestation frameworks to provide a complete supply chain security picture. Our platform verifies SLSA provenance and Sigstore signatures for your dependencies, flags components that lack attestation, and incorporates attestation status into policy gates. You can enforce requirements like "all production dependencies must have SLSA L2 provenance" or "all container images must be Sigstore-signed." Attestation tells you how software was built. Safeguard tells you whether how it was built meets your standards.