Your container scanner found zero critical vulnerabilities. Your registry passed the security gate. Then a zero-day in a transitive dependency took down production.
Surface-level container scanning checks the boxes on your compliance checklist, but it won't catch the supply chain attacks that bypass traditional perimeter defenses. Here's what you need to implement instead.
What This Guide Covers
This guide addresses container security for teams running Kubernetes clusters and container registries in production. You'll learn:
- Why image-layer scanning misses application-level risks
- What vulnerability intelligence sources actually matter
- How to enforce policies before containers reach your registry
- Where to integrate security controls in your CI/CD pipeline
This isn't about replacing your existing scanner. It's about understanding what it can't see and filling those gaps.
Key Concepts and Definitions
Perimeter scanning examines container image layers for known CVEs. It catches outdated base images and unpatched system packages. It doesn't analyze the application code or dependencies inside those layers.
Application-focused scanning inspects the software components your developers actually build and deploy: libraries, frameworks, and their transitive dependencies. This matters because 80% of your application code comes from third-party packages.
Curated vulnerability intelligence means someone verifies CVE applicability before alerting you. Public feeds like the National Vulnerability Database list every reported CVE, including theoretical exploits that don't affect your runtime configuration. Curated feeds filter noise and prioritize exploitable vulnerabilities.
Policy enforcement points are gates in your pipeline where you can block builds, reject images, or quarantine containers based on security rules. The earlier you enforce, the less it costs to fix.
Requirements Breakdown
If you're subject to regulatory frameworks, here's where deeper container scanning maps to your obligations:
PCI DSS v4.0.1 Requirement 6.3.2 requires you to manage vulnerabilities through a risk-based approach. Surface scanning of base images satisfies the letter of this requirement but misses the spirit -- you need visibility into application components to assess actual risk.
SOC 2 Type II CC7.1 (System Operations) requires monitoring for security events and vulnerabilities. Your auditor will ask how you detect vulnerabilities in production containers. "We scan images at build time" doesn't answer the question if you can't detect newly disclosed CVEs in running containers.
ISO 27001 Control 8.8 (Management of Technical Vulnerabilities) requires a systematic approach to identifying and addressing vulnerabilities. This means continuous monitoring, not point-in-time scans.
Implementation Guidance
Integrate at Build Time
Add security scanning before your container registry. In your CI/CD pipeline, this looks like:
build → test → security-scan → push-to-registry → deploy
If the security scan fails, the image never reaches your registry. You're enforcing policy at the cheapest possible intervention point.
Most teams put the scan after the registry push. That means vulnerable images sit in your registry until someone notices the alert. Worse, automated deployments might pull and run those images before you can quarantine them.
Define Blocking vs. Warning Policies
Not every CVE deserves to block a deployment. Create tiered policies:
Block on:
- Critical vulnerabilities with public exploits
- Any vulnerability in internet-facing services
- Components with known malware
Warn on:
- High-severity CVEs without active exploitation
- Vulnerabilities in internal-only services
- Deprecated dependencies
Ignore:
- Theoretical vulnerabilities that don't apply to your runtime
- CVEs in unused code paths (if you can verify they're unused)
Document your policy decisions. Your auditor will ask why you deployed a container with a high-severity CVE. "It's a false positive because we don't expose that endpoint" is a valid answer if you can prove it.
Monitor Running Containers
Build-time scanning catches what you knew about when you built the image. Runtime monitoring catches what you learn later.
Set up continuous scanning of your running containers. When a new CVE drops, you need to know within hours which of your production workloads are affected. Consider a scenario where a critical vulnerability gets disclosed in a logging library your team uses across 40 microservices. Without runtime monitoring, you're manually checking manifests and hoping your build-time scan results are still current.
Use Curated Intelligence Sources
Public CVE feeds contain thousands of entries. Most don't apply to your environment. Some are duplicates. Others describe theoretical attacks that require local access to the container filesystem.
Curated sources filter this noise. They verify exploitability, confirm affected versions, and prioritize based on actual risk. This reduces alert fatigue and helps your team focus on vulnerabilities that matter.
Common Pitfalls
Scanning only the final image. Multi-stage Docker builds can hide vulnerable dependencies in intermediate layers. Scan your build environment, not just the production artifact.
Trusting "official" base images without verification. Official doesn't mean vulnerability-free. The Python 3.11 official image might bundle a six-month-old version of pip with known CVEs. Verify, don't assume.
Ignoring transitive dependencies. Your application imports library A. Library A imports library B. Library B has a critical vulnerability. Your surface scan won't catch this unless it analyzes the full dependency tree.
Setting policies once and forgetting them. Threat landscapes change. Review your blocking policies quarterly. What you ignored six months ago might be actively exploited today.
Separating security from deployment velocity. If your security gate adds 15 minutes to every build, developers will find ways around it. Optimize for speed and accuracy; cache scan results, parallelize checks, and fail fast on critical issues.
Quick Reference Table
| Security Control | Implementation Point | What It Catches | What It Misses |
|---|---|---|---|
| Base image scanning | Registry/build time | Outdated OS packages, known CVEs in system libraries | Application dependencies, zero-days |
| Dependency analysis | Build time | Vulnerable libraries, license violations | Runtime configuration issues |
| Policy enforcement | Pre-registry push | Known vulnerabilities before deployment | Newly disclosed CVEs |
| Runtime monitoring | Production clusters | New CVEs in running containers | Build-time misconfigurations |
| Curated intelligence | All stages | Exploitable vulnerabilities, active threats | Theoretical/unverified CVEs |
What to Do Monday Morning
Start with visibility. Pick one production application and scan its full dependency tree. Compare those results to what your current image scanner reports. The gap between those two reports is your risk.
Then move the security gate. Configure your CI/CD pipeline to scan before pushing to the registry. Start with warnings only -- don't block builds yet. After two weeks, review the warnings and define your first blocking policy.
You don't need to solve this in one sprint. But you do need to understand what your current tools aren't seeing.
