Why do static scans miss the real risk in container images?

Why This Matters for Security Teams

Static image scanning is useful, but it is not a complete risk answer. A scan can confirm whether a package version maps to a known vulnerability record, yet it cannot prove exploitability in the target deployment. That gap matters because container images are often rebuilt, promoted, and patched faster than scanners are rerun, and because the same vulnerable library may be unreachable in one service and directly exposed in another. The NIST Cybersecurity Framework 2.0 emphasises continuous risk management, which is the right lens here.

Security teams often overestimate a clean scan result and underestimate runtime conditions such as privilege, network policy, mounted secrets, and orchestration controls. A container image can look low risk at build time and still become the easiest path to lateral movement if it ships with broad credentials, embedded tooling, or an exposed admin port. In practice, many security teams encounter the real exposure only after a workload is already running with production data and production reachability, rather than through intentional risk-based validation.

How It Works in Practice

Static scanning primarily checks the image layer content against a vulnerability database, policy rules, or software bill of materials signals. That helps identify known issues, but it does not answer whether the vulnerable component is imported, reachable, or protected by compensating controls. A better workflow combines build-time scanning with runtime context, admission checks, and exposure analysis.

Practitioners usually need to evaluate four questions together: is the issue actually present, is the affected code path loaded, can the service be reached, and can an attacker turn it into an outcome that matters. That is where container security moves from simple inventory to operational risk. The image may include many packages that are never executed, while a tiny exposed utility can create a serious blast radius if it runs with elevated privileges or can talk to internal APIs.

• Confirm the software inventory with image and dependency scanning, then correlate findings to an SBOM where available.
• Check whether the vulnerable component is reachable in the deployed service path, not just present in the file system.
• Use admission controls to block known-bad images, but pair them with runtime monitoring and policy enforcement.
• Review network policy, Linux capabilities, mounted secrets, and service account permissions to measure practical exposure.
• Feed findings into risk acceptance and patch prioritisation, rather than treating every CVE as equal.

This approach aligns with control thinking in the NIST Cybersecurity Framework 2.0, where identification, protection, detection, and response are meant to work together. It is also consistent with modern container guidance from the OWASP Kubernetes Top 10, which highlights how misconfiguration and over-permissioning can matter as much as software flaws. These controls tend to break down when images are reused across many services with different runtime permissions because the scanner sees one artifact while production risk depends on multiple deployment contexts.

Common Variations and Edge Cases

Tighter scanning often increases build friction and review overhead, requiring organisations to balance deployment speed against confidence in exposure. That tradeoff is especially visible in fast-moving CI/CD pipelines, where teams may suppress findings to keep releases moving.

Best practice is evolving for severity scoring because there is no universal standard for how to combine CVSS, exploitability, reachability, and business context into one decision. A package with a critical CVE may be harmless if it is dead code in an internal-only job, while a medium-severity issue can be more urgent if the container handles internet-facing traffic, secrets, or privileged node access. Temporary exceptions are sometimes justified, but they should be time-bound and tied to compensating controls such as network segmentation, read-only filesystems, or rapid patch replacement.

Another edge case is supply chain drift after the scan. Images can be retagged, rebuilt from mutable base layers, or altered by a downstream process after the original assessment. That is why provenance, immutable references, and repeated verification matter. For teams dealing with identity-heavy workloads, the same logic applies to non-human identities and secrets embedded in the image or injected at runtime: if a container can reach a secret, the scan result alone does not describe the full attack path.

In short, static scans are a starting point, not a decision engine. The real question is not only what exists in the image, but what an attacker can actually do with it in the live environment.

Related resources from NHI Mgmt Group

• Why do quarterly privileged access scans miss real risk?
• Why do static access reviews miss the real identity risk in modern environments?
• Why do static pentest scopes miss real-world risk?
• Why do periodic access reviews miss the real NHI risk?