Software attestation answers a simple question: can you prove that this software artifact was built from this source code, using this build process, by this build system? In theory, the answer should always be yes. In practice, most organizations can't provide that proof for any of their software.
By April 2023, attestation had moved from an academic concept to an industry priority, driven by Executive Order 14028, NIST guidelines, the SLSA framework reaching v1.0, and high-profile supply chain attacks demonstrating exactly why provenance matters.
What Attestation Actually Is
An attestation is a signed statement about a software artifact. It says: "I, the build system, certify that I built artifact X from source Y at time Z using process W." The signature makes the statement verifiable — anyone can check that the attestation was made by the claimed build system and hasn't been tampered with.
The most common attestation types:
Provenance Attestation
Records where the artifact came from:
- What source repository and commit were used
- What build system and configuration were used
- What the build process inputs and outputs were
- When the build occurred
SBOM Attestation
A signed SBOM that the build system attests is accurate for a specific artifact.
Vulnerability Scan Attestation
A signed statement from a scanner that a specific artifact was scanned at a specific time and the results are as reported.
Code Review Attestation
A signed statement that the source code was reviewed by specified individuals before the build.
The Frameworks
SLSA (Supply-chain Levels for Software Artifacts)
SLSA provides a maturity framework for build integrity:
- SLSA Level 1: Provenance exists — the build process produces provenance information
- SLSA Level 2: Hosted build — the build runs on a hosted, managed build service
- SLSA Level 3: Hardened build — the build service provides strong isolation and tamper resistance
in-toto
An attestation framework that defines a layout (the expected steps in a supply chain) and links (signed evidence that each step was performed correctly). in-toto allows you to define a complete supply chain policy and verify that every step was followed.
Sigstore
A suite of tools for signing, verifying, and managing attestations:
- Cosign: Signs and verifies container images and artifacts
- Fulcio: A certificate authority for short-lived signing certificates
- Rekor: A transparency log that records signing events
Sigstore's key innovation is eliminating the need for long-lived signing keys. Instead, it uses OIDC identity (like your GitHub account) to issue short-lived certificates. The signing event is recorded in Rekor's transparency log, providing a permanent, tamper-evident record.
Practical Implementation
Step 1: Generate Provenance in Your CI/CD Pipeline
Most major CI/CD platforms now support provenance generation:
GitHub Actions: GitHub provides built-in SLSA Level 3 provenance for GitHub-hosted runners. The actions/attest-build-provenance action generates signed provenance attestations.
GitLab CI: GitLab supports generating SLSA provenance through pipeline integrations.
Google Cloud Build: Natively supports generating and storing provenance attestations.
Step 2: Sign Your Artifacts
Use Cosign to sign container images:
# Sign with keyless signing (uses OIDC identity)
cosign sign ghcr.io/myorg/myapp:v1.0.0
# Sign with a key pair
cosign sign --key cosign.key ghcr.io/myorg/myapp:v1.0.0
For non-container artifacts, use Cosign's blob signing:
cosign sign-blob --bundle myapp.bundle myapp-v1.0.0.tar.gz
Step 3: Attach Attestations to Artifacts
Attestations can be attached directly to container images in OCI registries:
# Attach an SBOM attestation
cosign attest --predicate sbom.json \
--type cyclonedx \
ghcr.io/myorg/myapp:v1.0.0
# Attach a vulnerability scan attestation
cosign attest --predicate vuln-scan.json \
--type vuln \
ghcr.io/myorg/myapp:v1.0.0
Step 4: Verify Before Deployment
Set up verification in your deployment pipeline:
# Verify signature
cosign verify ghcr.io/myorg/myapp:v1.0.0
# Verify provenance attestation
cosign verify-attestation \
--type slsaprovenance \
ghcr.io/myorg/myapp:v1.0.0
For Kubernetes deployments, use admission controllers that verify attestations before allowing container deployment.
Step 5: Enforce Policies
Define policies about what attestations are required:
- All production deployments must have provenance attestations from the official build system
- All container images must have SBOM attestations
- All images must be signed by a known identity
- Vulnerability scan attestations must show no critical vulnerabilities
Common Challenges
Key Management
Traditional signing requires managing private keys — generating them securely, storing them safely, rotating them regularly, and revoking them if compromised. Sigstore's keyless signing solves this by using short-lived certificates tied to OIDC identities, but many organizations still use key-based signing.
Build Reproducibility
Attestation proves what went into a build, but verifying the attestation requires trusting the build system. Reproducible builds allow independent verification — if you can rebuild the same artifact from the same inputs, you can verify that the build system's attestation is accurate.
Legacy Systems
Many organizations have build systems that predate attestation tooling. Retrofitting attestation into legacy build pipelines can be challenging, especially when build environments aren't containerized or when builds depend on manual steps.
Performance
Signing and verification add time to build and deployment pipelines. For organizations running thousands of builds per day, the overhead needs to be managed through caching, parallel processing, and efficient key management.
The Business Case
Software attestation isn't just a security checkbox. It provides concrete business value:
Faster incident response: When a vulnerability is disclosed, attestations let you immediately identify which builds are affected and which are clean.
Customer trust: Providing signed provenance attestations demonstrates to customers that you take supply chain security seriously.
Regulatory compliance: Executive Order 14028, the FDA's SBOM mandate, and CISA's Secure by Design principles all point toward attestation requirements.
Liability protection: Signed attestations provide evidence that you followed security practices, which can be valuable in legal and regulatory contexts.
How Safeguard.sh Helps
Safeguard.sh integrates attestation into your supply chain security workflow:
- Attestation Management: Safeguard.sh generates, stores, and verifies attestations for your software artifacts, providing a central platform for attestation lifecycle management.
- Policy Enforcement: Safeguard.sh enforces attestation policies, ensuring that only properly attested artifacts are deployed to production.
- SBOM Attestation: Safeguard.sh generates signed SBOM attestations that link your software inventory to specific build artifacts.
- Provenance Tracking: Safeguard.sh tracks the complete provenance of your software from source to deployment, providing verifiable evidence of your supply chain integrity.
Attestation is the mechanism that turns supply chain security from a trust-based model to a verification-based model. The tools are mature, the frameworks are standardized, and the industry is moving toward making attestation a requirement rather than an option.