Skip to main content
INS // Insights

Container Image Signing with Cosign and Sigstore

Updated April 2026 · 6 min read

Software supply chain attacks against government systems have accelerated. The SolarWinds compromise demonstrated the catastrophic downstream effect of injecting malicious code into a trusted software delivery pipeline. For federal cloud programs operating under NIST 800-53, CMMC, or FedRAMP, the response isn't optional — it's a control requirement.

Container image signing addresses one of the most critical attack surfaces: ensuring that the container that reaches production is the same container that passed security gates in CI/CD. Rutagon implements Cosign and Sigstore across all container-based federal delivery work. Here's how that pipeline works in practice.

Why Container Signing Is a Federal Control Requirement

NIST 800-53 Rev 5 identifies software integrity controls under:

  • CM-14 (Signed Components) — Software and firmware components must be signed by a trusted source
  • SA-12 (Supply Chain Risk Management) — Agencies must manage supply chain risks including the software supply chain
  • SI-7 (Software, Firmware, and Information Integrity) — Systems must detect unauthorized changes

FedRAMP High and DoD IL4/IL5 programs inherit these controls. Programs approaching cATO (continuous ATO) need automated integrity verification, not manual attestation.

Cosign Architecture for Federal Pipelines

Cosign (part of the Sigstore project, hosted by the Linux Foundation and backed by Google, Red Hat, and Purdue) provides:

  • Keyless signing via OpenID Connect (OIDC) — short-lived certificates tied to the CI/CD job identity
  • Key-based signing for environments where OIDC is unavailable (common in air-gapped IL5 environments)
  • Image attestation — attaching signed metadata (SBOM, test results, vulnerability scan results) to an image without modifying it
  • Policy enforcement — preventing unsigned or untrusted images from reaching production namespaces

Keyless Signing Flow (GovCloud CI/CD)

# GitLab CI job — image signing after build
sign-image:
  stage: sign
  image: gcr.io/projectsigstore/cosign:v2.2.0
  script:
    - |
      # OIDC token from GitLab CI
      COSIGN_EXPERIMENTAL=1 cosign sign \
        --identity-token "$CI_JOB_JWT_V2" \
        $REGISTRY/$IMAGE_NAME:$CI_COMMIT_SHA
    - |
      # Attach SBOM attestation
      cosign attest \
        --predicate sbom.json \
        --type spdxjson \
        $REGISTRY/$IMAGE_NAME:$CI_COMMIT_SHA
  only:
    - main
    - /^release-.*/

The resulting signature is stored in the container registry alongside the image — no external key management infrastructure required for keyless flows.

Key-Based Signing for Air-Gapped Environments

In IL5 or classified environments where OIDC federation to Sigstore's Fulcio/Rekor is unavailable, key-based signing with private key management is the pattern:

# Key generation (done once, stored in AWS Secrets Manager or Vault)
cosign generate-key-pair

# Sign with private key
cosign sign --key cosign.key $REGISTRY/$IMAGE_NAME:$TAG

# Verify in Kubernetes admission controller
cosign verify --key cosign.pub $REGISTRY/$IMAGE_NAME:$TAG

For air-gapped deployments, Rutagon operates an internal Rekor-compatible transparency log using Rekor deployed within the program boundary — maintaining the immutable audit trail without egress to public transparency infrastructure.

Policy Enforcement with Admission Controllers

Signing without enforcement is security theater. Rutagon integrates policy enforcement at the Kubernetes admission layer using Kyverno or Gatekeeper (OPA):

# Kyverno policy — require Cosign-signed images in production namespace
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-image-signature
      match:
        resources:
          kinds:
            - Pod
          namespaces:
            - production
            - staging
      verifyImages:
        - image: "$REGISTRY/*"
          key: |-
            -----BEGIN PUBLIC KEY-----
            <base64-encoded-public-key>
            -----END PUBLIC KEY-----

This policy causes the Kubernetes API server to reject any Pod admission request where the container image hasn't been signed by the program's Cosign key — regardless of how the image reaches the cluster.

SLSA Provenance Generation

Container signing addresses image integrity. SLSA (Supply-chain Levels for Software Artifacts) provenance addresses the build process itself — proving that the build ran in a trusted environment from a specific source commit.

