Container Security Beyond Scanning: Runtime Protection and Supply Chain Integrity
Container security programs that start and end with image vulnerability scanning are protecting against the easiest-to-fix category of risk while leaving the most dangerous categories unaddressed. Image scanning finds known CVEs in image layers. It does not find: malicious packages that have no CVE, supply chain compromises that injected malicious code into a legitimate-looking dependency, runtime exploitation of application vulnerabilities, container escape techniques, or lateral movement between pods. This guide covers the full container security stack — from build-time supply chain integrity through runtime behavioral detection.
The Container Security Stack: Four Layers
Container security has four distinct layers, each requiring different controls:
Layer 1: Supply chain and build-time integrity What goes into the image? Is the base image from a trusted source? Are dependencies from a verified registry? Has the build pipeline been tampered with?
Layer 2: Image configuration and posture Is the image hardened? Does it run as root? Does it include unnecessary tools (curl, wget, bash) that aid attackers? Are secrets baked into the image?
Layer 3: Runtime behavior Is the running container doing what it is supposed to do? Has it spawned unexpected processes, made unexpected network connections, or accessed unexpected files?
Layer 4: Orchestration-level controls (Kubernetes) Are Pods configured securely? Are NetworkPolicies applied? Are RBAC permissions scoped correctly? Is the API server accessible only to authorized clients?
Most organizations have partial coverage of Layer 2 (image scanning) and no coverage of Layers 1, 3, or 4. The risk is concentrated in what they are not monitoring.
Supply Chain Integrity: SBOMs, Sigstore, and SLSA
Software supply chain attacks against container environments target the build pipeline and dependency resolution — not the application code itself.
Software Bill of Materials (SBOM): An SBOM is a machine-readable inventory of every component in a container image — OS packages, language libraries, binaries. Generate SBOMs at build time using Syft or Grype. Store them alongside the image in the registry. When a new CVE drops (e.g., Log4Shell), query your SBOM inventory to identify which images are affected within minutes — not days.
Image signing with Sigstore/Cosign: Signing container images creates a cryptographic attestation that the image was built by your pipeline and has not been tampered with since. Sigstore's Cosign tool integrates with GitHub Actions, GitLab CI, and Tekton. Signed images are stored alongside the image in the registry (OCI 1.1 format). Admission controllers can require valid signatures before allowing image execution in the cluster.
SLSA (Supply Levels for Software Artifacts): SLSA is a framework for build provenance — a cryptographically signed record of how an artifact was built, from which source commit, by which system. SLSA Level 2 requires a hosted build service generating signed provenance. Level 3 adds requirements for tamper-resistant build infrastructure. SLSA provenance is queryable: you can verify that a production image was built from a specific git commit by an authorized pipeline.
Dependency verification: Lock dependency files (go.sum, package-lock.json, Pipfile.lock) and verify hashes at build time. Do not pull 'latest' from upstream registries — pin to specific digest hashes. Use a private registry mirror (Harbor, AWS ECR, Artifactory) that can enforce allowlists on base images.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Image Hardening Beyond Vulnerability Scanning
Image configuration choices create attack surface independent of CVE count.
Run as non-root: Images that run as root within the container can escalate to host root if a container escape vulnerability exists. Use USER directive in Dockerfile to specify a non-root UID. Kubernetes PodSecurity admission can enforce this cluster-wide.
Minimize image contents: Attack tools (curl, wget, nc, bash, python) present in production images increase the capability of an attacker who achieves code execution. Use distroless base images (Google's distroless series) or multi-stage builds that copy only the compiled binary into a minimal base. No shell means significantly reduced attacker capability.
Read-only root filesystem: Setting readOnlyRootFilesystem: true in the Pod spec prevents attackers from writing malicious files to the container filesystem. Applications that need writable directories can mount tmpfs volumes for specific paths.
Dropped capabilities: Linux capabilities allow fine-grained privilege grants. Most containers need zero Linux capabilities. Drop all capabilities by default (drop: [ALL]) and add back only those the application explicitly requires (e.g., NET_BIND_SERVICE if binding to a port below 1024).
No secrets in images: Scan images for embedded credentials using Trufflehog or Detect-Secrets in the build pipeline. Use Kubernetes Secrets (or external secret managers — HashiCorp Vault, AWS Secrets Manager) mounted at runtime rather than baked into image layers.
Runtime Security: Behavioral Detection in Containers
Runtime security tools monitor container behavior against a behavioral baseline and alert when containers deviate — spawning unexpected processes, making unexpected network connections, or accessing unexpected files.
How runtime detection works: Falco (CNCF project), Sysdig Secure, Aqua, and StackRox use eBPF or kernel module interception to observe system calls from every container. They evaluate each system call against policy rules. Example Falco rule: 'Alert when a container spawns a shell process.' This catches post-exploitation regardless of whether the attacker used a known exploit.
High-value runtime detection rules:
- Shell spawned in a container (bash, sh, zsh, dash) — catches interactive attacker access
- Unexpected outbound network connection to an external IP — catches C2 callback
- Write to /etc, /bin, /usr/bin — catches persistence mechanisms
- Process execution of known attack tools (curl, wget, nc, nmap, python) — catches post-exploitation activity
- Container escape indicators (host mount access, /proc/sysrq-trigger access, ptrace on host processes)
- Sensitive file access (/etc/shadow, /etc/kubernetes/pki, service account token files)
Runtime policy enforcement: Beyond alerting, runtime tools can kill containers or block syscalls that violate policy (using seccomp profiles). Seccomp profiles define which system calls a container is permitted to make — a tight seccomp profile reduces the syscall surface available for container escape exploitation.
Kubernetes Admission Control: Enforcing Policy at Deploy Time
Admission controllers intercept API server requests and enforce policy before resources are created. They are the enforcement layer for image signing requirements, Pod security standards, and namespace-level guardrails.
Built-in admission controllers: Kubernetes 1.25+ includes Pod Security Admission (PSA) built in, replacing the deprecated PodSecurityPolicy. PSA enforces security profiles at the namespace level:
privileged: No restrictions (default)baseline: Prevents known privilege escalation (no privileged containers, no host namespaces, no dangerous capabilities)restricted: Enforces security best practices (non-root, read-only filesystem, dropped capabilities, seccomp required)
Apply at minimum baseline to all namespaces; restricted to namespaces running untrusted or multi-tenant workloads.
External admission webhooks: External admission controllers (OPA/Gatekeeper, Kyverno) allow custom policy definition in Rego or YAML. Common uses:
- Require signed images (validate Cosign signatures before allowing image pull)
- Enforce image registry allowlists (only allow images from internal registry)
- Require specific labels for all Pods (owner, team, environment)
- Block privileged containers, hostPath mounts, host network usage
Policy as code: Admission control policies belong in version control alongside application code. Test policies against known-good and known-bad manifests in CI before deploying to the cluster. Kyverno's policy reports provide ongoing compliance scanning of existing resources.
Container Escape and Lateral Movement: What Defenders Miss
Container escape attacks move from container-level code execution to host-level compromise. The techniques exploit misconfigurations more often than CVEs.
Common container escape vectors:
Privileged containers: A container running with privileged: true has full access to host devices and can mount the host filesystem trivially. Privileged containers are equivalent to root on the host. Never use privileged containers in production; replace with specific capability grants.
Mounted host paths: hostPath volume mounts that include /, /proc, /sys, or /etc give a container near-complete host access. Audit all hostPath mounts; restrict to specific safe paths (e.g., /var/log) with read-only access where possible.
Docker socket mounting: Mounting the Docker socket (/var/run/docker.sock) into a container allows that container to control the Docker daemon and spawn new privileged containers. This is a complete container escape. CI/CD systems that need Docker-in-Docker should use rootless Podman or Kaniko instead.
Lateral movement between pods: By default, all pods in a Kubernetes cluster can communicate with all other pods across all namespaces. NetworkPolicies define allowed traffic patterns — they are the container equivalent of microsegmentation. Apply default-deny NetworkPolicies in every namespace, then allowlist only the specific pod-to-pod connections the application requires.
Container Security Toolchain Reference
Layer 1 (Supply chain): Sigstore/Cosign for image signing, Syft for SBOM generation, Grype for vulnerability scanning against SBOMs, Trufflehog for secrets detection in build artifacts.
Layer 2 (Image scanning and hardening): Trivy (broad CVE, IaC, and secret scanning), Grype (SBOM-based vulnerability scanning), Dockle (Dockerfile best practice linting), hadolint (Dockerfile static analysis).
Layer 3 (Runtime): Falco (open-source runtime security), Sysdig Secure (commercial Falco-based), Aqua Security, Prisma Cloud (formerly Twistlock), StackRox/OpenShift ACS.
Layer 4 (Kubernetes posture): kube-bench (CIS Benchmark compliance checks), Polaris (workload configuration analysis), Kubescape (NSA/CISA hardening guide compliance), Kyverno or OPA/Gatekeeper (policy enforcement).
Commercial platforms (Wiz, Orca, Lacework, Aqua, Sysdig) provide unified coverage across Layers 1-4 with a single agent and management plane, reducing operational complexity at the cost of licensing spend.
The bottom line
Container security that starts and stops at image scanning is checking one box out of four. Supply chain integrity, runtime behavioral detection, and Kubernetes admission control are where the majority of container-related incidents originate — and where most security programs have the largest gaps. Build the supply chain controls into CI/CD pipelines, deploy runtime monitoring with meaningful behavioral rules, enforce Pod security standards with admission controllers, and apply default-deny NetworkPolicies. That combination addresses the full attack surface, not just the visible part.
Frequently asked questions
Is container image scanning enough for container security?
No. Image scanning finds known CVEs in image layers at build time. It does not catch: malicious packages without CVEs, supply chain compromises injected into clean-looking dependencies, runtime exploitation of application vulnerabilities, container escapes, or lateral movement between pods. Runtime protection, admission control, and supply chain integrity controls are required to address the full attack surface.
What is a Software Bill of Materials (SBOM) and why does it matter for containers?
An SBOM is a machine-readable inventory of every component in a container image — OS packages, language libraries, and binaries. It matters because when a new CVE drops, you can query your SBOM inventory to identify which images are affected in minutes. Without SBOMs, identifying affected images requires rescanning every image in production, which takes hours or days.
What is Falco and how does it work?
Falco is an open-source CNCF runtime security tool that uses eBPF or kernel module interception to observe system calls from every container. It evaluates each system call against policy rules and generates alerts when containers deviate from expected behavior — spawning shells, making unexpected network connections, accessing sensitive files, or exhibiting container escape indicators.
How do Kubernetes NetworkPolicies prevent lateral movement?
By default, all pods in a Kubernetes cluster can communicate with all other pods across all namespaces — a flat network. NetworkPolicies define allowlisted ingress and egress rules. A default-deny NetworkPolicy in each namespace blocks all pod-to-pod traffic not explicitly allowed. This limits the blast radius of a compromised pod to only the services it is explicitly authorized to reach.
What is the risk of running privileged containers?
A privileged container has full access to host devices and can mount the host filesystem. An attacker with code execution in a privileged container effectively has root on the host node. This is the most common and most severe container escape vector. Never use privileged containers in production; replace with specific Linux capability grants for the exact privileges the application requires.
What is Sigstore/Cosign and how does image signing improve security?
Cosign (part of the Sigstore project) creates a cryptographic signature for a container image at build time, stored in the image registry alongside the image. Admission controllers can require a valid signature before allowing image execution in the cluster. This prevents: images built outside the authorized CI/CD pipeline, tampered images (modified after signing), and images pulled from unauthorized registries.
Sources & references
- CISA/NSA Kubernetes Hardening Guidance
- NIST SP 800-190: Application Container Security Guide
- Sysdig 2025 Cloud Native Security Report
- Google SLSA Framework Documentation
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.