Container security is layered: image scanning (build-time), admission control (deploy-time), runtime detection (run-time), and supply chain (dependency tracking). Each layer catches a different class of issue.
Table of contents
- The four layers
- Image scanning tools
- Admission control
- Runtime detection
- Supply chain security
- What the layered stack looks like
- The image signing deep dive
- The runtime detection in detail
- FAQ
The four layers
Container security breaks into four layers:
- Image scanning. Scan the container image for known vulnerabilities before deployment. Catches CVEs in base images and dependencies.
- Admission control. Decide which images can run in the cluster. Catches images that weren’t scanned, images from untrusted registries, images that violate policy.
- Runtime detection. Watch what running containers actually do. Catches anomalous behavior (unexpected network connections, file access, syscalls).
- Supply chain. Track every dependency from source to deployment. Catches malicious packages, dependency confusion, supply chain attacks.
Image scanning tools
The right tool for build-time scanning:
- Trivy. Open source, fast, comprehensive. Scans OS packages, language packages, and IaC configs.
- Grype. Anchore’s open-source scanner.
- Snyk. Commercial, polished UI, integrates with CI/CD.
- AWS Inspector / GCP Container Scanning. Cloud-native scanners built into the platform.
The team that scans every image before deployment catches 80%+ of known CVEs. The team that doesn’t scan has a 6-month window between a CVE being published and the team finding out.
Admission control
The right tool for deploy-time policy:
- OPA (Open Policy Agent). The standard policy engine. Define policies in Rego; enforce in the Kubernetes admission controller.
- Kyverno. Kubernetes-native policy engine. Simpler than OPA for common cases.
- Sigstore / cosign. Sign images cryptographically; the admission controller verifies the signature.
The team that uses admission control to block unsigned images has a defense against supply chain attacks. The team that runs unsigned images has no protection against a compromised CI/CD pipeline.
Runtime detection
The right tool for run-time anomaly detection:
- Falco. The standard open-source runtime detection. CNCF-graduated.
- Tracee. Aqua Security’s eBPF-based runtime detection.
- Tetragon. Cilium’s eBPF-based runtime detection.
- Sysdig Secure. Commercial runtime detection.
The team that runs Falco catches unusual syscalls (a process spawning a shell, a container connecting to an unexpected host). The team that doesn’t has logs that show network traffic but not what processes are doing.
Supply chain security
The right tools for dependency tracking:
- Sigstore. Sign and verify software artifacts.
- SLSA (Supply-chain Levels for Software Artifacts). A framework for supply chain security.
- SBOM (Software Bill of Materials). Track every dependency.
- Dependency-Track. Open-source SBOM analyzer.
The team that has SBOMs for every image knows what’s running. The team that doesn’t finds out about a vulnerable library when the CVE is published.
What the layered stack looks like
The right architecture for a production cluster:
- Build. Trivy in the CI pipeline. Block the build if vulnerabilities are critical.
- Registry. Sigstore-signed images. The registry rejects unsigned pushes.
- Deploy. Kyverno admission controller. Block unsigned images, images from untrusted registries, images without SBOMs.
- Runtime. Falco running in the cluster. Alert on anomalous behavior; kill the container if it’s clearly malicious.
The team that has all four layers has the modern container security stack. The team that has only one has a single point of failure.
The image signing deep dive
How image signing works in practice:
- Build the image.
docker build -t myapp:1.0 . - Sign the image.
cosign sign --key cosign.key myapp:1.0 - Push to registry.
docker push myregistry.example.com/myapp:1.0 - Verify on pull. The admission controller runs
cosign verifybefore allowing the pod to start.
The signing key is the critical secret. The team that uses a hardware security module (HSM) or a managed key service (AWS KMS, GCP KMS) has the strongest key protection. The team that stores the key in a git repo has a compromise waiting to happen.
Key rotation:
- Annual rotation. Generate a new key, sign new images with it, update the verifier.
- Compromise response. If the key is leaked, rotate immediately and re-sign all images with the new key.
The team that has documented key rotation has a clear response to compromise. The team without one has chaos.
The runtime detection in detail
How Falco detects anomalous behavior:
Falco hooks into the kernel’s syscall interface via eBPF or a kernel module. It evaluates each syscall against a ruleset. When a rule matches, Falco fires an alert.
Example rules:
- “A process spawned a shell inside a container” (suspicious)
- “A container wrote to /etc/passwd” (suspicious)
- “A container made a network connection to a non-allowlisted host” (suspicious)
- “A container is reading sensitive files (/proc, /sys)” (may be normal or suspicious)
Falco outputs alerts in JSON. The team that pipes Falco alerts to a SIEM has centralized detection across the fleet. The team that runs Falco without a SIEM has alerts going to stdout that nobody reads.
Tuning:
- Start with default rules. See what’s noisy.
- Add exceptions for known-good behavior. Reduce noise.
- Add custom rules for known-bad behavior. Catch specific attacks.
- Review weekly. The team that reviews and tunes Falco rules has fewer false positives and more accurate detection.
FAQ
What’s the most important container security tool?
Image scanning. The team that scans every image before deployment catches 80%+ of known CVEs. The team that doesn’t scan finds out about CVEs from production incidents.
Is Trivy better than Snyk?
Different tradeoffs. Trivy is open-source and free. Snyk is commercial, has a better UI, and integrates with more tools. The team that wants free and fast uses Trivy; the team that wants a polished product uses Snyk.
Do I need Falco if I have admission control?
Yes. Admission control catches issues at deploy time; runtime detection catches issues at run time. A vulnerability that wasn’t in any CVE database, a malicious package that passed image scanning, an attacker that got in via stolen credentials - all of these need runtime detection.
What’s an SBOM?
Software Bill of Materials. A list of every dependency in a piece of software. The team that has SBOMs for every image knows exactly what’s running and can respond quickly to CVEs.
How do I scan a container image for vulnerabilities?
Use Trivy, Snyk, or AWS Inspector. The team that scans every image before deployment catches 80%+ of known CVEs. trivy image myapp:1.0 shows the vulnerabilities.
What’s the difference between Trivy and Snyk?
Trivy is open-source and free; Snyk is commercial with a polished UI and CI/CD integrations. Both scan for vulnerabilities. The team that picks Trivy saves money; the team that picks Snyk has a better UX.
Can I run Falco in production without it slowing things down?
Yes. Falco runs in the kernel; the overhead is typically < 1% CPU. The team that monitors Falco’s resource usage has no performance concerns.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: