A cluster can pass every container image scan and still get breached through the Kubernetes control plane itself. That's what happened with CVE-2025-1974, an unauthenticated remote code execution flaw in the ingress-nginx admission controller disclosed on March 24, 2025, carrying a CVSS score of 9.8. Wiz researchers found more than 6,500 internet-exposed clusters running the vulnerable admission webhook — clusters whose container images may have scanned clean while the orchestration layer around them was wide open. This is the gap that pure image-scanning tools, including Anchore's Grype and Syft-based stack, routinely miss: Kubernetes vulnerability scanning has to cover the API server, kubelet, etcd, RBAC bindings, admission controllers, and CIS Benchmark drift, not just the contents of a container layer. For teams pursuing SOC 2, FedRAMP, or PCI DSS 4.0 attestation, that gap is exactly where auditors start asking uncomfortable questions. Here's what's actually different about scanning Kubernetes, and how to close the gap before an auditor — or an attacker — finds it.
What Makes Kubernetes Vulnerability Scanning Different From Container Image Scanning?
Kubernetes vulnerability scanning has to assess the orchestration layer — API server configuration, RBAC bindings, etcd encryption, kubelet permissions, and admission control — while image scanning only inspects package manifests inside a container layer. A tool like Grype (Anchore's open-source scanner) will tell you that a base image ships OpenSSL 3.0.7 with a known CVE. It will not tell you that your cluster's kubelet is exposing an unauthenticated read-only port on 10255, that a ClusterRoleBinding grants cluster-admin to a default service account, or that your ingress-nginx admission webhook is reachable from outside the cluster network — the exact misconfiguration CVE-2025-1974 exploited. The CIS Kubernetes Benchmark v1.9, published in November 2024, lists over 100 control checks across five categories (control plane, etcd, worker nodes, policies, and managed services) specifically because image hygiene and cluster hygiene are separate failure domains. A scanner scoped to SBOMs and OS packages structurally cannot evaluate most of that list.
How Many Kubernetes Vulnerabilities Were Disclosed Recently, and Which Ones Actually Matter?
Kubernetes and its adjacent ecosystem (ingress controllers, CNI plugins, admission webhooks) had at least a dozen high-or-critical CVEs disclosed between 2023 and 2025, and three of them are worth naming because they map directly to real breach paths. CVE-2025-1974 (CVSS 9.8) let any pod on the cluster network trigger arbitrary code execution on the ingress-nginx controller with no authentication. CVE-2024-9042 (CVSS 9.8) affected the Windows kubelet, allowing command injection through a crafted log query parameter — patched in Kubernetes 1.31.3, 1.30.7, 1.29.11, and 1.28.15, released November 2024. CVE-2024-3177 exposed a bypass in the ImagePolicyWebhook admission controller that let attackers deploy unapproved images despite an active image-policy enforcement rule, undermining exactly the kind of "trusted registry only" control that compliance frameworks assume is working. None of these are container-image CVEs. All three would sail through a workload-only scan and only surface when the scanning tool understands live cluster state — API objects, RBAC, admission chain configuration — not just image layers.
Why Do Compliance Audits Fail Even When Image Scans Pass?
Compliance audits fail on Kubernetes environments because auditors under SOC 2, PCI DSS 4.0, and FedRAMP increasingly ask for cluster-level evidence — RBAC least-privilege proof, network policy enforcement, admission control configuration, and audit log retention — not just a clean CVE report on your images. PCI DSS 4.0 became fully enforceable on March 31, 2025, and its requirement 6.3.2 for maintaining an inventory of software components applies to the cluster's own control-plane components, not only application containers. A team can present a spotless Anchore or Grype scan of every deployed image and still fail an audit because they can't produce evidence that system:masters isn't bound to more principals than necessary, that etcd is encrypted at rest, or that the last CIS Benchmark run was within the audit period. In practice, auditors want a continuously generated, timestamped record — not a one-time scan result — because SOC 2 Type II specifically tests controls "over a period of time," typically 3 to 12 months. Point-in-time image scans don't produce that kind of evidence trail on their own.
Where Does Anchore Fall Short for Kubernetes-Native Environments?
Anchore's core products — Anchore Enterprise, plus the open-source Syft (SBOM generation) and Grype (vulnerability matching) — are built around the container image as the unit of analysis, which means Kubernetes-specific risk sits outside their native scope. Anchore Enterprise does offer Kubernetes inventory and policy features, but its vulnerability detection still resolves to image and package data; it doesn't independently assess API server flags, kubelet TLS configuration, or admission webhook reachability the way a CIS Benchmark-aware or kube-bench-style engine does. Teams running Anchore commonly end up bolting on a second tool (kube-bench, kube-hunter, or a cloud-native CSPM) to cover cluster configuration, which means two separate findings pipelines, two remediation backlogs, and two sets of evidence to reconcile for an auditor. That split is itself an audit risk: when image findings live in one system and cluster findings live in another, producing a single coherent risk narrative — the thing an assessor actually wants — becomes a manual, error-prone exercise done right before the audit window closes.
What Does an Audit-Ready Kubernetes Vulnerability Scanning Program Actually Look Like?
An audit-ready program combines continuous image scanning, CIS Kubernetes Benchmark v1.9 checks, RBAC analysis, and admission-control validation in one pipeline that produces time-stamped evidence automatically, rather than a scramble of exported CSVs the week before an assessment. Concretely, that means: scanning every image at build and at a fixed re-scan interval (commonly every 24 hours) so newly disclosed CVEs like CVE-2025-1974 are caught against already-deployed workloads, not just new builds; running CIS Benchmark checks against live cluster state on a schedule that matches the audit period (SOC 2 Type II typically spans 3-12 months, so evidence needs to span that same window); mapping every finding to the specific control it satisfies (PCI DSS 4.0 clause, SOC 2 trust services criterion, NSA/CISA Kubernetes Hardening Guidance v1.2 recommendation) so an auditor doesn't have to translate a raw CVE list into control language themselves; and retaining remediation history, not just current state, since SOC 2 Type II auditors sample historical periods. Programs that miss any one of these four pieces typically end up with either an incomplete risk picture or an audit that runs long because evidence has to be reconstructed manually.
How Safeguard Helps
Safeguard was built to close exactly the gap described above: one pipeline that scans container images, evaluates live Kubernetes cluster configuration against the CIS Kubernetes Benchmark, and maps every finding to the compliance control it affects, so image risk and cluster risk stop living in separate tools with separate backlogs.
On the scanning side, Safeguard continuously re-scans deployed images against updated CVE feeds — so when a vulnerability like CVE-2025-1974 or CVE-2024-9042 is disclosed, workloads already running in production are flagged within your re-scan window, not just future builds. On the cluster side, Safeguard evaluates RBAC bindings for over-permissioned service accounts, checks admission controller reachability and configuration, verifies etcd encryption and API server flags against CIS Benchmark v1.9 controls, and surfaces drift the moment a cluster configuration change introduces risk.
For audit prep specifically, Safeguard generates continuous, timestamped evidence rather than point-in-time reports, and maps each finding directly to the SOC 2 trust services criterion, PCI DSS 4.0 requirement, or FedRAMP control it satisfies — so when an assessor asks for proof that a control operated effectively over the audit period, the evidence already exists instead of needing reconstruction. Remediation history is retained automatically, matching the historical sampling that SOC 2 Type II and similar audits require.
Where tools built around SBOM and image analysis leave Kubernetes-specific risk to a second product, Safeguard treats the image and the cluster as one connected attack surface — because as CVE-2025-1974 demonstrated, that's exactly how attackers treat it. If your current scanning stack tells you your images are clean but you can't produce a current CIS Benchmark report or a control-mapped evidence trail on demand, that's the gap worth closing before your next audit window opens.