DevOps3 min read

Container Image Signing & SLSA Provenance Verification with Sigstore Cosign

The SolarWinds and Log4j vulnerabilities weren’t just security failures—they were wake-up calls. Suddenly, "just build and push" felt dangerously naive. Teams r...

Listen to Article

Click play to listen to audio narration

Container Image Signing & SLSA Provenance Verification with Sigstore Cosign

Introduction

The SolarWinds and Log4j vulnerabilities weren’t just security failures—they were wake-up calls. Suddenly, “just build and push” felt dangerously naive. Teams realized that trusting a container image’s integrity required more than a developer’s intuition or a CI/CD pipeline’s automated tests. Enter Sigstore Cosign, a toolkit that turns cryptography into a non-negotiable guardrail. By combining SLSA (Supply-Chain Levels for Software Artifacts) provenance with cryptographic signing, Cosign ensures that every image you run is exactly what your team intended—no tampering, no surprises.

Why This Matters

In distributed systems, trust is fragile. Developers, builders, and operators often exist in silos, with no shared cryptographic proof of an image’s origin or build environment. Manual signing workflows are error-prone, and even when teams try to automate them, there’s no audit trail. SLSA Provenance addresses this by codifying how an image was built (e.g., “this Dockerfile ran in a CI runner with a specific Git commit hash”), while Cosign cryptographically binds that process to the final image. Without this, you’re left guessing: Was that “nginx” image really built by your team, or did someone swap the base layer?

How It Works

Architecture

Cosign integrates into your CI/CD pipeline to sign container images cryptographically. The workflow involves generating a Software Bill of Materials (SBOM) to track dependencies, signing the image’s digest, and storing both the signature and SBOM alongside the image in a registry. Downstream systems (like Kubernetes admission controllers) then verify the signature and SBOM before allowing deployment.

Here’s the pipeline visualized:

flowchart TD  
A[Source Code] --> B[CI Build (docker build)]  
B --> C[Generate SBOM (syft)]  
C --> D[Cosign Sign Image (keyless or KMS)]  
D --> E[Upload Image + Signature + SBOM to OCI Registry]  
E --> F[Verification Service (cosign verify + sbom check)]  
F --> G{Trust Decision}  
G -->|Yes| H[Deploy to Production (K8s, etc.)]  
G -->|No| I[Reject Build / Alert]  

Core Concepts

  • SBOM: A structured inventory of all components in an image (e.g., packages, licenses). Tools like Syft generate SPDX or CycloneDX SBOMs.
  • SLSA Provenance: A JSON blob detailing the build environment, Dockerfile, and Git commit hash. This answers, “Where was this image built, and how?”
  • Keyless Signing: Instead of managing PGP keys, Cosign uses your CI’s identity (via OIDC tokens) to sign images, eliminating key rotation headaches.
  • Transparency Log: A public log (hosted by Cosign) that archives all signatures for auditability.

Examples & Code Walkthrough

Dockerfile

# Build stage  
FROM golang:1.21 as builder  
WORKDIR /app  
COPY . .  
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app  

# Final stage  
FROM
Tags:#container#devops#image#signing
S

Written by Staff DevOps & Infrastructure Engineer

Editorial staff persona specializing in container orchestration, CI/CD pipeline automation, log aggregation, and real-time monitoring infrastructure.

View Profile
Recommended For You

Related Articles

Quick:
Navigate Select
Loading search index...