KRIs for container and Kubernetes security

The KRIs in this domain measure whether your container security controls are operating at the speed and coverage that container-native infrastructure demands, not batch scanning but continuous assurance, not perimeter monitoring but runtime protection, and not manual policy enforcement but admission controls that prevent non-compliant workloads from running at all.

If you are standing this up from scratch, start with how to build a KRI program and the consolidated KRI reference library, which maps every domain to one CIS-aligned catalog.

KRI inventory

1. Container image vulnerability scan coverage rate

What to measure. Percentage of container images deployed to production that have been scanned for known vulnerabilities (CVEs in base image and application layers) within the defined scan frequency, covering images in registries and images actively running in production.

Why it matters. Unscanned container images are unknown risk. Images built months ago may carry base image vulnerabilities discovered since the last scan. A container image pipeline that scans at build time but never rescans running images accumulates vulnerability risk silently as new CVEs are published against the base image layers already deployed.

• Container registry (ECR, GCR, Docker Hub, Harbor, JFrog Artifactory): image scan results and scan date per image tag
• Container security platform (Wiz, Prisma Cloud, Sysdig, Aqua Security, Snyk Container): image scan coverage report
• Kubernetes: running pods with image SHAs cross-referenced against scanned image inventory
• CI/CD pipeline: image scanning step completion rate per build

How to calculate.

• Registry scan coverage: (Images in registry scanned within defined frequency) ÷ (total images in registry) × 100
• Runtime scan coverage: (Pod/container SHAs actively running with scan record <7 days old) ÷ (total running pods) × 100

Status	Criteria
Green	>99% of registry images scanned; running images rescanned on vulnerability publication trigger; no production images with critical CVEs unresolved >7 days
Amber	90–98% registry coverage; or scanning at build-time only (no rescan of running images); or critical CVE SLA 7–30 days
Red	<90% registry coverage; or images deployed without scanning; or no rescan capability

2. Base image hygiene rate

What to measure. Percentage of production container images built on approved, minimal, and current base images, free of unnecessary packages and using current OS layer versions, versus images using outdated, fat, or unapproved base images.

Why it matters. Base image selection is the single most impactful vulnerability management decision in container security. A container built on ubuntu:18.04 carries hundreds more CVEs than one built on distroless or alpine. Base image hygiene enforced at build time prevents entire categories of vulnerabilities from entering the image supply chain.

• Container security platform: base image layer analysis per image, identify base image, OS version, package count
• Image scanning results: CVE counts by layer, base layer vs. application layer vulnerability split
• Approved base image registry: list of organization-approved base images; compare against images in production
• CI/CD policy: admission control or pipeline gate enforcing approved base images

How to calculate. (Production images built on approved base image list) ÷ (total production images) × 100 Also: (Production images with critical CVEs exclusively in base layer, could be fixed by base image update), actionable remediation signal

Status	Criteria
Green	>95% of production images on approved base image list; automated base image update pipeline; distroless or minimal base images preferred for new builds
Amber	80–94%; or approved base image list defined but not enforced in pipeline; or legacy fat base images in production with no migration plan
Red	<80%; or no approved base image policy; or outdated OS base images (Ubuntu 18.04, CentOS 7) in production with no migration path

3. Kubernetes cluster security benchmark compliance

What to measure. Percentage of Kubernetes cluster components, API server, kubelet, etcd, control plane, compliant with CIS Kubernetes Benchmark security recommendations, measured through automated benchmark assessment.

Why it matters. Default Kubernetes cluster configurations are not hardened. Anonymous authentication, insecure API server flags, and kubelet configurations allowing privilege escalation are common in clusters deployed without security hardening. CIS Benchmark compliance measures whether the cluster configuration itself is secure, independent of the workloads running on it.

• kube-bench: open-source CIS Kubernetes Benchmark scanner, runs against node and master configurations
• Cloud-managed Kubernetes assessment (EKS, GKE, AKS): each provider has built-in security posture assessment (AWS EKS Best Practices, GKE Security Posture, Azure Defender for Containers)
• Polaris: workload and cluster configuration validation against best practices
• Falco: runtime security rules for Kubernetes, detected policy violations signal cluster security health

How to calculate. (CIS Benchmark checks passing) ÷ (total CIS Benchmark checks applicable) × 100 Run kube-bench: kubectl run kube-bench --image=aquasec/kube-bench:latest --restart=Never -- master; parse output for PASS/FAIL/WARN

