Container Supply Chain Security: Scan, Sign & Safeguard Images

Introduction

Let’s face it - containerized environments can be a double-edged sword. They streamline development, enable rapid iteration, and boost cloud-native scalability. But with great power comes great responsibility, especially when it comes to securing what’s inside those containers. As we head further into 2025, it’s clear that container supply chain security isn’t just a CISSP-certified buzzword anymore - it’s a core requirement.

In this guide, I’ll walk you through how to truly safeguard your container builds from the inside out. We’ll break down the key steps that help prevent breaches: scanning images for vulnerabilities using tools like Trivy and Grype, signing and verifying those images with Cosign, generating and validating SBOMs, and enforcing deployment checks with Kubernetes admission controllers. Whether you’re running a few pods or managing an enterprise-scale fleet of Kubernetes clusters, this walkthrough will arm you with the practical, real-world security essentials you need.

Why Container Supply Chain Security Matters (Now More Than Ever)

Here’s what’s changed: container usage isn’t niche anymore. It’s mainstream. Nearly every CI/CD pipeline now pushes container images multiple times per day, often pulling them from public registries or integrating open-source components with unknown histories. That means you’re relying on (and deploying) software you didn’t build yourself.

These are the common weak points:

• Vulnerable images: Outdated packages, unpatched exploits, or unintentional secrets in code.
• Image spoofing or tampering: Without signature validation, it’s easy to pull a fake or malicious image named like a trusted one.
• Opaque dependencies: Most orgs don’t have visibility into the true contents of their containers - until something breaks or gets exploited.
• Weak runtime admission controls: Even if your pipeline signs and scans images, are your clusters verifying that before giving them a home?
• Insecure registries: These should be vaults, not open drawers. But often they’re not properly isolated or monitored.

With cyber threats growing and regulators paying closer attention (especially post-Executive Order 14028), focusing solely on runtime security isn’t enough. Today, we must lock down the entire container lifecycle - from base image origin to deployment verification.

Scanning Containers with Trivy & Grype: Start Clean

When I work with teams new to DevSecOps, the first thing I ask is: “Do you scan every image before it touches staging or production?” Nine times out of ten, they say no - or they say yes but rely on just one tool passively. That’s where Clarity starts: early, automated CVE detection.

Trivy: Good for Fast, Local, and Broad Coverage

I personally like Trivy for its simplicity. It scans a wide range of components inside a container, including OS libraries and app dependencies, and even flags misconfigurations or exposed secrets.

Here’s how you’d use it for critical issues only:

trivy image --severity HIGH,CRITICAL my-app-image:latest

It’s great for quick local tests or pre-commit hooks too. Trivy also integrates straight into GitHub Actions, GitLab CI, and most major DevOps platforms with zero friction.

Grype: Enterprise-Friendly and SBOM-Aware

If your team relies heavily on build automation (and you should), Grype complements Trivy well. It ingests SBOMs directly, outputs structured JSON for parsing, and scales better for policy-based enforcement.

For example:

grype my-image:1.2.3 -o json > scan-report.json

Use it alongside Grype’s companion project Syft to scan more granular layers or components.

My Take on Best Practices

• Use both tools in parallel - each catches things the other might miss.
• Plug them into your CI so they gate deployments automatically.
• Customize severity filters - don’t block on low-level warnings.
• Track your scan results historically and tie into a dashboard or ticketing system for follow-up.

Signing Images with Cosign: Don’t Trust It, Verify It

Here’s the deal - if you’re pulling unsigned images into production, you’re gambling. Without a cryptographic signature, there’s zero guarantee an image wasn’t tampered with somewhere between build and deploy.

Why Cosign?

Backed by Sigstore, Cosign is light, fast, and doesn’t require managing complex PKI chains. You can sign images with your own key pair or a company-wide key from your cloud KMS provider.

Example signing:

cosign sign --key ./keys/cosign.key my-image:v1.5.2

Verification is just as straightforward:

cosign verify --key ./keys/cosign.pub my-image:v1.5.2

This ensures that what you’re deploying hasn’t been spoofed or altered.

Make Signing Automatic

Here’s the step many teams miss: wiring Cosign into their pipeline. Set it up so that no unsigned image ever reaches your registry. Also, rotate those signing keys regularly (at least quarterly), store them securely - preferably in a vault or HSM - and make sure your team understands who owns which keys.

Bonus tip: Cosign can sign both the image and its associated SBOM.

SBOMs: Shine a Light Inside Your Containers

