Why Vulnerability Scanning Alone Is Not Enough

For years, vulnerability scanning has been the default answer to container security. Build the image, scan it for CVEs, patch what you can, and move on.

That approach made sense when software environments were smaller and release cycles were slower. But modern containerized environments operate differently. Applications are assembled from layers of inherited dependencies, rebuilt continuously, and deployed at massive scale across dynamic infrastructure.

In that environment, scanning is still useful, but it is no longer sufficient. It tells you what vulnerabilities are already present after software has been assembled. It does not control what entered the image in the first place, whether the build process was trustworthy, or whether the software can actually be trusted at runtime.

Container security today is less about detecting bad packages after the fact and more about reducing inherited risk before it spreads across environments.

What Vulnerability Scanning Actually Does

A vulnerability scanner compares software packages against databases of known Common Vulnerabilities and Exposures (CVEs). For container images, scanners typically inspect operating system packages, application dependencies, language libraries, and known vulnerable versions.

That visibility is valuable. For many organizations, scanners are the primary way security teams understand what exists inside container images and identify outdated or vulnerable software before deployment.

The limitation is that scanning happens after the image already exists. By the time a vulnerability is identified, the dependency has already been inherited, trusted, assembled into the image, and often deployed across multiple environments.

That becomes difficult to manage at scale.

A typical enterprise container image inherits software from several upstream layers. Base images alone may contain hundreds of packages, even when the application itself only needs a small subset of them. Every unnecessary package increases the attack surface and creates additional software that must be monitored, patched, and maintained.

For example, a team building a simple Python API may inherit a full Linux userland through a general-purpose base image. Even if the application only requires a Python runtime and a few libraries, the final image may still include shells, package managers, networking tools, and legacy utilities unrelated to the workload itself.

Teams quickly discover that identifying vulnerabilities is often easier than fixing them.  

Remediation may depend on upstream maintainers releasing patches, base image providers rebuilding artifacts, internal CI/CD pipelines completing successfully, and production deployment windows becoming available. Security becomes dependent on layers of software the application team does not directly control.

The Bigger Problem: Scanners Measure Exposure, Not Trust

One of the biggest limitations of vulnerability scanning is that it measures known exposure, not software integrity.

A scanner can tell you whether a package version is associated with a known CVE. What it cannot tell you is where that software originated, whether dependencies were substituted during the build process, whether the pipeline itself was compromised, or whether the image was modified after creation. Vulnerability data measures exposure. It does not establish trust.

That distinction matters because many modern attacks target the software supply chain itself rather than exploiting runtime vulnerabilities directly.

The xz/liblzma incident (CVE-2024-3094) demonstrated this clearly. Malicious code was quietly introduced upstream into a trusted open-source project and distributed through legitimate channels before most organizations realized anything was wrong. Traditional vulnerability scanning was not designed to detect that type of compromise because there was no existing signature available when the malicious code first entered environments.

Modern supply chain attacks increasingly exploit trusted relationships in the development ecosystem:

• compromised maintainer accounts

• dependency confusion attacks

• typosquatting packages

• malicious pipeline modifications

• tampered artifacts in registries

These attacks bypass traditional assumptions about trusted software sources.

Scanning helps identify known vulnerabilities. It does not verify whether software itself is trustworthy.

The Operational Reality of Alert Fatigue

Most security teams eventually encounter another problem: too many alerts with too little context.

Scanners typically match package versions against CVE databases without understanding how software behaves at runtime. They generally cannot determine whether a vulnerable function is actually reachable, whether exploit conditions exist, or whether compensating controls already reduce the practical risk.

As a result, engineering and security teams spend large amounts of time triaging findings that may never be exploitable in practice.

Over time, scanner output starts becoming operational noise rather than actionable intelligence. Vulnerability queues continue growing while teams still struggle to determine which issues meaningfully increase risk.

This is one of the reasons many organizations are rethinking the role of scanning in container security. The issue is not that scanners are ineffective. The issue is that they were never designed to serve as the primary security boundary for highly distributed software supply chains.

Even when vulnerability findings are accurate, they still represent only one layer of container risk.

A Clean Scan Does Not Mean a Secure Environment

Even an image with zero critical CVEs can still be highly vulnerable in production.

A container running with root privileges, unrestricted network access, excessive Linux capabilities, or exposed secrets may present serious risk regardless of scan results. Runtime behavior matters just as much as package hygiene.

For example, a container image may pass every vulnerability scan and still expose significant risk if it runs with broad permissions inside a Kubernetes cluster. In that scenario, a simple application compromise can quickly become lateral movement across services or infrastructure.

Container security depends heavily on how workloads are configured, isolated, and verified after deployment. Kubernetes permissions, network segmentation, admission policies, runtime hardening, secret management, and image provenance all influence the overall security posture of a running environment.

A scanner cannot validate most of those controls because many of the most important risks exist outside the image itself.

This is where many organizations begin realizing that container security is fundamentally an architectural problem, not simply a vulnerability management problem.

Security Has to Start Earlier

Modern container security is gradually shifting away from a purely scan-and-patch model toward a broader software trust and integrity model.

The focus is moving earlier in the lifecycle:

• reducing unnecessary software before deployment

• verifying where artifacts originated

• controlling how images are built

• enforcing trust boundaries before workloads reach production

Minimal container images are part of that shift. The fewer packages inside an image, the smaller the inherited attack surface becomes. Some organizations go further by building container images directly from verified source rather than inheriting pre-built operating system layers with unknown dependency chains.

Some organizations are also rethinking the foundation itself by moving away from inherited public base images and toward source-built container images assembled from verified components. CleanStart follows this model by building container images directly from verified source through reproducible build pipelines, reducing inherited CVE exposure and improving software provenance from the start of the lifecycle.

Other controls strengthen trust across the lifecycle. Signed artifacts help verify image authenticity. SBOMs improve visibility into dependencies and software composition. Reproducible builds reduce tampering risk by ensuring artifacts can be consistently recreated. Admission policies prevent unsafe workloads from reaching production environments, while runtime hardening limits what an attacker can do after compromise.

These controls address different parts of the problem. Vulnerability scanning remains valuable, but it becomes one layer within a broader trust model rather than the entire strategy.

Conclusion

Vulnerability scanning remains an important operational control. Organizations still need visibility into known vulnerabilities, outdated packages, and emerging CVEs.

But modern container environments move too quickly and inherit too much upstream complexity for scanning alone to serve as the foundation of security.

By the time a scanner detects a problem, the software has already been trusted, assembled, and potentially deployed across environments.

Effective container security requires a broader approach: reducing unnecessary software, verifying build integrity, enforcing provenance, and hardening runtime environments before vulnerabilities become operational problems.

That shift is driving broader adoption of minimal, source-built, and provenance-aware container foundations designed to reduce inherited risk before deployment.

The goal is not simply to find vulnerabilities faster. It is to build systems that inherit less risk to begin with.