Status	Criteria
Green	>90% CIS Benchmark compliance; all FAIL checks remediated or documented with compensating controls; benchmark run automatically on cluster changes
Amber	75–89%; or known FAIL items with no remediation plan; or benchmark run periodically rather than on-change
Red	<75%; or critical benchmark failures (anonymous auth, insecure API server) unaddressed; or no benchmark assessment

4. Admission control policy coverage

What to measure. Percentage of Kubernetes workload deployments validated by admission controllers enforcing security policies, specifically: no privileged containers, no host network access, required security contexts, approved registries only, and required labels.

Why it matters. Admission controllers are the enforcement mechanism that prevents non-compliant workloads from being scheduled at all. Without them, developers can deploy privileged containers, containers running as root, and images from unapproved registries, and nothing stops them. Admission control is the preventive control; everything else in Kubernetes security is detective.

• OPA/Gatekeeper policies: constraint templates and constraints deployed; admission webhook status
• Kyverno policies: policy rules deployed; enforcement mode (audit vs. enforce) per policy
• Pod Security Admission (Kubernetes 1.23+): namespace-level security standards (privileged/baseline/restricted); enforcement mode per namespace
• Admission webhook logs: admission denials per policy, signals active policy enforcement

How to calculate.

• Policy coverage: (Production namespaces with admission control policies in enforce mode) ÷ (total production namespaces) × 100
• Policy breadth: (Admission policies covering: no privileged, approved registry, security context, resource limits) ÷ (4 defined policy categories) × 100

Status	Criteria
Green	All production namespaces in enforce mode; all four policy categories covered; admission denial alerts reviewed
Amber	Enforce mode in most namespaces but gaps; or audit mode only (not blocking); or policy coverage missing registry or privilege controls
Red	No admission control; or all policies in audit mode; or privileged containers running in production without controls

5. Container runtime threat detection coverage

What to measure. Percentage of production Kubernetes nodes and container runtimes with active runtime security monitoring, detecting anomalous system calls, unexpected network connections, privilege escalation attempts, and container breakout behaviors.

Why it matters. Image scanning and admission control prevent known-bad workloads from running. Runtime detection catches compromise of known-good workloads, the container that was clean at deploy time but has been exploited through a vulnerability in the running application. Container runtime security is the equivalent of EDR for the container layer.

• Runtime security platforms (Falco, Sysdig Secure, Aqua Runtime, Prisma Cloud Defender): agent deployment coverage across nodes
• Cloud-native runtime detection (AWS GuardDuty ECS/EKS Runtime Monitoring, Microsoft Defender for Containers, GCP Security Command Center container threats): coverage configuration
• Alert volume and type: runtime security alerts by category (privilege escalation, shell spawned in container, network anomaly, filesystem write to protected path)

How to calculate. (Kubernetes nodes with runtime security agent active and reporting) ÷ (total production Kubernetes nodes) × 100

Status	Criteria
Green	>98% node coverage; alert triage SLA defined; critical runtime alerts (container escape, privilege escalation) routed to SOC with <15 minute SLA
Amber	85–97% coverage; or alerts generated but not integrated into SOC workflow
Red	<85%; or no runtime security monitoring; or container threats detected only via host-level EDR without container context

6. Secrets management in container workloads

What to measure. Percentage of containerized applications that retrieve secrets (API keys, database credentials, certificates) from a secrets management system at runtime, versus secrets hardcoded in container images, environment variables, or Kubernetes ConfigMaps.

Why it matters. Secrets in container images, environment variables, or ConfigMaps are visible to anyone with access to the Kubernetes cluster, the container registry, or the CI/CD pipeline. A single kubectl describe pod on a misconfigured deployment can expose production database credentials. Secrets management systems (Vault, AWS Secrets Manager, Kubernetes Secrets with encryption) enforce access control and auditability that inline secrets cannot.

• Secrets scanning (Gitleaks, Truffleog, Semgrep): container image layers scanned for hardcoded secrets
• Kubernetes resource audit: kubectl get secrets -A count vs. workloads using external secrets operator or vault agent
• External Secrets Operator: deployments using ESO to pull secrets from external vaults vs. native Kubernetes Secrets
• Vault agent injector: pods with vault-agent-injector annotations confirmed in production namespaces

