For years, we treated software as something that could be built, secured, and shipped. But today’s enterprise applications are no longer static artifacts. Instead, they’re living and breathing systems shaped not only by the code they contain, but by the environments they operate in.

According to the Nutanix Enterprise Cloud Index, more than 85 percent of organizations operate across multiple environments, with hybrid multi-cloud now the dominant model. At the same time, most organizations are supporting development across five to seven open source languages, often running on multiple operating systems. This creates a complex environmental matrix that is difficult to track, standardize, and secure, introducing additional layers of risk as dependencies and configurations diverge across environments. 

Moreover, teams are actively modernizing applications and increasing their use of containers. Nutanix reports that 87% of cybersecurity executives expect the level of application containerization within their organization to increase across 2026. Moreover, 85% believe AI is accelerating container adoption in a meaningful way.

But with great adoption comes even greater responsibility, and the industry is quickly turning to container hardening as a catch-all response to the growing number of dependency challenges that exist within open source containers.

Before we continue, it’s important to note that we’re not here to bad mouth hardened containers. In many ways, they’re a logical and necessary step to safeguarding against open source vulnerabilities. But, hardened containers assume that risk can be contained within the artifact itself. 

Unfortunately, this is not true. In fact, the moment a container is deployed, it enters into this “living system” and, much like any living thing, it is subject to the one and only constant: change itself.

What follows is a clear look at where container hardening delivers value, where it breaks down, and what it takes to secure software as a system that continues to evolve long after the image is built.

What Is Container Hardening, Really?

At its core, a hardened container is an attempt to reduce risk before anything ever runs.

In practice, it follows two steps. First, scan the container for vulnerabilities. Second, remediate as many of those vulnerabilities as you can.

Scanning is typically handled by Software Composition Analysis (SCA) tools, which identify issues like Common Vulnerabilities and Exposures (CVEs) by checking dependencies against known databases such as MITRE. This gives teams visibility into what is already broken or exposed within the image.

Remediation, though, is where container hardening takes shape. Unnecessary packages are removed and vulnerable components are patched or replaced. The goal is to minimize the attack surface and reduce exposure to known threats.

Once you scan and remediate, what you’re left with is a hardened container.

But container hardening has limits, and a container can never be perfectly safe. Why? Because open source builds on open source, often pulling in dozens or hundreds of dependencies along with it. And as AI accelerates development, it increases both the velocity and volume of those dependencies entering the system, compounding the challenge and expanding the surface area where vulnerabilities can exist.

Why Hardened Images Became the Default Answer

It’s not surprising that container hardening became a default practice. It solves a problem that’s easy to see. And when security teams are under pressure to reduce exposure and demonstrate defensible progress, hardened containers provide an easy win. 

It also aligns well with how teams already work. Hardening fits naturally into the build pipeline, and it doesn’t require a fundamental change in ownership or process. You simply scan, remediate, and ship. 

But while hardened images provide clarity at build time, what they do not provide is security continuity. And in a system that continues to change after deployment, that gap becomes the real source of exposure.

The Four Security Gaps Hardened Containers Cannot Solve

To understand the limits of container hardening, you have to look beyond the build process. These four gaps highlight where hardened containers lose visibility and control once the system is live.

1. Runtime Drift and Configuration Decay

Containers are often described as immutable. In practice, they are anything but.

The moment a container is deployed, it begins to interact with its environment. Sometimes configuration or environment variables shift and change. Some other times, orchestration layers introduce new dependencies and behaviors. What matters is that, over time, the running system diverges from the hardened image it started as.

This is runtime drift.

It’s subtle, continuous, and rarely tracked with the same rigor as build-time security. But in most cases it’s where systems move furthest away from their original security posture.

What we’re trying to say is: Container hardening is great for defining a starting point. But optimizing against runtime drift will define how secure your application is when it’s actually running.

2. Dependency Sprawl and Hidden Transitive Risk

Modern applications rely on deep dependency trees, often introducing dozens or hundreds of transitive dependencies that are not directly visible to the team building the container. Each of these components carries its own risk profile, its own update cycle, and its own vulnerabilities.

Hardening focuses on the image you can see. It does not fully account for the dependencies you inherit.

As AI accelerates development and dependency usage increases, this hidden layer becomes one of the largest sources of exposure.

3. End-of-Life Software Inside Secure Images

End-of-life software is a clear gap that hardened containers cannot solve for. Once a component is no longer maintained, it no longer receives patches or security updates. Any vulnerability discovered after that point remains exposed indefinitely.

Put simply, you cannot secure software that is no longer supported. And this creates a dangerous illusion. While an image may appear clean at build time, the underlying components are aging out of relevance the moment they are deployed.

4. The Remediation Ownership Problem

When vulnerabilities continue to emerge after the image is in use, it’s easy for developer ownership to become entirely unclear. For example:

• Who is responsible for fixing the issue?
• Who rebuilds the image?
• Who ensures the updated version is redeployed across environments?

In many organizations, the answer is fragmented across teams. If cybersecurity teams identify challenges, development teams own the code, and platform teams manage deployment, no single group owns the full software lifecycle.

Without clear ownership over who handles post-deployment vulnerability remediation, images can remain vulnerable inside a live application for much longer than intended. In fact, the average Mean Time To Remediate (MTTR) for vulnerabilities is around 140 days, extending the window of exposure and significantly increasing risk.

Side Note: What’s The Difference Between Artifact Security and System Security?

Here’s the scoop: 

Artifact security focuses on the container itself. For instance, is the image clean? Are known vulnerabilities patched? Does it meet a defined baseline at build time?

System security, on the other hand, looks beyond the image. It asks how that container behaves once it is deployed, how it interacts with other services, and how risk evolves over time.

This distinction matters. A lot. An artifact can be secure at the moment it is built and still introduce risk as it runs. If you secure the system, however, you are managing risk as it actually exists.