Kubernetes-related threat-actor operations climbed 282% over the past year and 22% of cloud environments showed service-account-token theft activity in 2025, per Unit 42's April 2026 threat report on Kubernetes environments. Many Kubernetes incidents involve a mix of misconfiguration, vulnerable workloads, identity abuse, or runtime exploitation. Strong Kubernetes security posture management catches the first; only a hardened image catalog closes the second, and the work has to be divided between teams.
This guide is the architectural framework for that divide. It defines what posture catches and what it misses. It draws the boundaries where admission policy and runtime detection each take over. And it specifies how platform, security, and application teams should split the controls so nothing falls between desks. This guide explains how platform, security, and application teams can divide responsibilities across KSPM, hardened image catalogs, admission policy, and runtime detection.
Key Takeaways
Kubernetes Security Posture Management: Definitions That Match How Engineers Actually Work
Kubernetes security posture management (KSPM) is the continuous monitoring of cluster and workload configuration against a rules baseline, with alerts when settings drift or violate policy. That is the engineer's mental model. It is not the marketing definition that every vendor cyberpedia uses ("comprehensive cloud-native security framework"); it is the working definition that maps to the dashboard a platform team actually opens on Monday morning.
Posture is one of six controls a Kubernetes program runs. Each has a different boundary. The unified controls matrix below is the spine of the rest of this guide; every section below advances one row or one column.
Six controls, four boundaries. KSPM and image security overlap, and that overlap is where work falls through if no one owns it.
A 4-7 word vendor primer for first-mention orientation: Wiz is a CNAPP suite and the leader in KSPM cyberpedia content. CrowdStrike Falcon Cloud Security is a CNAPP with KSPM, admission control, and runtime modules. Palo Alto Prisma Cloud is a CNAPP with the most thorough KSPM cyberpedia entry. Dynatrace is an observability platform with a KSPM module. Cast AI is a Kubernetes cost-optimization vendor that added automated KSPM in September 2025. ARMO Kubescape is open-source KSPM with a paid SaaS layer. Chainguard is the container security vendor that pioneered Wolfi-based hardened images. Docker DHI is Docker Hardened Images, free under the Apache 2.0 license since December 17, 2025. Iron Bank is the DoD's hardened-image registry at repo1.dso.mil/dsop. Kyverno and OPA Gatekeeper are the two open-source policy engines for Kubernetes admission control. Falco is the CNCF-graduated open-source runtime threat detection project, eBPF-based.
The OWASP Kubernetes Top 10 (2025) is the canonical risk taxonomy. Mapping it across four discrete controls is what makes the join between posture and image security concrete:
Posture and image security overlap on K01 and K07. Per the Red Hat State of Kubernetes Security 2024 report, 45% of incidents involve a misconfigured Kubernetes cluster, and most of those clusters are also running images with package-level CVEs. The overlap is where work falls through if no one owns it. Sections 5 through 7 are how that ownership gets fixed.
KSPM is part of CNAPP for vendors that sell suites, but CNAPP is not the only place KSPM lives. Open-source Kubescape, observability-anchored Dynatrace KSPM, and cost-optimization-anchored Cast AI all ship KSPM independent of a full CNAPP. The category matters less than the rule pack; what catches a misconfiguration is the same regardless of which suite it ships under.
KSPM dashboards turn red because an openssl CVE was published this morning. The KSPM tool can flag every running pod that includes the vulnerable version. It cannot patch openssl. The patch lives in the base image, and the only durable fix is a base-image swap.
A typical chain: KSPM reports payments-api pod runs OpenSSL 3.0.7, CVE-2024-XXXX, CVSS 9.8. The pod is built from python:3.12-slim (Debian). The runtime is healthy; admission policy passed. The fix is not a KSPM rule. It is a Dockerfile change from python:3.12-slim to a hardened equivalent (cgr.dev/chainguard/python:3.12, a dhi.docker.com/python digest, or an internal hardened registry path). Once the rebuild ships, the KSPM finding closes within 24 hours of the production deploy.
This is the join between posture and image security. KSPM is the dashboard that surfaces the work; the hardened image catalog is the surface that does the work. The skill is matching findings to fixes.
Chainguard's published numbers from its hardened-image research are the citable baseline. Popular Debian-based community images carry roughly 300 CVEs each. Package updates inside the same image reduce CVE counts by only about 5%. Debloating (removing every package not required to run the application) reduces CVEs by about 65%. Top 50 Iron Bank images carry around 110 CVEs. These numbers explain why "patch every package" is not a strategy and why "ship a smaller image" is.
The framing Chainguard coined as "start left, not just shift left" applies here. Shift-left means scanning earlier in the pipeline. Start-left means starting with a base image that does not have the CVE in the first place. Both layers help. The latter is what closes the package-debt half of the work that KSPM cannot.
The cost objection that gated catalog adoption for years is gone. Docker Hardened Images went free under the Apache 2.0 license on December 17, 2025, and the OSS catalog now reports 500,000 daily pulls across 2,000-plus images. The cheapest entry path is a free catalog from a well-resourced vendor; the cheapest exit is no longer "build it yourself." The hardened container images foundation guide walks the catalog-evaluation pattern in more depth.
The remaining question is enforcement. Once the upgraded image lives in the catalog, how do you make sure it is the one that actually runs?
Admission control is the bridge between the image-policy layer and the cluster-policy layer. The Kubernetes API server hands every create or update request to an admission chain; the controllers in that chain accept the request, mutate it, or reject it before the object lands in etcd. That is where "only hardened images run here" goes from a goal to an enforced rule.
The Kubernetes admission-controllers reference documents all of the built-in controllers. Kyverno and OPA Gatekeeper are the two open-source policy engines most teams pick; the choice between them is mostly about whether the security team prefers YAML-native policies (Kyverno) or Rego (OPA).
The signature artifact of this section is a working Kyverno policy that enforces both an approved-registry list and digest-pinning. A production version should be tested against your Kyverno version and registry naming conventions, but the policy shape looks like this:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-hardened-base-image
spec:
validationFailureAction: Enforce
background: false
rules:
- name: only-hardened-registries
match:
any:
- resources:
kinds:
- Pod
validate:
message: "Images must come from an approved hardened-image catalog (Docker DHI, Chainguard, Minimus, Iron Bank, or your internal hardened registry)."
pattern:
spec:
containers:
- image: "dhi.docker.com/* | cgr.dev/chainguard/* | images.minimus.io/* | registry1.dso.mil/ironbank/* | hardened.internal/*"
- name: require-digest-pinning
match:
any:
- resources:
kinds:
- Pod
validate:
message: "Image must be pinned by digest (sha256:...), not a tag."
pattern:
spec:
containers:
- image: "*@sha256:*"
The first rule restricts pods to images from a registry allowlist. The second rule requires every image to be pinned by digest, which is what makes the registry allowlist meaningful (a tag is mutable; a digest is not). For a transition, swap validationFailureAction: Enforce to Audit, run for one to two weeks against existing workloads, and triage the audit log before flipping back to Enforce. Forward the violations to a SIEM (Splunk, Elastic, Sumo, or Datadog) so the security team has the audit trail. The Kyverno admission controller guide for hardened base images walks the policy variants and rollout patterns.
Admission only sees what passes through the API server. Workloads already running are not in scope, and an attacker who exploits an in-memory weakness will not show up here. That is the seam runtime detection covers.
If KSPM is finding misconfig, hardened images shrunk the attack surface, and admission policy is enforcing both, do you still need runtime detection? Yes, but for narrower reasons. Three things runtime catches that the other layers cannot:
The right question is not "do you need runtime?" The right question is "for which workloads is runtime mandatory?" The decision tree:
EDR and runtime container security are not the same thing. EDR is endpoint-resident and watches whole hosts at the kernel and process level. Runtime container security operates inside the workload's namespace and tracks per-container behavior (which container did the bad syscall, which image, which pod, and which namespace). They overlap on the host but runtime adds the container-aware context auditors expect for K8s workloads. The container runtimes and isolation guide covers the mechanics underneath both.
With four discrete controls in play (KSPM, hardened images, admission, and runtime), the next question is who owns each one.
The failure mode is familiar. KSPM tool sends an alert. Security forwards it to Slack. Platform says "that is an image issue, ping the app team." App team says "we do not own base images." Six weeks later the alert is still open. The article's title is literally that question, so the responsibility matrix is the article's spine.
In many KSPM programs, “percentage of services on hardened bases” becomes a useful KPI because it connects posture findings to image remediation progress. That number is the lagging indicator for both halves of the work, because most posture findings tied to container image content go away when the base swaps. A vendor-neutral pattern for the hardened image catalog with SLA-backed remediation is documented separately.
You now know who. Next is how to track the work in one place.
Posture findings and image upgrades belong in the same backlog with a single owner per ticket, not in parallel queues. Parallel queues are where work falls between teams. A single owner per ticket is what closes the loop.
This is a Jira-style template that engineers can copy-paste:
TICKET TYPE: Posture-driven image fix
TITLE: [KSPM-CRIT] Pod running vulnerable openssl in payments-api / production
LINKED FINDINGS:
- KSPM finding: payments-api pod runs OpenSSL 3.0.7 (CVE-2024-XXXX, CVSS 9.8)
- Image source: payments-api:v1.42.3 built from python:3.12-slim (Debian)
- Admission policy: passed (image is from approved registry, signed)
- Runtime: no exploitation observed
ROOT CAUSE: base image (python:3.12-slim) ships with vulnerable openssl
FIX (assigned to App team):
- Update Dockerfile FROM line: cgr.dev/chainguard/python:3.12 (or DHI equivalent)
- Rebuild image, run integration tests
- Tag as v1.42.4, promote through dev -> staging -> prod
- Confirm KSPM finding closes within 24h of prod deploy
VERIFICATION (assigned to Security team):
- Confirm KSPM finding closes
- Confirm admission policy still passes
- Confirm runtime baseline unchanged
OWNER: app-team-payments
DEPENDS ON: hardened-image-catalog/python:3.12 SLA-compliant patched build
PRIORITY: derived from "blast radius x image debt" formula (see below)
SLA: critical = 7d, high = 14d, medium = 30d
priority = exposure_factor x privilege_factor x cve_severity x image_blast_radius where each factor is 1 to 4. A score of 192 (4 x 4 x 3 x 4) is "fix this week"; a score of 12 (1 x 3 x 2 x 2) is "fix in a sprint." The numbers are deliberate and the math is auditable, which is what compliance reviewers want when they ask how prioritization works.
A package comparison guide for what is actually inside your container image is useful when the app team asks that question before running the fix step. Most rebuild questions land there.
You now have the joint backlog. The closing question is how to sequence the first 200 findings so the team is not patching forever.
Most teams enter Year 2 of K8s in production with a recurring loop: same CVEs in same images, same misconfigs in new namespaces, and same Slack threads about who owns what. The four-step sequencing playbook below is how that loop breaks.
Day 0: Audit (1 day, security plus platform). Run kube-bench, Trivy, and Kyverno audit-mode policies across all clusters. Categorize findings into KSPM-only, image-only, runtime-only, and joint. Output: one spreadsheet with finding count per category per cluster. This is the baseline that every later step measures against.
Week 1: Catalog adoption (2 to 5 days, platform plus one pilot app team). Pick a hardened-image catalog (DHI Free is the cheapest entry point; a paid vendor like Chainguard or Minimus is the right answer for SLA-critical workloads). Mirror the catalog to your internal registry or pull-through cache. Migrate one pilot service. Measure the CVE reduction after migration, since results vary by image, workload, and scanner.
Week 4: Admission enforcement (1 to 2 weeks, security plus platform). Deploy Kyverno or OPA Gatekeeper in audit mode. Author the "require hardened base" policy from Section 3. After one week of audit, flip to enforce. Have a runbook for false positives. At this point, no new workload can deploy without a hardened base.
Quarter 1: Joint backlog cadence (ongoing, all teams). Implement the weekly joint posture review from Section 5. Adopt the joint backlog template from Section 6. Track the KPI per team. Close the loop: by end of Q1, the same CVE should not reappear in two consecutive cycles.
Do not try to swap every base image on Day 1. The operational risk is unhedged. Do not enforce admission on Day 1 either; you will block production deploys. The sequencing exists because the work has to be staged.
A hardened-image catalog with SLA-backed CVE remediation slots into this sequence at Week 1 and stays as the dependency the joint backlog leans on through Quarter 1.
Minimus publishes hardened, minimal container images based on upstream distributions, rebuilt on a frequent, automated cadence to absorb security updates quickly. Each image is delivered with a Cosign signature and an SBOM, with vulnerability-status information and a 48-hour critical CVE remediation SLA surfaced in the Trust Center. The Hardened Image Gallery is a digest-addressable catalog, with FIPS 140-3-ready variants and STIG-aligned scan attestations per image. Image Creator lets teams define private images on top of Minimus base images when the public catalog does not cover a specific runtime configuration, which becomes the preferred path when teams need custom-image dependencies.
For the sequencing playbook in Section 7, Minimus images sit at Week 1 (catalog adoption) and stay as the SLA-backed dependency through Quarter 1. Browse the catalog at images.minimus.io, read the verification guides at docs.minimus.io, or get started on a 30-day proof.
CSPM monitors the whole cloud account: IAM, storage, network, and compute at the cloud-provider layer. KSPM monitors the Kubernetes slice: clusters, RBAC, pod settings, NetworkPolicies, etcd, and audit logs. Most organizations need both, but KSPM is mandatory for any team running Kubernetes in production. The unified controls matrix in Section 1 lays out the boundaries.
KSPM is configuration-focused (pre-deploy plus post-deploy). CWPP is behavior-focused (post-deploy live). KSPM tells you "this pod is misconfigured." CWPP tells you "this pod is being attacked right now." They overlap on RBAC and service-account watching but live in different time domains. Section 4 has the full comparison and the example tools per category.
Cloud, Cluster, Container, and Code. It is Palo Alto's framework, and it has been generally adopted across the category. KSPM owns the Cluster and Container configuration layers; hardened images own the Container content layer; admission policy enforces the Cluster and Container boundaries; CSPM owns the Cloud layer; SAST and DAST tools own the Code layer. The four C's are useful as a label; the unified controls matrix in Section 1 is what tells you which tool catches which risk.
It is a shared job. Platform owns the tool, security owns the policy, application teams own the workload-level findings. The joint backlog template in Section 6 is how to make that split work without finger-pointing. The responsibility matrix in Section 5 is the artifact you send your CISO and your app-team leads when they ask who fixes what.
EDR is endpoint-resident and watches whole hosts (kernel, processes, and files at the host level). Container runtime security operates inside the workload's namespace and tracks per-container behavior (syscalls via eBPF and container-specific process trees). They overlap at the host but runtime adds the container-aware context auditors expect: which container did the bad syscall, which image, which pod, and which namespace. Most regulated environments need both.
For internet-exposed workloads, regulated environments (PCI, HIPAA, and FedRAMP), and PII, financial, or crypto data, yes. Runtime catches zero-days, token misuse, and lateral movement that posture and image security cannot prevent at deploy time. For internal-only batch jobs with low blast radius, runtime is optional but still recommended. Section 4 has the decision tree and the KSPM-vs-CWPP boundary table.
.svg)
.svg)
.svg)
.svg)