Rutagon generates SLSA Level 3 provenance for federal deliverables:

# GitHub Actions / GitLab equivalent — SLSA provenance
- name: Generate SLSA provenance
  uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1
  with:
    image: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
    digest: ${{ steps.build.outputs.digest }}
    registry-username: ${{ secrets.REGISTRY_USERNAME }}
    registry-password: ${{ secrets.REGISTRY_PASSWORD }}

The resulting provenance attestation documents: the build inputs, environment, builder identity, and output digest — all cryptographically signed. This provides ATO auditors with machine-verifiable evidence that images reaching production came from authorized, audited CI runs.

ATO Evidence Collection

Container signing generates durable ATO evidence for multiple NIST controls:

| Control | Evidence Generated | |---|---| | CM-14 | Signed image OCI manifest + transparency log entry | | SA-12 | SBOM attestations attached to each image | | SI-7 | Admission controller policy enforcement logs | | AU-9 | Immutable Rekor log entries (tamper-evident) | | RA-5 | Vulnerability scan results as signed attestations |

These artifacts are automatically archived to S3 in the program boundary with access logging and immutable object lock — satisfying NIST AU-9 and the audit log requirements for most ATO packages.

Integration with Platform One Pipelines

For DoD programs on Platform One or using Iron Bank-sourced containers, Rutagon's signing workflow verifies upstream Iron Bank signatures before re-signing for program-specific deployments:

# Verify Iron Bank provenance before use
cosign verify \
  --certificate-identity-regexp ".*ironbank.*" \
  --certificate-oidc-issuer "https://kubernetes.io" \
  registry1.dso.mil/ironbank/opensource/nginx/nginx:1.25

# Re-sign for program registry with program key
cosign copy \
  registry1.dso.mil/ironbank/opensource/nginx/nginx:1.25 \
  $PROGRAM_REGISTRY/nginx:1.25
cosign sign --key cosign.key $PROGRAM_REGISTRY/nginx:1.25

This chain-of-custody approach — Iron Bank source verification → program-specific re-sign → admission enforcement — satisfies platform and program ATO requirements simultaneously.

Container image signing is one layer of a comprehensive supply chain security posture. For programs requiring end-to-end supply chain integrity from source to production, Rutagon delivers the full SLSA framework implementation alongside the existing DevSecOps pipeline capabilities.

Discuss supply chain security requirements with Rutagon →

Frequently Asked Questions

What is the difference between Cosign and Sigstore?

Sigstore is the open-source project umbrella that includes Cosign (the signing tool), Fulcio (the certificate authority), and Rekor (the transparency log). Cosign is the primary CLI tool developers use for signing and verifying container images. For federal programs, Sigstore provides the trust infrastructure while Cosign is the day-to-day operational tool.

Does keyless signing work in air-gapped government environments?

Standard keyless signing requires connectivity to Sigstore's public Fulcio and Rekor infrastructure, which isn't available in air-gapped IL5 or classified environments. Rutagon deploys an internal Rekor instance within the program boundary for classified programs, enabling transparency log functionality without external egress. Key-based signing with internal key management is also used when a self-hosted Rekor isn't feasible.

What NIST controls does container signing satisfy?

The primary controls addressed are CM-14 (Signed Components), SA-12 (Supply Chain Risk Management), and SI-7 (Software Integrity). Depending on configuration, the associated audit logs can contribute to AU-2 and AU-9 control satisfaction. Programs with cATO requirements particularly benefit from the automated, machine-verifiable evidence container signing generates.

How does container signing integrate with Kubernetes?

Admission controllers (Kyverno or OPA/Gatekeeper) enforce image signing policies at the Kubernetes API layer. A ClusterPolicy or ConstraintTemplate is configured with the trusted public key, and the admission controller verifies signatures before allowing Pod creation. Unsigned or improperly signed images are rejected before they can run — this is the enforcement mechanism that makes the signing requirement meaningful.

Can container signing satisfy CMMC Level 2 supply chain requirements?

Container signing directly addresses NIST 800-171 control 3.13.13 (employ cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission) when applied to container delivery pipelines, and contributes to 3.14.1 (identify, report, and correct system flaws). For CMMC Level 2 C3PAO assessments, Rutagon provides documentation mapping specific Cosign implementation details to the required 110 controls.