What this article covers
- What attestations are and why they matter for supply chain security
- The five critical pipeline stages where attestations should be captured
- How to implement source, build, test, SBOM, and deployment attestations
- Verification and policy enforcement using OPA and Kubernetes admission control
- Real-world implementation patterns and performance optimization strategies
Understanding attestations
An attestation is a cryptographically signed statement about a software artifact. Unlike simple signatures that only verify who signed, attestations provide structured metadata about the artifact's entire lifecycle: where the code came from, what infrastructure built it, which dependencies were used, what tests passed, and what security scans were performed. Modern software supply chains face unprecedented threats. The 2020 SolarWinds breach and 2021 Codecov incident demonstrated that trusting build artifacts without verification is no longer viable. Attestations solve this by providing cryptographic proof that enables you to answer: What source code was used? Who built it? What tests passed? Was the build environment compromised?
Why attestations prevent tampering
Traditional CI/CD systems produce artifacts but lack verifiable evidence of how they were created. Attestations provide:
- Cryptographic signatures that detect unauthorized modifications
- Verification mechanisms for downstream consumers before deployment
- Immutable audit trails for compliance and incident response
- Policy enforcement gates that automatically reject non-compliant artifacts
SLSA compliance levels
SLSA (Supply-chain Levels for Software Artifacts) defines maturity levels for supply chain security:
- SLSA 0: No guarantees
- SLSA 1: Build process is documented
- SLSA 2: Build service generates signed provenance
- SLSA 3: Build provenance is non-falsifiable (hardened build platform)
- SLSA 4: Two-party review of all changes
An attestation pipeline is essential for achieving SLSA Level 2+ compliance.
Pipeline architecture overview
A comprehensive attestation pipeline captures evidence at five critical stages:
Core components
Attestation Generators: Embedded in CI/CD stages to collect evidence, generate in-toto predicates, and sign attestations using ephemeral keys. Signing Infrastructure: Keyless signing via Sigstore/Fulcio (OIDC-based), Hardware Security Modules (HSM) for long-lived keys, or Key Management Service (KMS) integration. Attestation Storage: OCI registries store attestations alongside container images, while transparency logs like Rekor provide public audit trails. Verification Layer: Policy engines (Open Policy Agent, Kyverno), Kubernetes admission controllers, and CLI tools enable verification at deployment time.
Recommended technology stack
Component
Recommendation
Why
Attestation Format
in-toto
SLSA standard format
Signing
Sigstore
Keyless signing reduces operational overhead
Verification
slsa-verifierPolicy-aware validation
Policy-aware validation
Open Policy Agent
Maximum flexibility
Stage 3: Test and security attestation
Test attestations prove security scans passed and tests succeeded before deployment.
Implementation example
Adding VEX documents
VEX (Vulnerability Exploitability eXchange) documents explain why specific vulnerabilities don't affect your application:
Stage 2: Build provenance attestation
Build provenance documents the build environment and ensures reproducibility.
Implementation example
Critical requirements
Immutable Build Environment: Use pinned base images with SHA digests, not tags. This prevents attacks where a compromised registry serves malicious images. Hermetic Builds: Restrict network access and pre-fetch dependencies. This ensures builds are reproducible and not dependent on external resources at build time. Build Service Identity: Use non-falsifiable identity providers like GitHub Actions OIDC or GCP Workload Identity. This prevents attackers from forging build provenance.
Stage 1: Source code attestation
Source attestation proves which commit was used and that code review occurred.
Implementation example
Evidence captured
- Git commit SHA and repository URL
- Branch or tag reference
- Build trigger (push, pull request, manual)
- OIDC identity of the actor who initiated the build
Stage 4: SBOM attestation
SBOM (Software Bill of Materials) attestations provide a complete inventory of components and their licenses.
Implementation example
SBOM best practices
- Use SPDX 2.3+ or CycloneDX 1.5+ format
- Include transitive dependencies, not just direct dependencies
- Document license information for compliance
- Link to source repositories for each component
Verification and policy enforcement
Manual verification
Developers can verify attestations locally before deployment:
Automated policy enforcement with OPA
Use Open Policy Agent to enforce attestation requirements automatically:
Kubernetes admission control with Kyverno
Enforce attestation policies at the Kubernetes admission control layer:
Stage 5: Deployment attestation
Deployment attestations record where and when artifacts were deployed.
Implementation example
Optimization strategies
Parallel attestation generation: Generate attestations concurrently with build/test stages instead of sequentially. Cached signing credentials: Reuse OIDC tokens and signing certificates across pipeline steps to reduce authentication overhead. Batched transparency log submissions: Submit multiple attestations to Rekor in a single batch rather than individually. Async verification post-deployment: For low-risk environments, verify attestations after deployment to reduce deployment latency.
Performance impact and optimization
Typical overhead per pipeline stage
Stage
Without Attestation
With Attestation
Overhead
Build
3m 45s
4m 10s
+25s (11%)
Test
2m 30s
2m 45s
+15s (10%)
Package
1m 15s
1m 35s
+20s (27%)
Deploy
45s
55s
+10s (22%)
Total
8m 15s
9m 25s
+1m 10s (14%)
Implementation roadmap
Phase 1: Infrastructure setup (Month 1)
- Use SPDX 2.3+ or CycloneDX 1.5+ format
- Configure OCI registry with attestation support
- Create reusable GitHub Actions workflows
Phase 2: Pilot implementation (Months 2-3)
- Select 10 high-value services for initial rollout
- Implement full attestation pipeline for pilot services
- Document lessons learned and common issues
Phase 3: Organization-wide rollout (Months 4-5)
- Migrate remaining services to attestation pipeline
- Enable policy enforcement in audit mode
- Train development teams on verification workflows
Phase 4: Enforcement (Month 6)
- Switch policy enforcement to blocking mode
- Block deployments without valid attestations
- Establish incident response procedures for attestation failures
Common challenges and solutions
Attestations become stale in long-running pipelines Solution: Implement attestation refresh mechanisms with timestamp checks. Reject attestations older than a configurable threshold (e.g., 24 hours). Private dependencies break hermetic builds Solution: Use artifact caching layers with integrity verification. Pre-fetch dependencies and verify their checksums before build execution. Key management complexity Solution: Adopt keyless signing with Sigstore for ephemeral workloads. This eliminates the need to manage long-lived signing keys. Verification performance at scale Solution: Implement caching layers for verification results. Use signature bundle format to reduce network calls during verification.
Notes / Tips
- Start with source and build provenance to achieve SLSA Level 2, then add test and SBOM attestations
- Keyless signing with Sigstore significantly reduces operational overhead compared to managing signing keys
- Store attestations in OCI registries alongside images for simplified distribution
- Use transparency logs (Rekor) for public accountability and tamper detection
- Monitor attestation generation success rates and alert on missing attestations in production
- Provide CLI tools and dashboards so developers can verify attestations locally
- Maintain offline backups of attestation databases for disaster recovery
Related articles
- Understanding SLSA Levels and Compliance Requirements
- Sigstore Keyless Signing Implementation Guide
- Container Image Verification in Kubernetes
- Building Hermetic CI/CD Pipelines
References
- SLSA Framework: https://slsa.dev
- in-toto Attestation Format: https://github.com/in-toto/attestation
- Sigstore Documentation: https://www.sigstore.dev
- Open Policy Agent: https://www.openpolicyagent.org