How is the security of your container images?
CTO
João Brito
Information security is often left on the back burner until something serious happens. In containerized environments, this oversight can be costly. Even with good intentions, poorly planned updates expand the attack surface and introduce vulnerabilities that are difficult to detect.
The critical point is that many of these flaws are not in the application code. They are hidden in the inherited base images, filled with obsolete libraries, unnecessary packages, and risks that go unnoticed.
Think of a container image as an old building that you inherited. At first glance, everything seems to work. Over time, leaks, broken locks, and cracks appear. And then you realize that it is not just about minor repairs, but structural problems that affect the entire safety of the building.
With containers, the same thing happens. We inherit images that carry a massive amount of outdated software, often without knowing it. And since the responsibility for this cleanup is not always clear within teams, the decision is to postpone it.
In this article, we show why the traditional approach of continuous maintenance may not be enough. Strategies like multi-stage build offer a smarter path: building securely from the start, reducing complexity and allowing your application to be born in a reliable environment.
The Old Building Problem: Inherited Vulnerabilities in Popular Images
To better visualize what we have discussed so far, let's scan some famous base images on Docker Hub. You can also run this test on your own.
TIP: You can scan official images listed on Docker Hub using tools like Trivy. And, for a complete view of what is running in your Kubernetes cluster, Zora offers a detailed mapping of vulnerabilities and misconfigurations.
All of these images above have more than 10 million downloads and maybe some of them are running in your infrastructure right now.
An important detail: they all use the same base image, Debian 12.10 , which means they already carry, from the start, the same critical vulnerability associated with the package zlib1g.
A similar pattern appears when analyzing database images like Redis, MySQL, and MongoDB. Even without being written in Go, these images include the language binary in their base. At the time of analysis (March/2025), they presented 3 critical vulnerabilities and 31 high-severity ones, as can be seen below.
These critical vulnerabilities, in fact, already have fixes available, which is common in the open source ecosystem. However, these packages need to be updated in a new build of the image. Until that action happens, the vulnerability remains active.
This scenario is not limited to public images. The same happens inside your clusters, with your own images: they accumulate not only vulnerabilities from your code, but also inherited flaws from the bases used. And fixing this is a laborious and expensive process.
In the latest MITRE report on CVEs, it was highlighted that more than 80% of vulnerabilities in containers are in the base images. As we saw above, this is not restricted to a few cases. Even official and widely used images concentrate a significant number of active vulnerabilities, which require continuous work.
The Challenges of Continuous Patching: Here it is necessary to reflect on the cost and complexity involved in the continuous maintenance of images. Every day new vulnerabilities emerge, and most environments already start this journey with a significant amount of old CVEs to be fixed.
Studies point out that each CVE takes, on average, 2 to 15 hours to be fixed.
Doing a simple math calculation, just to resolve the critical and high-severity flaws in the official Nginx image, approximately 140 working hours would be required.
Now, apply this estimate to the volume of images used in your environment. Consider the diversity of stacks, the number of open vulnerabilities, and the time required to remediate them safely.
The result is a high cost in engineering time, build cycles, and manual validations. A constant and barely visible effort that consumes the team's energy without generating direct value, just to maintain the bare minimum: the security of container images.
Complementary Strategies: Shift-left and secure images
In secure development, it is increasingly common to use the "shift-left" strategy, which means anticipating security actions to the earliest stages of the development cycle, rather than leaving them only for deployment. In the case of container images, this translates to ensuring that base images are already secure and validated early on in the development pipeline or build process.
How to Adopt Base Images with Zero Vulnerabilities Following not only the premise of cost reduction, but also of gaining efficiency and especially safety, is how the approach of using a base image with zero vulnerabilities presents itself as the healthiest way out for your environments.
These images can be obtained in two main ways:
1 - Created by the team itself: a team of specialists must produce and maintain the base images of the languages and frameworks used in the environment.
2 - Created and maintained by a partner: the partner team of specialists produces and maintains base images of various languages and frameworks with zero vulnerabilities, performs periodic and constant re-analyses, and updates these images to more secure versions, always maintaining the zero-vulnerability standard. Learn how Getup can help you here.
But... what about debugging tools?
A common objection to using slim images is the absence of administrative and debugging tools. In practice, these tools should not be in the image (we know there is a philosophical discussion here and we can delve deeper into it later); including unnecessary packages contradicts the best practices of container construction, in addition to expanding the attack surface.
Containers should contain only what is necessary to run the application. Nothing more.
Of course, there may be times when it is necessary to investigate something in production. And for that, there are already more secure solutions than keeping internal utilities inside the image. A good example is the use of ephemeral containers for debugging, available natively in kubectl since version 1.25 of Kubernetes. This feature allows spot inspections without compromising isolation or opening unnecessary loopholes.
Conclusion: From the Old Building to a New Secure Structure
I do not intend to exhaust the subject here, but to raise a point that needs to be addressed before it becomes a bigger pain. The proposal of this article is simple: to provoke a reflection on the state of your container images and the impact on your daily routine.
If you can, start by scanning some images you already use. Having a view of what is running right now is the first step in deciding how to handle the problem, whether with your team or with external support.
And if it makes sense to talk about how to accelerate this transition with more security and less effort, we are right here: getup.io/lp/images
Newsletter Getup.
Atualizações sobre Kubernetes e Software Supply Chain Security todos os meses.
Operating Kubernetes in production for more than 13 years. With Quor, this experience extends to software supply chain security as well.
GET UP
© Getup · 2026
