Kubernetes and containerised workloads need vulnerability management that scans images, registries, and running clusters — not just the servers underneath them. Ephemeral pods and layered container images move faster than an annual penetration test can track, so the process has to run continuously and feed straight into your ISO 27001 or SOC 2 evidence, not sit in a spreadsheet until the next audit.
Why vulnerability management matters for Kubernetes teams
A typical container image pulls in hundreds of transitive dependencies you never chose directly. Every one of those packages is a potential CVE, and every rebuild introduces new ones.
Auditors reviewing ISO 27001:2022 Annex A 8.8 or SOC 2 CC7.1 in 2026 expect evidence of a running vulnerability management process for cloud infrastructure, not a single scan report from last year. Clusters that scale up and down by the hour make point-in-time scans close to meaningless — the pod an auditor asks about may not exist anymore.
For teams building on cloud-native infrastructure, that mismatch between how fast Kubernetes changes and how slow traditional vulnerability management moves is the whole problem. Fix the cadence and the compliance evidence follows on its own.
Scan every container image before it ships
Catch vulnerabilities at build time, before a bad image ever reaches a cluster.
- Run an open-source scanner like Trivy or Grype inside your CI pipeline
- Block builds automatically on critical, patchable CVEs
- Scan the base OS layer, not just your application code
- Pin dependency versions instead of floating to the latest tag
- Generate a software bill of materials (SBOM) per image, not per project
Verdict: do this first. It costs nothing but engineering time and stops the worst images from ever deploying.
Scan running clusters, not just build-time images
An image that was clean on the day it built can drift once it runs for weeks against new CVE disclosures.
- Deploy an admission controller or runtime scanner inside the cluster
- Check node-level OS packages, not only container layers
- Watch for privilege escalation paths in pod security configuration
- Alert on unexpected outbound pulls from unrecognised registries
- Re-scan long-lived pods on a fixed schedule, not only at deploy
Prioritise by exploitability and exposure, not CVSS score alone
A CVSS 9.8 finding on a pod with no internet exposure is a lower priority than a CVSS 6 finding sitting behind a public load balancer.
- Cross-reference findings against the CISA Known Exploited Vulnerabilities catalogue
- Flag internet-facing pods and services for faster remediation
- Check whether a vendor patch actually exists before setting an SLA
- Deprioritise vulnerabilities in packages your pods never load at runtime
- Use an SBOM diff to confirm which layers are actually executed
Compare the tools teams use for this step:
| Option | Best for | Pricing model | Key limitation |
|---|---|---|---|
| Trivy / Grype (open source) | Teams starting from zero | Free | No runtime detection, no audit mapping |
| Commercial CNAPP platforms | Large fleets needing continuous runtime scanning | Per-node subscription | Heavy setup, often overkill under 20 nodes |
| Cloud-native scanners (AWS, Azure, GCP built-ins) | Single-cloud teams | Usage-based | Locked to one cloud provider, weak cross-cloud view |
| Vulnerability and patch management tools for lean teams | Small IT and security teams covering servers and containers together | Subscription | Still needs a runtime layer for large clusters |
Patch and rebuild base images on a fixed cadence
CVEs do not wait for your sprint schedule, and neither should your patching.
- Rebuild base images on a set weekly or bi-weekly schedule
- Automate rolling restarts so patched images actually reach production
- Set a firm remediation SLA for critical CVEs, measured in days not sprints
- Track outstanding critical CVEs as an open backlog item, not a Slack thread
Verdict: automate this or it slips. Manual rebuild schedules get skipped the first busy release week.
Lock down cluster and registry configuration
A scanner will not catch a misconfigured RBAC policy or an open kubelet port — that is a separate check.
- Enforce least-privilege RBAC across namespaces
- Disable anonymous pulls on your container registry
- Enable image signing and verification before deploy
- Apply restricted pod security standards, not the default baseline
- Close exposed kubelet and etcd ports at the network layer
Track supply chain and third-party image risk
Most container CVEs in 2026 do not come from your own code. They come from base images and public packages pulled in without a second look.
- Maintain a live SBOM inventory across every image in production
- Vet public base images before adopting them, not after an incident
- Monitor upstream CVE feeds for the specific packages you depend on
- Review vendor-supplied images with the same scrutiny as your own
Automate evidence collection for auditors
This is where a manual process stops scaling. Screenshotting scanner dashboards every audit cycle is the biggest time sink teams hit once they reach their second or third certification.
- Map scan output directly to ISO 27001 Annex A 8.8 and SOC 2 CC7.1 control language
- Timestamp remediation automatically instead of hunting for evidence retroactively
- Retire the spreadsheet tracking which CVE, which pod, fixed when
- OneClickComply takes your existing scanner output and turns it into audit-ready evidence continuously, so vulnerability management for Kubernetes stops being a separate project every time an auditor asks for proof
Turn scan results into audit evidence
See how OneClickComply maps vulnerability data to ISO 27001 and SOC 2 controls.
Report remediation KPIs to engineering leadership
- Track mean time to remediate, split by severity band
- Report open critical CVEs per cluster, not one blended number
- Show the remediation trend over time, not a snapshot on audit day
- Tie every metric to the date of your next surveillance audit
Common mistakes Kubernetes teams make
- Scanning at build time only. Images drift once pods run for weeks against newly disclosed CVEs.
- Chasing every CVSS 9-plus finding. Engineering time burns on unreachable internal services while exposed ones wait.
- Treating the SBOM as a one-off audit deliverable. It goes stale the moment a base image updates.
- Letting patch backlogs queue until a CVE trends. Then teams scramble instead of running a fixed cadence.
- Keeping scan results in a dashboard nobody maps to a control. Auditors want evidence, not a severity chart screenshot.
Frequently asked questions
One last thing
Most container CVEs sitting in a scan report never touch a running pod. They live in unused base image layers nobody executes. Run an SBOM diff against runtime process data before you spend a sprint patching the full image manifest — the real remediation list is usually a fraction of what the scanner flagged.
Get the scanning cadence right, automate the evidence, and Kubernetes compliance becomes seriously simple cyber compliance instead of an audit-week fire drill.