Skip to main content
CleanStart

Knowledge Hub

How to Design an Automated Attestation Pipeline for Software Factory Architecture

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-verifier

Policy-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