Docker and Kubernetes Security: The 10 Risks

In 2026, 92% of companies run containers in production (Datadog 2025). Docker and Kubernetes aren't emerging technologies anymore, they're critical infrastructure components. Yet containerized environment security remains a blind spot for many CISOs. The Sysdig 2025 report shows that 87% of Docker images in production contain at least one high or critical vulnerability.

Risk 1: Vulnerable images

This is the most common risk. A Docker image built from an unupdated ubuntu:22.04 carries dozens of known CVEs. The official node:18 image contains an average of 40+ vulnerabilities at any given time.

• Remediation: scan every image with Trivy or Grype before deployment AND at runtime. Use minimal images (Alpine, Distroless). Rebuild images at least monthly.
• ThreatClaw: the Trivy skill automatically scans images in your registry and at runtime, with EPSS prioritization.

Risk 2: Secrets in images or environment

API keys, passwords, and tokens hardcoded in Dockerfiles, environment variables, or image layers. Trufflehog and Gitleaks still find credentials in 15-20% of analyzed repositories.

• Remediation: Kubernetes Secrets (encrypted with KMS), HashiCorp Vault, or AWS Secrets Manager. Never put secrets in the image. Use multi-stage builds to prevent build-time secrets from ending up in the final image.

Risk 3: Container escape

A misconfigured container can allow an attacker to escape to the host node. Classic vectors: mounting the Docker socket (/var/run/docker.sock), --privileged mode, excessive Linux capabilities (CAP_SYS_ADMIN).

• Remediation: never use --privileged in production. Don't mount the Docker socket. Kubernetes SecurityContext with runAsNonRoot: true, readOnlyRootFilesystem: true, drop all capabilities.
• ThreatClaw: the Docker Bench for Security skill automatically checks these configurations against CIS recommendations.

Risk 4: Image supply chain

Your image depends on 10 parent images, 50 system packages, and 200 application dependencies. A single backdoor in the chain and your container is compromised. The XZ Utils attack (CVE-2024-3094) demonstrated the reality of this risk.

• Remediation: generate an SBOM (Software Bill of Materials) with Syft. Verify provenance with Sigstore/Cosign. Use a private registry with admission scanning.
• ThreatClaw: the Syft skill generates the SBOM for each image and the Grype skill continuously scans it against new CVEs.

Risk 5: Runtime security

A production container can be compromised via an application vulnerability (SQL injection, SSRF, RCE). Image scanning detects known vulnerabilities, but not ongoing exploitation.

• Remediation: syscall monitoring with Falco, abnormal process detection, alerting on unusual container behavior (reverse shell, crypto mining).
• ThreatClaw: ML behavioral detection also applies to containers, process, network, and filesystem baseline per container.

Risk 6: Missing network policies

By default, all Kubernetes pods can communicate with each other. No segmentation, no micro-segmentation. An attacker who compromises a frontend pod can reach the database pod directly.

• Remediation: implement Kubernetes NetworkPolicies. Default deny-all, then explicitly allow necessary flows. Compatible CNI required (Calico, Cilium).

Risk 7: Misconfigured RBAC

Kubernetes RBAC is powerful but complex. Classic mistakes: ClusterRoleBinding with cluster-admin on service accounts, wildcards (*) in permissions, default ServiceAccounts with excessive rights.

• Remediation: least privilege principle. Regularly audit RBAC bindings. Use tools like kubiscan or rakkess to visualize effective permissions.

Risk 8: Insufficient logging and monitoring

Without centralized logs, investigating an incident in a Kubernetes cluster is nearly impossible. Pods are ephemeral, when they crash, logs vanish.

• Remediation: centralized logging stack (EFK/ELK, Loki). Kubernetes audit logs enabled. Sufficient retention for forensics (90 days minimum). Integration with your SIEM.

Risk 9: Regulatory non-compliance

Containerized environments must meet the same requirements as the rest of your infrastructure: NIS2, GDPR, PCI DSS, ISO 27001. But traditional controls (server agents, port scanning) don't work the same way in a Kubernetes cluster.

• Remediation: adapt compliance controls to the container paradigm. CIS Kubernetes Benchmark. Admission controllers (OPA Gatekeeper, Kyverno) to enforce policies at admission time.

Risk 10: Backup and disaster recovery

Stateless workloads are easy to recreate. Persistent data (PersistentVolumes, stateful databases) less so. Ransomware encrypting a cluster's PVs can be as devastating as ransomware on a traditional server.

• Remediation: Velero for Kubernetes resource backup + PV snapshots. Regular restoration tests. Off-cluster backup (3-2-1 rule). Ransomware detection on PVs.

ThreatClaw skills for container security

ThreatClaw includes specialized skills for Docker and Kubernetes environments:

• Trivy: image scanning (CVEs, secrets, misconfigs), filesystem scanning, Kubernetes config scanning
• Grype: SCA (Software Composition Analysis) of dependencies in images
• Docker Bench for Security: automated CIS Docker Benchmark audit
• Syft: SBOM generation for supply chain traceability

These skills run continuously. Every new image pushed to the registry is scanned. Every configuration drift is alerted. The CISO has real-time visibility into container security posture, not a monthly snapshot.

FAQ

Is Docker inherently less secure than a VM?

No, but the security model is different. Containers share the host kernel, which reduces isolation compared to a VM. However, with proper practices (seccomp, AppArmor/SELinux, namespaces, reduced capabilities), a properly configured container offers a reduced attack surface. The risk is mostly in misconfiguration, not the technology itself.

Should I scan images at every build or only in production?

Both. Scanning at build time (CI/CD pipeline) prevents vulnerable images from reaching production. Runtime scanning catches new CVEs published after deployment. An image that's clean on day one can become vulnerable the next day if a new CVE is discovered in one of its dependencies.

Is Kubernetes necessary for small infrastructures?

No. For fewer than 20 containers, Docker Compose or Docker Swarm often suffice. Kubernetes adds value starting at 50+ containers, especially if you need auto-scaling, rolling updates, and multi-node orchestration. Kubernetes complexity is a cost: more attack surface, more possible misconfiguration. Choose the complexity you need, not more.

How should I prioritize securing an existing Kubernetes cluster?

In priority order: (1) Scan all production images with Trivy, fix critical CVEs. (2) Enable deny-all NetworkPolicies and open necessary flows. (3) Audit RBAC and remove excessive permissions. (4) Enable audit logs and centralize them. (5) Implement an admission controller (Kyverno or OPA Gatekeeper). ThreatClaw covers steps 1-4 automatically.