Container security platforms promise to cover the whole lifecycle from image build to running pod, but many teams buy one and end up with thousands of image findings, an unused runtime sensor and Kubernetes clusters that still admit privileged pods. The market spans image scanning, Kubernetes posture, admission control, runtime detection and response, and broad cloud suites that include all of these at varying depth. This vendor-neutral guide helps platform engineering, cloud security and procurement teams define requirements, compare container security solutions on evidence, ask the right RFP questions, understand pricing models and run a proof of concept on their own clusters. For how to secure containers and clusters, see the Container Security Guide and the Kubernetes Security Guide.
Key takeaways
- Buy for the gaps your platform leaves. Kubernetes Pod Security Admission, managed cluster defaults and cloud-native scanners already cover a lot; a container security platform should add what they cannot, not repeat it.
- Prioritisation beats detection volume. The test of image scanning is whether it tells you which vulnerable packages are in running, exposed workloads with a fix available, not how many CVEs it lists.
- Prevention happens at admission. Blocking unscanned, unsigned or privileged workloads before they run is cheaper than detecting them afterwards; check that enforcement can start in audit mode and fail safely.
- Runtime detection must be container aware. NIST SP 800-190 recommends "container-aware runtime defense tools"; test detections for container escape, unexpected processes and API abuse on your own nodes.
- Identity is part of container security. Service account tokens, cloud workload identities and secrets in images are routes from one pod to the cloud account; the platform should see them.
Define requirements
Choosing a container security platform starts with these decisions, written down before vendor demos. They decide whether you need a dedicated Kubernetes security platform, a module of a broader cloud suite, or better use of what you already run.
- Estate: count clusters by type (managed Kubernetes on each cloud, self-managed, edge), node operating systems and kernel versions, serverless container services, registries and CI systems. Note where you cannot install a privileged agent, because that limits runtime options.
- Risk model: NIST SP 800-190 groups container risks into image risks (vulnerabilities, configuration defects, embedded malware, embedded clear text secrets, untrusted images), registry risks, orchestrator risks (including unbounded administrative access and mixing of workload sensitivity levels), container risks (including rogue containers) and host OS risks (including the shared kernel). Mark which of these you already control and which you need a product for.
- Existing controls: record what is enforced today: Pod Security Standards levels per namespace, network policies, image registry restrictions, cloud-native scanning and threat detection (for example Microsoft Defender for Containers, or Amazon Inspector scanning images in Amazon ECR), and audit log collection.
- Baseline to measure against: the NSA and CISA Kubernetes Hardening Guide (v1.2, August 2022) lists the core mitigations: "Scan containers and Pods for vulnerabilities or misconfigurations", "Run containers and Pods with the least privileges possible", network separation, strong authentication and authorisation, and "Capture and monitor audit logs". The CIS Kubernetes Benchmark (currently 2.1.0, with separate benchmarks for EKS, AKS and GKE) gives checkable settings.
- Operating model: who triages image findings (application teams or a central team), who owns admission policy, who responds to runtime alerts, and how findings reach ticketing. A platform without an owner for each output becomes a dashboard nobody reads.
- Constraints: sensor overhead budget per node, whether a hosted service may receive workload metadata and process data, air-gapped or regulated clusters, and change windows for installing kernel-level sensors.
Size changes the answer. A small team on one managed Kubernetes service usually gets most value from enforcing Pod Security Standards, scanning in CI and the registry with the cloud provider's or an open-source scanner, default-deny network policies and cloud-native threat detection. A large organisation with many clusters across clouds, multi-tenant platforms and regulated workloads needs consistent policy, posture and runtime detection across them, and is the usual buyer of a dedicated platform. If you are also buying cloud posture and cloud identity tooling, compare against suites in the CNAPP Buyer's Guide.
Capability areas and evaluation criteria
Container security vendors lead with different capabilities. A fair container security comparison scores each capability area separately rather than giving a single verdict.
| Capability area | What it does | Lifecycle stage | Native or open alternatives |
|---|---|---|---|
| Image and registry scanning | Finds vulnerable OS and language packages, misconfigurations, secrets and malware in images; produces or ingests SBOMs | Build, registry | Cloud registry scanning; open-source scanners in CI |
| Kubernetes security posture (KSPM) | Checks cluster and workload configuration, RBAC and benchmarks; tracks drift | Deploy, operate | CIS Benchmark assessment tools; managed cluster recommendations |
| Admission control and policy | Blocks or warns on workloads that break policy: privilege, image source, signature, digest pinning, labels | Deploy | Pod Security Admission; open-source policy engines |
| Runtime detection and response | Watches process, file, network and Kubernetes API activity in containers; detects escape, drift and abuse; can kill or isolate pods | Run | Cloud-native threat detection; open-source runtime sensors |
| Network visibility and segmentation | Maps pod-to-pod and egress traffic; suggests and validates network policies | Run | Network policy support in the CNI; service mesh |
| Identity and secrets exposure | Finds service account privilege, mounted tokens, cloud role bindings and secrets in images or environment variables | Build, run | Cloud IAM analysis; secret scanning |
Weight criteria to your requirements. An illustrative split for a multi-cluster estate: 20% image risk prioritisation, 20% runtime detection and response, 20% admission and posture, 15% identity and secrets, 10% operational footprint, 15% integration and commercial terms. These container security evaluation criteria assume you score on your own clusters, not a vendor lab.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Image findings quality | Accurate package detection for OS and language ecosystems, base image identification, fix availability, KEV and exploitability context, and whether the package is loaded in a running workload | Raw CVE counts; no distinction between build-only and running images |
| Image content risks | Detects embedded secrets, malware and risky configuration (running as root, no USER, exposed ports), matching SP 800-190 sections 3.1.3 and 3.1.4 | Vulnerabilities only |
| SBOM and provenance | Generates and ingests SPDX or CycloneDX SBOMs; verifies image signatures and provenance at admission | SBOM export only; no verification |
| Admission control | Enforces image source, digest references, signatures and Pod Security Standards; audit and warn modes; documented failure behaviour | Enforcement only after deployment; webhooks that block the cluster when the vendor is unreachable |
| Posture and benchmarks | CIS Kubernetes Benchmark and managed-service benchmarks, RBAC analysis for wildcard and escalation verbs, checks from the Kubernetes security checklist | Generic cloud checks relabelled as Kubernetes |
| Runtime detection | Container and Kubernetes context on every alert (cluster, namespace, pod, image, service account); detections for escape, drift, shells, crypto mining and API abuse; low false positives after tuning | Host-only alerts without pod context; rules you cannot read or tune |
| Response | Kill, pause or isolate a pod, apply a network policy, capture forensic data, all logged and reversible | Alert only, or automatic actions that cannot be scoped |
| Coverage and footprint | Supports your kernels, node images, managed and serverless container services; published CPU and memory overhead; no kernel module where you cannot allow one | Coverage gaps on managed nodes; unmeasured overhead |
| Integration | CI plugins, registry hooks, SIEM and ticketing export, API access, owner mapping from labels | Findings trapped in the console |
Runtime detections to test
Ask vendors to map their runtime and audit-log detections to MITRE ATT&CK techniques in the Containers matrix, then prove them in the proof of concept: T1609 Container Administration Command (exec into pods), T1610 Deploy Container, T1611 Escape to Host, T1613 Container and Resource Discovery, T1525 Implant Internal Image, T1612 Build Image on Host, T1552.007 Unsecured Credentials: Container API, T1528 Steal Application Access Token and T1496 Resource Hijacking. Detection should combine runtime signals with Kubernetes audit logs, which the Kubernetes security checklist says must be "protected from general access".
Pricing models
Container security pricing is rarely published and the counting unit matters more with autoscaling than with any other category. Ask for a three-year cost at average and peak node counts.
| Model | What is counted | Watch for |
|---|---|---|
| Per node or host | Worker nodes running a sensor | Peak versus average counting during autoscaling; charges for system node pools |
| Per vCPU or core | Compute capacity protected | Cost rising with larger nodes even when workload count is flat |
| Per workload or pod | Running containers or pods | Short-lived jobs and replicas each counted |
| Per image or scan | Images scanned or stored in registries | Every tag and build counted; rescans charged |
| Suite or credit bundles | Container modules within a broader cloud platform, often consumption credits | Modules you need sold separately; credits consumed by serverless containers |
Where identity fits
Many container incidents become cloud incidents through identity. In the Tesla Kubernetes cryptojacking an open console exposed AWS credentials, and in the Kubeflow cryptomining attacks a mounted service account helped hijack clusters. The Kubernetes security checklist says "Service account tokens are not mounted in pods that don't require them" and asks for bound service account token volumes instead of non-expiring tokens; it also asks that workload access to the cloud metadata API is filtered. Require the platform to show which pods carry which service account and cloud role, flag cluster-admin and wildcard bindings, and detect secrets in images and environment variables. See the Kubernetes NHI Security Guide.
Framework mapping
| Capability | NIST SP 800-190 | CIS Controls v8.1 | NIST SP 800-53 and ISO/IEC 27001:2022 |
|---|---|---|---|
| Image scanning and registry control | 3.1 Image risks; 3.2 Registry risks | Control 7 Continuous Vulnerability Management; Control 16 Application Software Security | RA-5; Annex A 8.8 Management of technical vulnerabilities |
| Posture and admission control | 3.3 Orchestrator risks; 3.4.3 Insecure container runtime configurations | Control 4 Secure Configuration of Enterprise Assets and Software | CM-6, CM-7; Annex A 8.9 Configuration management |
| Runtime detection | 3.4.5 Rogue containers; 3.5 Host OS risks | Control 8 Audit Log Management; Control 13 Network Monitoring and Defense | SI-4, AU-6; Annex A 8.16 Monitoring activities |
| Identity and secrets | 3.1.4 Embedded clear text secrets; 3.3.1 Unbounded administrative access | Control 5 Account Management; Control 6 Access Control Management | AC-6, IA-5; Annex A 8.2 Privileged access rights |
Questions to ask vendors
Use these as the core of a container security RFP. Ask every shortlisted vendor the same set in writing and confirm the answers on your clusters in the proof of concept.
- Which of our cluster types, node operating systems, kernels and serverless container services do you support for each capability, and where is a privileged agent or kernel module required?
- How do you decide which image findings matter: fix availability, KEV status, exploitability, internet exposure, and whether the package is loaded in a running workload? Show the inputs for one finding.
- Do you detect secrets, malware and insecure configuration in images, and can you trace a running pod back to its image digest, registry, build and owner?
- How does admission control work: webhook or native policy, audit and warn modes, signature and digest verification, and what happens to deployments if your service is unreachable?
- Which benchmarks and checklists do you assess (CIS Kubernetes Benchmark, managed-service benchmarks, NSA and CISA guidance), and how do you analyse RBAC escalation paths?
- Which ATT&CK Containers techniques do your runtime detections cover, which data sources do they use, and can we read and tune the rules?
- What response actions are available, how are they scoped and approved, and how are they reversed?
- What CPU and memory overhead should we expect per node, and how do you update sensors without node restarts?
- What workload, process and network data leaves our clusters, where is it stored, and for how long?
- What permissions do your cluster and cloud integrations need, and can they be read-only and federated rather than static keys?
- What exactly counts toward the licence during autoscaling, and what does doubling our node count cost?
Red flags
- Image scanning that reports every CVE in every tag with no runtime or fix context, so teams stop reading the findings.
- Admission webhooks that fail closed with no tested bypass, letting a vendor outage block deployments and even cluster recovery, or that fail open silently with no alert.
- Runtime alerts with host context only, no pod, namespace, image or service account.
- Sensors that need privileges or kernel modules your managed nodes do not allow, discovered after purchase.
- Secrets in images treated as out of scope; public images regularly leak cloud, CI and AI keys, as the Docker Hub secrets leak showed.
- Integrations that require cluster-admin and long-lived cloud keys. A security tool is a privileged non-human identity and a supply chain target in its own right: credentials stolen from one scanner were used to poison another scanner's Docker images in the Checkmarx KICS supply chain attack.
- Per-node pricing counted at peak, which penalises autoscaling.
Proof of concept
- Scope and success criteria: use one production-like cluster on each Kubernetes flavour you run, plus one CI pipeline and registry. Agree measurable outcomes, such as the top 20 image risks in running workloads identified with owners, privileged pods blocked in audit mode, and every seeded runtime test detected with pod context.
- Baseline: record current image findings, Pod Security Standards levels per namespace, service accounts with cluster-admin, and existing alerts.
- Seed ground truth: deploy an image with a known KEV-listed vulnerable package, an image containing a disabled test credential, a pod requesting privileged mode and host path mounts, and a workload with an over-privileged service account. Note whether each is found and how it ranks.
- Admission in audit, then warn, then enforce: start policies in audit mode, review what would have been blocked across a week of normal deployments, then enforce in one namespace. Confirm the failure behaviour by making the vendor service unreachable.
- Exercise runtime detection safely: in a test namespace, run benign simulations of an interactive shell in a container, reading the mounted service account token, querying the Kubernetes API for secrets, and writing to a host path. Record detection time, context and false positives over a week of normal traffic.
- Measure footprint: compare node CPU, memory and pod start time with and without the sensor under realistic load.
- Roll back cleanly: remove admission webhooks first, then sensors and DaemonSets, revoke cluster roles and cloud permissions, confirm in Kubernetes and cloud audit logs that access has stopped, and get written confirmation that trial data is deleted.
After purchase, roll out in rings: visibility and image scanning across all clusters first, then admission policies in audit mode, then enforcement namespace by namespace starting with new workloads, then runtime response actions. Keep a documented break-glass process to disable admission webhooks. Track: share of running images scanned and from approved registries, age of exploitable vulnerabilities in running workloads, share of namespaces enforcing Baseline or Restricted Pod Security Standards (Restricted is aimed at "enforcing current Pod hardening best practices"), service accounts with cluster-admin or wildcard rights, runtime alerts triaged within target time, and benchmark pass rate per cluster. Image-specific practice is covered in the Container Image Security Guide.
Standards and references
- NIST: SP 800-190, Application Container Security Guide
- NSA and CISA: Kubernetes Hardening Guide
- Kubernetes: Security Checklist
- Kubernetes: Pod Security Standards
- CIS: Kubernetes Benchmarks
- CIS: Critical Security Controls v8.1
- MITRE ATT&CK: Containers Matrix
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Container Security Guide · Container Image Security Guide · Kubernetes Security Guide · CNAPP Buyer's Guide · Kubernetes NHI Security Guide · Top 10 Kubernetes Security Risks