When you deploy a container image to production, can you prove where it came from? Can you trace it back to a specific commit in a specific repository, built by a specific pipeline, from source code that was reviewed by specific people? If you cannot answer these questions, you have a provenance gap — and that gap is exactly what supply chain attackers exploit.
Software provenance is the verifiable record of how a software artifact was produced. In 2022, driven by high-profile supply chain attacks and government mandates, provenance tracking shifted from a niche concern to a core security requirement.
What Provenance Actually Means
Provenance answers three fundamental questions:
Source provenance: Where did the source code come from? Which repository, which branch, which commit? Was the code reviewed before it was merged?
Build provenance: How was the artifact built? Which build system, which build configuration, which build environment? Were the build inputs locked to specific versions?
Deployment provenance: How did the artifact reach production? Which deployment pipeline, which approvals, which configurations were applied?
Together, these form a chain of custody from the developer's commit to the running production system. A break at any point in this chain is an opportunity for an attacker to inject malicious code.
The SLSA Framework
Supply-chain Levels for Software Artifacts (SLSA, pronounced "salsa") is a framework developed by Google and now maintained by the OpenSSF that defines four levels of supply chain security maturity:
SLSA Level 1: Documentation
The build process is documented and produces provenance metadata. This is the bare minimum — you know how your software is built, even if you cannot verify it.
Requirements:
- Scripted build (no manual steps)
- Provenance metadata generated
SLSA Level 2: Hosted Build
The build runs on a hosted service that generates authenticated provenance. This ensures the provenance is not trivially forgeable.
Requirements:
- Build service generates provenance
- Provenance is authenticated (signed)
- Version control for source
SLSA Level 3: Hardened Build
The build environment is hardened against tampering. Builds run in isolation, and the build service itself is protected from compromise.
Requirements:
- Build runs in ephemeral, isolated environment
- Provenance is non-forgeable
- Source is version-controlled and reviewed
SLSA Level 4: Complete Provenance
Two-person review of all changes, hermetic builds (no network access during build), and reproducible builds where possible.
Requirements:
- Two-person reviewed source
- Hermetic, reproducible builds
- Complete dependency provenance
Most organizations in 2022 were somewhere between Level 1 and Level 2. Reaching Level 3 requires significant investment in build infrastructure. Level 4 is currently aspirational for most.
Practical Implementation
Step 1: Automate Your Build
If your build involves any manual steps — copying files, running commands by hand, editing configuration — your provenance chain is already broken. Everything must be scripted and version-controlled.
# Everything about the build is defined in code
name: Build and Sign
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: npm ci
- run: npm run build
- run: docker build -t myapp:${{ github.sha }} .
Step 2: Generate Build Provenance
Use tools that generate provenance attestations alongside your build artifacts. The SLSA GitHub Generator creates provenance that meets SLSA Level 3 requirements:
# Generate SLSA provenance for container images
- uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml
with:
image: myregistry/myapp
digest: ${{ steps.build.outputs.digest }}
Provenance attestations record:
- The source repository and commit
- The builder identity and environment
- The build command and configuration
- The output artifact digest
Step 3: Sign Everything
Code signing provides cryptographic proof that an artifact was produced by a specific entity. Sigstore makes this accessible:
# Sign a container image with Cosign (Sigstore)
cosign sign myregistry/myapp@sha256:abc123...
# Sign with provenance attestation
cosign attest --predicate provenance.json \
--type slsaprovenance \
myregistry/myapp@sha256:abc123...
Sigstore's keyless signing ties the signature to the identity of the build pipeline (via OIDC tokens from GitHub, GitLab, etc.), eliminating the need to manage signing keys.
Step 4: Verify Before Deployment
Provenance is only valuable if you verify it. Configure your deployment pipeline or admission controller to verify provenance before allowing artifacts to run:
# Verify image provenance before deployment
cosign verify-attestation \
--type slsaprovenance \
--certificate-identity "https://github.com/myorg/myrepo/.github/workflows/build.yml@refs/heads/main" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
myregistry/myapp@sha256:abc123...
Step 5: Track Dependencies
Your provenance chain is only as strong as its weakest link. If your artifact was built from verified source but one of your 200 npm dependencies was compromised, the provenance of your artifact is meaningless without knowing the provenance of its inputs.
This is where SBOMs and provenance intersect. An SBOM tells you what components are in your software. Provenance tells you where those components came from and how they were built.
The Sigstore Ecosystem
Sigstore has emerged as the de facto standard for software signing and verification in the open source ecosystem. It consists of:
Cosign: Signing and verification tool for container images and other artifacts.
Fulcio: A certificate authority that issues short-lived certificates tied to OIDC identities (your CI/CD pipeline's identity).
Rekor: A transparency log that records all signing events, providing a tamper-evident record of who signed what and when.
Together, these components enable keyless signing — you do not need to generate, store, or rotate signing keys. Your build pipeline's identity (verified through OIDC) serves as the signing identity.
Challenges in Practice
Dependency provenance is hard. You can control the provenance of your own code, but verifying the provenance of every third-party dependency is currently impractical for most organizations.
Reproducible builds are harder than they sound. Timestamps, non-deterministic file ordering, and platform-specific behavior make truly reproducible builds an engineering challenge.
Tooling is evolving rapidly. The provenance tooling landscape changes monthly. Standards, APIs, and best practices are still being established.
How Safeguard.sh Helps
Safeguard.sh provides an integrated provenance tracking system that records the complete lineage of your software artifacts — from source commit through build and deployment. Our platform verifies Sigstore signatures, validates SLSA provenance attestations, and maintains an auditable record of your software supply chain. Combined with SBOM management, Safeguard.sh gives you end-to-end visibility into not just what your software contains, but where every component came from and how it was built.