1. Have You Stopped Thinking Once You Added a Scanner?
When teams try to formalize container security guidelines, many stop at "we introduced an image scanning tool." But installing a scanner and actually blocking a deployment based on its results are two completely different things.
Running on the latest tag, running containers as root, scans that run in CI but whose alerts nobody reads, and running images without signature verification at all — if even one of these applies to your setup, you risk introducing exactly the kind of known vulnerabilities described in NIST's Application Container Security Guide into production without ever passing a real verification gate. Lightweight Kubernetes distributions like K3s (official K3s documentation) are appealing because they're easy to set up, but that ease of setup must never become an excuse to skip security steps.
As a side note, plenty of teams say they simply don't have the capacity to build and operate all of this themselves. Using a managed K3s environment like Kubo as your foundation frees up that effort to focus on security design itself.
This article organizes the four gates a container image must pass through before it reaches production — minimal base images, vulnerability scanning, signing, and admission control — into a checklist you can use directly in practice.
2. Narrow It Down at Build Time — Minimal Base Images and Removing Root
The foundation of container security comes down to what you don't include in the image. The attack surface grows in direct proportion to the number of files and binaries present inside the image.
Google's distroless project provides minimal base images that exclude shells and package managers entirely, and Kubernetes itself has adopted this approach starting with v1.15. Multi-stage builds let you strip compilers and toolchains needed only for the build out of the final image completely. On top of that, explicitly setting USER in your Dockerfile to make non-root execution the default is a fundamental measure for reducing privilege escalation risk.
The same principles apply just as well to K3s clusters as to standard Kubernetes. If anything, the benefit of trimming risk at build time is even larger in environments like edge and on-premises deployments, where patch cycles tend to stretch out longer.
3. Catch It Before the Push — Vulnerability Scanning and SBOM Generation
Even after narrowing down your base image, known CVEs in your application's own dependency libraries are unavoidable. What's needed here is making the pre-push scan function as an actual gate in your CI pipeline, not just a report.
The open-source Trivy scanner detects CVEs and misconfigurations across container images, IaC configurations, and Kubernetes manifests, and its ease of CI integration has made it widely adopted. What matters isn't just "running a scan" — it's designing the pipeline so the build itself fails when Critical or High severity vulnerabilities are found. Without that, scan results end up as nothing more than a log nobody reads.
At the same time, generating an SBOM (Software Bill of Materials) for every image is essential. The two major SBOM standards are CycloneDX and SPDX, both maintained as international specifications. Keeping an SBOM on hand means that when a new CVE is disclosed later, you can instantly identify which images contain the affected library, dramatically speeding up audit response and vulnerability triage.
4. Verify Before Deploy — Signing and Admission Control
Even after vulnerability scanning and SBOM generation are done, if the cluster can't confirm that an image is genuinely the one that passed CI, there's still room for a tampered image — or one that skipped scanning entirely — to slip through. This is where the combination of signing and admission control comes in.
Cosign is a tool for attaching a digital signature to images built in a CI pipeline, and it also supports keyless signing that removes the need for key management. Signing alone doesn't accomplish much — it only becomes effective when paired with a mechanism that mechanically enforces a policy on the cluster side rejecting any unsigned image.
Admission controllers like Kyverno and OPA Gatekeeper take on this role. They evaluate policy at the Kubernetes API layer and reject any Pod creation request that doesn't meet the criteria. Because enforcement happens mechanically on the cluster side rather than relying on individual CI operators' diligence or oversight, you structurally prevent the accident where an image that slipped past scanning quietly ends up in production.
Maintaining signature verification and admission policies over time takes a meaningful amount of ongoing operational effort. In Kubo's K3s-based environment, automated certificate management via cert-manager and monitoring via Prometheus/Grafana come built in standard, which reduces the surrounding operational load and lets you focus that effort on policy design itself.
5. Summary — Bringing the Four Gates Into Your K3s Operations
The four gates covered here — minimizing the base image, vulnerability scanning and SBOM generation, signing, and policy enforcement via admission control — are each insufficient on their own; they only function when chained together as a continuous pipeline. Runtime anomaly detection after a container starts running is out of scope for this article, since it belongs to a different defensive layer than the supply chain, and deserves its own dedicated treatment.
Building and maintaining this entire mechanism from scratch takes no small amount of effort — CI configuration, scanner operations, certificate and key management, and ongoing maintenance of admission controller policies. For organizations in regulated industries like finance or healthcare that need to keep their image supply chain management fully in-house for compliance reasons, Kubo On-Premise's air-gapped support is worth considering as an option. Take a moment to check whether your own container security practice has stalled at "we run a scanner, so we're fine" — run it against these four gates and see where it stands. If you'd like to discuss adoption, reach out via our contact page.