Imagine trying to handle a Log4Shell-type event without knowing which containers use what libraries. That’s a nightmare we’ve all seen in the last few years. SBOMs (Software Bill of Materials) solve that exact problem.

Why You Need SBOMs

• When there’s a new 0-day, you can quickly figure out which containers are impacted.
• Auditors and compliance teams increasingly expect SBOM availability.
• Dev and security teams need a clue what’s really bundled inside app containers.

Generating SBOMs with Syft

Syft is my go-to tool for generating SBOMs. It’s Dev-friendly and can export to SPDX, CycloneDX, and other standard formats.

Here’s the basic syntax:

syft myapp:latest -o spdx-json > sbom.json

Store this sbom.json file alongside the image - either in your Git repo or embedded in the registry as image metadata.

Using SBOMs Effectively

• Attach SBOMs to signed images in your registry.
• Validate SBOM presence/content during Kubernetes admission reviews.
• Use SBOM diffing to detect when unexpected components sneak into builds.
• Bridge between SBOMs and your CVE databases to automate exposure checks.

Admission Controllers: The Enforcers on Your Team

Once you’re scanning and signing, it’s time for enforcement - and that’s where admission controllers come in. These are essentially Kubernetes guards that decide: “Is this image safe to run?”

Options You Can Use

• OPA Gatekeeper: Uses Rego for rich, programmable policy logic.
• Kyverno: Easier to write (with YAML-based rules), solid for most use cases.
• Cosign Webhook: Purpose-built to verify signed images at admission time.

Say you want to block pods running unsigned images. With Kyverno, a policy could look like this:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
 name: require-signed-images
spec:
 rules:
 - name: verify-signature
 match:
 resources:
 kinds:
 - Pod
 verifyImages:
 - image: "*"
 key: "cosign.pub"

This enforces that all incoming pods use images signed with a valid key.

Real Talk: Don’t Enable Blocking Overnight

I’ve seen teams deploy admission policies too aggressively and bring down dev environments accidentally. Always start in audit mode, review violations, and then ramp up enforcement after stakeholders are trained and informed.

Hardening Your Container Registries

Here’s something a lot of folks overlook: your registry is the source of truth for every runtime workload. If someone sneaks a malicious image into your registry - or hijacks a service account to overwrite a legit one - you’re deploying poison.

Registry Security Must-Haves

• Strict auth & authorization: No anonymous pushes. Ever.
• TLS all the way: Encrypt everything in transit and at rest.
• Scan-on-push/pull: Trigger vulnerability scans automatically.
• Signed image enforcement: Don’t let unsigned artifacts linger in production-stage repos.
• Immutable tags: Disable overwriting of tags like latest in critical repos.

Trusted Providers with Security in Mind

If you’re using:

• Docker Hub Pro/Team, JFrog Artifactory, or Harbor - enable RBAC, scan hooks, and signed image verification.
• Cloud registries (ECR, GCR, ACR) - leverage built-in IAM policies, logging, and encryption.

Also, don’t forget to audit your registry access logs regularly. If something suspicious is happening - like nightly overwrites of images via unmonitored accounts - you want to know before it becomes incident response time.

Common Pitfalls & Fixes

Gotchas I’ve Seen in the Wild

Quick Security Checklist

Use this for internal audits or CI/CD health checks:

• Are all images scanned (Trivy/Grype) before getting deployed?
• Are images signed during the build process (Cosign)?
• SBOMs generated and stored with each artifact?
• Admission controllers verifying image signatures and scan thresholds?
• Registry access tightly controlled, scanned, and logged?
• Image tags immutable in critical repos?
• Teams trained in vulnerability triage and signature workflow?

Want to Dig Deeper?

Here are some must-read resources and tools I personally recommend:

• Sigstore - For managing image signing at scale
• Trivy Scanner by Aqua
• Grype + Syft by Anchore
• Kyverno - Easier Kubernetes policy engine
• OPA Gatekeeper
• INFOiYo: Rootless Containers for Deployment Security
• INFOiYo: Docker Security Best Practices

Final Thoughts

Securing your container supply chain isn’t something you bolt on after deployment. It’s something you build in - from the moment you write a Dockerfile to the second the image hits production.

My advice? Invest in the tools and processes that automate trust. Know where your images come from, what’s inside them, and who signed off. That’s how you avoid becoming tomorrow’s cautionary headline.

Keep your containers clean, your signatures verified, and your registries guarded. The attackers aren’t going away - but with the right setup, neither is your peace of mind.

Safe shipping.