Not All Inheritance Is Good: The Risk of Container Images
How is the security of your container images?
CTO
João Brito
Information security is often overlooked until something serious happens. In environments with containers, this neglect can be costly. Even with good intentions, poorly planned updates increase the attack surface and introduce hard-to-detect vulnerabilities.
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 like an old building you inherited. At first glance, everything seems to work. Over time, leaks appear, locks break, cracks form. And then you realize it’s not just about minor repairs, but structural problems affecting the entire security of the building.
With containers, it's the same. We inherit images that carry a vast amount of outdated software, often without knowing. 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 to continuous maintenance may not be sufficient. Strategies like multi-stage build offer a smarter way: building securely from the start, reducing complexity, and allowing your application to be born in a trusted environment.
The Old Building Problem: Inherited Vulnerabilities in Popular Images
To better visualize what we have been discussing so far, let’s scan some famous base images on Docker Hub. You can also perform this test on your own.
TIP: It is possible to scan official images listed on Docker Hub using tools like Trivy. And for a comprehensive view of what is running in your Kubernetes cluster, Zora provides a detailed mapping of vulnerabilities and misconfigurations.
All of these images above have over 10 million downloads and perhaps some of them are running in your infrastructure right now.
An important detail: all of them use the same base image, Debian 12.10 , which means they already carry the same critical vulnerability associated with the zlib1g package from the start.
A similar pattern appears when analyzing database images such as Redis, MySQL, and MongoDB. Even though they are not written in Go, these images include the binary of the language in their base. At the time of analysis (March 2025), they presented 3 critical vulnerabilities and 31 high severity, as can be seen below.
These critical vulnerabilities, indeed, 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 this action takes place, the vulnerability remains active.
This scenario is not limited to public images. The same happens within your clusters, with your own images: they accumulate not only vulnerabilities from your code but also inherited flaws from the foundational images used. And fixing this is a labor-intensive and costly process.
In the latest MITRE report on CVEs, it was highlighted that over 80% of vulnerabilities in containers exist in the base images. As we saw above, this is not limited to a few cases. Even official and widely used images concentrate a significant number of active vulnerabilities that require ongoing 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 number of old CVEs to fix.
Studies show that each CVE takes, on average, from 2 to 15 hours to be resolved.
Doing a simple calculation, just to address the critical and high severity flaws in the official Nginx image would require approximately 140 hours of work.
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 needed to remediate them securely.
The result is a high cost in engineering time, build cycles, and manual validations. A constant and less visible effort that drains the team's energy without generating direct value, merely to maintain the minimum necessary: 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 bringing security actions to the earliest stages of the development cycle, rather than leaving them solely for deployment. In the case of container images, this translates into ensuring that the base images are already secure and validated during the development pipeline or the build process.
How to Adopt Base Images with Zero Vulnerabilities Following not only the premise of cost reduction but also the gain in efficiency and especially security, the approach of using a base image with zero vulnerabilities presents itself as the healthiest solution for your environments.
These images can be obtained in two main ways:
1 - Created by your own team: a team of specialists should produce and maintain the base images of the languages and frameworks used in the environment.
2 - Created and maintained by a partner: the partner’s team of specialists produces and maintains base images of various languages and frameworks with zero vulnerabilities, conducts regular and constant reanalysis, and updates these images to more secure versions while always maintaining the standard of zero vulnerabilities. Learn how Getup can help you here.
But... what about debug tools?
A common objection to using slim images is the absence of administrative and debug tools. In practice, these tools should not be in the image (we know there’s a philosophical discussion here and we can delve deeper at another time); including unnecessary packages contradicts the best practices of container construction, in addition to increasing 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 safer solutions than keeping internal utilities in 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 for targeted inspections without compromising isolation or opening unnecessary vulnerabilities.
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 purpose of this article is simple: to provoke a reflection on the state of your container images and the impact on your daily life.
If possible, start by scanning some images that you already use. Having a view of what is currently running is the first step in deciding how to deal with the problem, whether with your team or external support.
And if it makes sense to discuss how to accelerate this transition with more security and less effort, we are here: getup.io/lp/images
With Quor, security becomes your competitive edge. See how in a personalized demo.