Why container security only works when the platform owns it

Container security has finally gone mainstream.

When Docker announced hardened container images in late 2025, complete with minimal attack surfaces, non-root defaults, continuous CVE scanning, and automated updates, the response was enthusiastic. For teams managing their own infrastructure, this was a real step forward. Secure-by-default containers are no longer niche or expensive. They are expected.

But that moment also exposed a misunderstanding that still shows up in many organizations:

Hardened images alone do not make a secure platform.

At scale, container security is not a feature you adopt once. It is an ongoing operational responsibility that has to be owned, automated, tested, and governed somewhere. 

The question is not whether containers are hardened, but who carries the burden of keeping them that way over time.

The illusion of “one hardened image”

The idea of a single, hardened base image is appealing. One image, carefully locked down, continuously patched, and reused everywhere. Simple. Auditable. Safe.

That model breaks down quickly in real production environments.

Most teams run more than one runtime. PHP, Python, Node.js, Java, databases, caches. Each runtime has multiple supported versions. Many rely on native extensions compiled against specific system libraries. Change the wrong dependency and applications break in subtle, expensive ways.

This is where security and stability collide.

If you upgrade a base image aggressively to chase the latest patches, you risk breaking workloads. If you delay upgrades to protect stability, you increase exposure. Managing that tradeoff is not something most application teams are equipped to do repeatedly and safely.

At scale, the problem is not hardening an image.

It is maintaining hundreds of versioned images, each with different compatibility constraints, while keeping all of them secure.

What secure containers actually require at scale

Once you move beyond toy examples, container security becomes an exercise in systems engineering.

A secure platform has to handle, continuously:

• Multiple runtimes and runtime versions
• ABI compatibility for native extensions
• OS-level package updates and security patches
• Controlled rollout and regression testing
• Emergency response paths for critical vulnerabilities
• Predictable, auditable update behavior

This work is repetitive, unglamorous, and easy to underestimate. It cannot be handled manually, and it cannot be delegated piecemeal to application teams without introducing risk.

That is why mature platforms treat container security as invisible infrastructure. Something that runs continuously in the background, absorbs complexity, and fails safely.

The platform approach: security without heroics

Upsun has taken this approach from the beginning.

Rather than maintaining a single “golden” container image, Upsun maintains hundreds of images across runtimes and versions. Each image is built, updated, and tracked independently to preserve compatibility while still receiving security updates.

This is not done through ad-hoc rebuilds or manual patching. The system is fully automated and declarative. Package versions are defined explicitly. Updates are detected programmatically. Images are rebuilt only when something actually changes.

Most of the time, nothing happens. And that is exactly the point.

Security at scale should be boring. It should rely on automation, not vigilance. When updates are needed, they should flow through a predictable pipeline that prioritizes correctness as much as speed.

Why testing cadence matters more than patch speed

Security conversations often focus on how quickly patches are applied. Speed matters, but speed without control is dangerous.

Database engines, language runtimes, and system libraries are not interchangeable parts. A broken update can corrupt data or cause prolonged outages. That risk is unacceptable for a platform running production workloads.

For this reason, Upsun separates building updates from deploying them.

Images are continuously monitored and rebuilt as packages change. Deployment to production follows a measured cadence, with full testing before rollout. Updates first land in internal testing environments, then progress safely toward production.

There is one exception: critical vulnerabilities with active exploitation. In those cases, the platform can fast-track updates through an accelerated path. This capability exists precisely because the normal system is automated and well understood.

The result is a balance most teams struggle to achieve on their own:

• Fast response when it truly matters
• Stability and predictability the rest of the time

What this changes for application teams

The practical impact of this model is simple, but profound.

Application teams do not need to:

• Track OS-level CVEs
• Rebuild base images
• Coordinate patch rollouts
• Worry about breaking native extensions
• Decide when security updates are “safe enough”

Instead, responsibilities are clearly divided:

• The platform owns system packages, base images, and security updates
• Teams own application code and application-level dependencies

This division of labor is what turns infrastructure from a constant source of risk into a stable foundation.

It also reduces cognitive load. Engineers can focus on shipping features, not evaluating whether a new OpenSSL patch might destabilize their runtime.

The one responsibility platforms cannot absorb forever

There is an important boundary that serious platforms are honest about.

No amount of automation can secure software that is no longer maintained upstream. When a runtime or operating system version reaches end of life, security updates stop. At that point, the only safe option is to upgrade.

Upsun enforces this boundary intentionally. Images tied to unsupported base systems eventually stop receiving updates. This is not a limitation of the platform; it is a reflection of reality.

Regular runtime upgrades are not about chasing novelty. They are about staying on supported foundations that can actually be secured. A platform can make upgrades safer and easier, but it cannot make abandoned software safe.

Clear boundaries build trust.

What Docker’s announcement actually validates

Docker’s move to make hardened images free and open source is good for the industry. It acknowledges what experienced platform teams already know:

Container security cannot be bolted on. It requires automation, continuous maintenance, and disciplined rollout.

That is exactly the model Upsun has been running in production for years, not as a feature launch, but as a necessity. When you operate a platform that hosts thousands of applications across many runtimes, manual security work simply does not scale.

The work that matters most is not flashy. It is the repetitive, automated checking of packages, the careful rebuilding of images, the testing pipelines, and the controlled deployments. That is what keeps systems secure over time.

Security as a property of the platform

The real takeaway is not about who did it first.

It is about where security belongs.

Hardened images are valuable. But without a platform that owns updates, testing, rollout, and lifecycle management, they shift responsibility onto teams that are already overloaded.

When security is handled at the platform layer, it stops being a recurring crisis and becomes part of the background. That is what allows teams to move faster without increasing risk.

That is what a platform is for.

Explore further

• Explore Upsun’s security and compliance model
  Learn how Upsun handles security as part of the platform, not as an add-on.
• Read the technical deep dive on container hardening
  For a detailed look at how images are built, updated, and tested, see the original Dev Center article.