Build-time container scanning is necessary. It is not sufficient.
The reason is straightforward: the CVE landscape changes continuously after an image is built. A container image scanned clean at build time accumulates new vulnerabilities as CVEs are disclosed against its packages, as dependencies are updated, and as the image remains in production without being rebuilt. Build-time scanning captures a point-in-time assessment. Runtime detection provides continuous coverage.
This gap matters more than teams typically account for. A containerized application that ships monthly has a 30-day window in which new CVEs are disclosed against its dependencies without triggering a rescan. If a Critical CVE is disclosed on day 3 after release and the next build cycle is day 30, the vulnerability runs in production for 27 days before anyone knows.
What Build-Time Scanning Cannot See?
Post-deployment CVE disclosure: New CVEs published against the packages in a running container are not detected by build-time scanning. The build-time scan captured the CVE state at build. The runtime state reflects subsequent disclosures.
Runtime state drift: A container image that was clean at build time may have processes injected at runtime through orchestration side-effects, configuration mounts, or compromised init containers. Build-time scanning evaluates the image layers; it cannot see what happens after the container starts.
Dynamic loading: Some applications load code at runtime that is not part of the container image. Python applications may load plugins from a mounted volume. Java applications may use reflection to instantiate classes from runtime-provided JARs. These dynamically loaded components are not captured by image scanning.
Configuration-dependent attack surface: Some CVEs are only applicable in specific configurations. An application that enables a specific feature flag at runtime may activate a code path with a CVE that was irrelevant in the default configuration at build time.
Runtime Detection Approaches
Continuous CVE database matching against running images: The simplest form of runtime detection: when a new CVE is published, match it against the package inventory of all running container images. This does not require instrumentation in the containers — it requires knowing what is running (from the container registry scan records) and receiving new CVE disclosures (from the vulnerability database feed).
This approach provides the CVE disclosure detection coverage that build-time scanning misses. When CVE-2025-XXXXX is published against OpenSSL 3.0.x, an alert is triggered for every running container that has OpenSSL 3.0.x in its scan record.
Behavioral drift detection: Monitor running containers for deviations from their established behavioral baseline. The baseline is established during the initial deployment by profiling the container’s normal operation. Deviations from the baseline — new network connections, unexpected process spawns, unusual file access patterns — trigger alerts.
Container security behavioral drift detection catches post-deployment compromise attempts that CVE scanning cannot detect: an attacker exploiting a CVE to gain code execution in the container and then attempting lateral movement would produce behavioral deviations that appear in the drift detection system.
Runtime SBOM verification: Periodically verify that the software actually running in the container matches the expected inventory. If runtime behavior is observed that implicates packages not in the container’s SBOM, the discrepancy is flagged for investigation.
The Complementary Layer
Build-time scanning and runtime detection are complementary, not competitive. They address different threat windows:
Build-time scanning: Prevents known-vulnerable images from being deployed. Effective at the point of deployment; not effective for CVEs disclosed after deployment.
Runtime detection: Provides continuous coverage against newly disclosed CVEs and detects post-deployment behavioral changes. Not a substitute for build-time scanning because it cannot prevent initial deployment of a vulnerable image.
The security program that combines both:
- Build-time: image is scanned before deployment, Critical CVEs block deployment
- Post-deployment: continuous CVE database matching alerts on new disclosures against running images
- Runtime: behavioral monitoring detects anomalies in running container behavior
Hardened container images improve the effectiveness of runtime detection by reducing the expected behavioral baseline. A hardened container with fewer installed packages has a simpler, more predictable behavioral profile. Anomaly detection on a simple baseline is more precise than anomaly detection on a complex one with many expected behaviors that are hard to distinguish from unexpected ones.
Frequently Asked Questions
Why is build-time container vulnerability scanning not enough?
Build-time scanning captures a point-in-time CVE state at the moment the image is built. After deployment, new CVEs are continuously disclosed against the packages in running containers — a clean image on day 1 can accumulate significant new vulnerabilities by day 30 without any code changes. Additionally, build-time scanning cannot see runtime state drift, dynamically loaded code, or configuration-dependent attack surfaces that only activate after the container starts.
What does runtime container security detection add beyond build-time scanning?
Runtime detection provides continuous coverage for CVEs disclosed after deployment by matching new CVE database entries against the package inventory of all running containers. It also enables behavioral drift detection, which establishes a baseline of normal container behavior and alerts when deviations occur — such as new network connections or unexpected process spawning — that may indicate exploitation of a vulnerability. These capabilities address the threat windows that build-time scanning is structurally unable to cover.
How does runtime detection work with container vulnerability scanners?
The most practical form of runtime detection pairs the existing container vulnerability scanner’s image inventory with CVE database feed subscriptions. When a new CVE is published, it is automatically matched against the package composition of all running images recorded during the last build-time scan. Matches generate alerts with affected image details and severity-based response triggers — Critical CVEs prompt expedited rebuilds within 72 hours, while lower severity findings are queued for the next remediation cycle.
Do hardened container images improve runtime security monitoring?
Yes. Hardened containers with fewer installed packages produce simpler, more predictable behavioral baselines. Anomaly detection is more precise against a lean baseline than against a complex one where many expected behaviors are difficult to distinguish from unexpected ones. The CVE reduction from hardening also directly reduces the number of runtime CVE alerts, since packages that have been removed cannot generate new disclosures.
Practical Runtime CVE Coverage
Implementing continuous CVE database matching against running images:
Step 1: Maintain a running image inventory
Every container running in production should be inventoried with its image digest. The inventory is updated as deployments change.
# Kubernetes pod image inventory
kubectl get pods –all-namespaces -o jsonpath='{range .items[*]}{.spec.containers[*].image}{“\n”}{end}’ | sort | uniq
Step 2: Subscribe to CVE database feeds
CVE databases publish feeds of new CVE additions and updates. Subscribe to these feeds to receive new CVE notifications as they are published.
Step 3: Match new CVEs against running image inventory
When a new CVE is published, check it against the package inventory of all running images. If a match is found, generate an alert with the affected image and the CVE details.
Step 4: Trigger response based on severity
- Critical CVEs: immediate alert with expedited remediation trigger (rebuild and redeploy within 72 hours)
- High CVEs: alert with standard remediation priority (address within SLA)
- Medium/Low CVEs: add to the findings queue for next scheduled remediation cycle
Runtime detection converts the static build-time scan into a continuous coverage program. The image scanned clean today is still monitored tomorrow, and the day after, for every new CVE that might be disclosed against its packages.