The "Sealed Box" Myth of CI/CD — Did the Tests Really Run on That Image?
Container images are trusted on the assumption that "build once, run anywhere the same way." Code that passes your test suite gets packaged into an image, pushed through a registry, and delivered to your Kubernetes cluster. That's the basic shape of a CI/CD pipeline.
But there's a question most teams overlook: is the image your cluster is actually running the exact same build artifact your CI pipeline tested? Without a mechanism to verify container image signing, there's no way to answer that question with confidence.
CNCF's work on software supply chain security points out that as open-source components, container images, Helm charts, and third-party CI/CD actions pile up, the dependency surface area grows — increasing the need for SBOMs, artifact signing, provenance tracking, and vulnerability scanning (CNCF Blog). Your test safety net says nothing about the legitimacy of the image that ships afterward.
Anyone Can Rewrite an Image Tag. Why Pinning to a Digest Alone Isn't Enough
Not just :latest — even a version tag like v1.2.3 can be overwritten by anyone with write access to the registry. A tag is just a pointer; it guarantees nothing about the identity of the content behind it.
The common defense against this is pinning to an image digest (sha256:...). Since a digest is computed from the image's actual content, any change to the content changes the digest, making tampering detectable. According to Sigstore's official documentation, Cosign signatures are bound to a container image using either a local key pair or a key managed by a cloud KMS, and stored in the registry via the OCI 1.1 referrers specification (Sigstore Docs).
But digest pinning alone can't prove who built the image or which CI pipeline it passed through — that's a provenance question, not an integrity question. Tamper detection (integrity) and provenance proof are two separate problems, and solving the latter requires signing and signature verification.
Enforcing "Reject Unsigned Images" with Sigstore (Cosign) and Kyverno
The combination that plays the central role in actually enforcing container image signing on a cluster is Sigstore's Cosign paired with Kyverno.
Cosign supports signing with a key pair, as well as "keyless signing," which binds a short-lived certificate to an OpenID Connect identity. Every signing event is recorded in a transparency log (Rekor), so who signed what, and when, remains verifiable after the fact.
To enforce signed images at the cluster level, you use Kubernetes' admission controller mechanism. Kubernetes' official documentation describes ImagePolicyWebhook, which validates an image via an external webhook before a Pod is allowed to run, letting cluster administrators permit only approved images (Kubernetes documentation).
In practice, teams increasingly reach for the policy engine Kyverno as a more flexible option. According to Kyverno's official documentation, its verifyImages rule can validate Sigstore or Notary signatures, and supports pattern-based image matching, registry credential management, and TTL-based caching of verification results (Kyverno documentation).
A further step up is the SLSA (Supply-chain Levels for Software Artifacts) framework. Run by the Linux Foundation and OpenSSF, it defines requirements — such as isolated build environments and signed provenance — across a series of levels, giving organizations a shared vocabulary for deciding how hardened their supply chain needs to be (SLSA official site). ArgoCD, for instance, has reportedly achieved SLSA Level 3 across source, build, and provenance (CNCF Blog).
Combining these pieces lets you build a defensive layer at the cluster's entry point: any unsigned image, or any image that fails verification, is refused as a Pod.
Building this setup from scratch for your CI/CD pipeline takes real operational know-how — key management, policy design, and tuning verification caches, among other things. A managed K3s service like Kubo lets you start with this kind of security layer already built into the operating foundation.
Fitting This into K3s/GitOps Operations
Verifying container image signatures fits naturally into a GitOps workflow with minimal added operational burden. The GitOps philosophy treats a Git repository as the single source of truth for desired state, with a controller continuously comparing and reconciling the running state against what's defined in Git (Argo CD documentation).
K3s, a lightweight Kubernetes distribution, is designed to run as a single binary suitable for production use even at the edge or on IoT devices (K3s official site). Building on that lightweight footprint, a practical division of labor emerges: CI builds and signs the image, while CD (ArgoCD or Flux) combines with Kyverno's verification policies to handle deployment.
If you want to automate image updates themselves, there are tools that watch a registry and, when a new image is published, commit the corresponding change to Git or update application definitions (argocd-image-updater). When adopting a tool like this, the key to preserving supply chain safety is designing it not as "deploy immediately when a new image arrives," but as "only auto-update to images that have passed signature verification."
Kubo ships with ArgoCD/Flux integration built in, so you can start wiring signature verification policies into your GitOps pipeline right away. Being able to build this security layer in from the design stage — rather than bolting it on later — while keeping K3s-based costs more than 40% lower than comparable EKS/AKS setups, is one of the real advantages of a managed service.
Summary
The instinct that "code passing tests means it's safe" quietly skips several verification steps the moment it gets repackaged as a container image. Tags can be rewritten, digest pinning only catches tampering, and proving provenance requires a separate layer: signing and verification.
Signing with Sigstore (Cosign), enforcement via a Kyverno admission controller, and a staged benchmark like SLSA — combined, these let you shift from "it's safe because it runs" to "it's safe because it's verifiable."
You don't have to keep wrestling with the high cost, complexity, and vendor lock-in of EKS/AKS. Kubo, built on K3s, delivers full-featured Kubernetes plus a GitOps workflow that includes this kind of supply chain security layer — cost-effectively. If you're looking to build container image signature verification into your own CI/CD pipeline, start with a conversation about your operational design via our contact page.