How to calculate. (Production pods/deployments using approved secrets management solution) ÷ (total production pods/deployments) × 100 Critical gap: secrets found in container image layers (scan result), absolute count; should be zero

Status	Criteria
Green	>90% of workloads using secrets management; zero secrets in image layers; Kubernetes Secrets encrypted at rest with KMS
Amber	70–89% using secrets management; or Kubernetes Secrets used without KMS encryption; or known secrets in environment variables being migrated
Red	<70%; or secrets in container image layers; or no secrets management in production; or Kubernetes Secrets without encryption at rest

7. Network policy coverage rate

What to measure. Percentage of Kubernetes namespaces with network policies enforcing microsegmentation, restricting pod-to-pod communication to only the traffic required for the application to function, with a default-deny baseline.

Why it matters. Without network policies, all pods in a Kubernetes cluster can communicate with all other pods by default. An attacker who compromises one pod can reach every other pod in the cluster, across namespaces, across applications. Kubernetes network policies are the microsegmentation control for east-west traffic within the cluster.

• Kubernetes API: kubectl get networkpolicies -A, namespaces with network policies; compare against total namespaces
• Network policy analysis tools (Calico, Cilium, Trireme): visual policy mapping and gap analysis
• Namespace inventory: production namespaces with default-deny ingress and egress policies as baseline
• Runtime network monitoring: actual pod-to-pod traffic flows vs. network policy allowed flows, unexpected flows signal policy gaps

How to calculate. (Production namespaces with at least one network policy including default-deny baseline) ÷ (total production namespaces) × 100

Status	Criteria
Green	>95% of production namespaces with network policies including default-deny; network policy testing validates no unauthorized lateral movement paths
Amber	75–94%; or network policies present without default-deny baseline (allow-list without initial deny)
Red	<75%; or no network policies (flat cluster network); or default-allow networking in production namespaces

Deriving these KRIs by source type

From Container Registries (ECR, GCR, Docker Hub, JFrog)

• ECR scan results: aws ecr describe-image-scan-findings --repository-name <repo> --image-id imageTag=<tag>, findings by severity; aws ecr describe-images --repository-name <repo> for scan status and imageScanStatus.status
• GCR/Artifact Registry: gcloud artifacts docker images list --format=json | jq '.[].package' + vulnerability scanning via Container Analysis API
• JFrog Xray: REST API GET /api/v1/artifact/summary with artifact coordinates, vulnerability and license findings

From Kubernetes API

• Cluster security assessment: kubectl run kube-bench --image=aquasec/kube-bench:latest --restart=Never -- master, CIS Benchmark results
• Admission controller status: kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations, confirm admission webhooks are registered
• Network policy coverage: kubectl get networkpolicies -A -o json | jq '.items | group_by(.metadata.namespace) | map({namespace: .[0].metadata.namespace, policy_count: length})'
• Privileged pods: kubectl get pods -A -o json | jq '.items[] | select(.spec.containers[].securityContext.privileged == true) | {namespace: .metadata.namespace, name: .metadata.name}'
• Secrets in env vars: kubectl get pods -A -o json | jq '.items[] | select(.spec.containers[].env[]?.valueFrom.secretKeyRef != null) | .metadata.name'

From Runtime Security Platforms (Falco, Sysdig)

• Falco alert stream: Falco outputs JSON events to stdout/syslog/webhook; route to SIEM with rule, priority, container.name, namespace fields
• Sysdig Secure API: GET /api/alerts for policy violation events; GET /api/benchmarks/tasks for benchmark run results and coverage
• Coverage validation: Sysdig agent connectivity report, nodes with agent running and reporting vs. total cluster nodes

From Cloud Container Security (Defender for Containers, GuardDuty, GCP SCC)

• AWS GuardDuty EKS: aws guardduty list-findings --detector-id <id> --finding-criteria '{"Criterion":{"service.resourceRole":{"Eq":["TARGET"]},"type":{"Prefix":["Kubernetes/"]}}}'
• Microsoft Defender for Containers: Security Center → Containers workload protections → Coverage; recommendations filtered to container resource type
• GCP SCC Container Threat Detection: gcloud scc findings list projects/PROJECT_ID --filter="category:CONTAINER_THREAT_DETECTION"