Best Practices for Balancing Container Security with Operational Efficiency

Businesses need their software to be secure. They also need their application development and deployment processes to be fast and efficient.

Unfortunately, these two goals don’t always go hand-in-hand. Too often, security comes at the expense of operational efficiency (or vice versa) – especially in the context of modern, containerized workloads, whose complexity makes it extra challenging to balance security with efficiency.

Indeed, according to our 2025 State of Container Security report, 49 percent of organizations cite “time and resource constraints” as a primary hindrance in keeping containers secure. Nearly a quarter also said they had experienced container security breaches in the past year, likely due to having cut corners on the security front for the sake of operational efficiency.

The good news is that it doesn’t have to be this way. It’s possible to achieve the best of both worlds – container security paired with operational efficiency. Doing so requires business leaders to set the right tone for development teams and drive strategic investments in technology that enables secure containerized applications without compromising on efficiency.

Container security vs. operational efficiency: Why it can be hard to achieve both

The core reason why it can be tough for businesses to achieve high container security standards while also maintaining operational efficiency is simple enough: The more software developers include within containers, the easier it is to build, deploy, and maintain applications – but at the same time, more software also increases the risk of vulnerabilities that lead to breaches.

For example, more than half of developers say they need shells inside container images, and 39 percent want package managers, according to the report mentioned above. This makes sense because shells make it possible to run commands, which can help when administering an application. Package managers streamline the process of adding software when building container images and running containers.

The downside, though, is that shells, package managers, and other additional components also make it easier for the bad guys to execute malicious code or deploy malware. Removing this software from containers hardens them against attack, although it makes life harder for developers and IT teams.

Data shows that, in practice, a majority of teams prioritize operational convenience and efficiency over security. More than half of organizations we surveyed build their containers using general-purpose Linux distributions, which include a host of tools and utilities that bloat the attack surface.

This happens despite the fact that developers are most likely to cite security as their top priority when choosing a container-based image. What developers say about container security appears to diverge from what they actually do (at least from the perspective of minimizing attack surfaces and avoiding software bloat).

Squaring the circle: Keeping containers secure and efficient

But again, businesses don’t actually have to choose between security and efficiency. They can have it all by implementing a container security strategy founded on principles like the following.

1) Invest in risk prevention, not just monitoring

While monitoring for container security risks at runtime (meaning after applications are up and running) is important, organizations should also invest heavily in preventing risks from occurring in the first place.

One of the easiest ways to do this is to build containers using base images that include minimal code. The less code that runs when a container starts up, the fewer vulnerabilities there are for attackers to exploit.

2) Separate runtime container images from development images

A potential objection from developers about using minimalist container base images is that they need the tools that larger images provide. But often, they only require those tools during application development and testing, not within production runtime environments.

If this is the case, there’s a simple solution: Teams can use fuller “debug builds” of their containers, which include more utilities, during the development process, then migrate to hardened, minimal runtime images for production. This makes it possible to run the diagnostics and testing that developers want to perform during development, while still minimizing the risk of vulnerabilities in production environments.

3) Optimize application runtimes

Another way to boost the performance and operational efficiency of containers without compromising on security is to choose base images that include optimized runtimes (such as lightweight Java distributions)

Lightweight runtimes are carefully tuned to maximize CPU and memory efficiency, delivering footprints that reduce resource utilization by up to 30%. They’re also optimized for security, thanks to the removal of unnecessary components that bloat the attack surface.

Generic open-source base images don’t usually include optimized runtimes, but this type of solution is available from third-party developers that specialize in security–and in performance-centric base images.

4) Partner with upstream developers on security

Many base container images (even minimalist ones, like Alpine Linux) are developed by open-source projects that provide no guarantee about vulnerability prevention or mitigation. This means that organizations that use those images are on their own when it comes to dealing with security risks.

But fortunately, this isn’t always the case. Container image vendors exist that do provide support guarantees for their software, resulting in base images that are fully compatible with popular open-source distributions like Alpine, but with the added benefit of professional support and management. Choosing these images in lieu of generic open-source base images goes a long way toward alleviating the risk management and support burden that development teams face, which is another way to boost operational efficiency, since it leaves engineers with more time to do actual engineering work and less time chasing vulnerabilities.