As containers have become the standard architecture for cloud applications over the last ten years, they have greatly improved the velocity of teams delivering products to their customers.
However, for security teams, the challenge with containers is that images are still built mainly from the same package sources that traditional virtual machines were, leaving security organizations with a similar vulnerability footprint to manage across their estate, but with a much higher velocity of change.
The best organizations in the world with the largest investments in security teams and platforms still face hundreds of thousands or even millions of vulnerabilities across their estate. Most organizations can patch only about 10% of the vulnerabilities they detect, and rely on their security platforms to make the most efficient use of their development team's time. That still leaves upwards of hundreds of thousands of vulnerabilities unaddressed, typically in components of the infrastructure that aren’t needed or used by the deployed application. These packages are often just along for the ride—and for attackers, they’re useful entry points.
Let’s take a quick look at nginx to see a typical example of what security operators and development teams face.
Nginx is one of a modern application stack's most commonly deployed containers. It’s a marvel of modern software engineering, scaling and handling incredible throughput and providing a huge amount of flexibility used in software stacks worldwide. It also ships with a variety of tools to allow flexible deployment and debugging.
But here’s the problem: Most of the components in a standard nginx image aren’t used when the container is instantiated. However, the container still has all of these assets and packages available when the container is started if they haven’t been specifically removed during the application build process.
Here is a quick snapshot of just some of the additional packages in the upstream nginx image:
Let's look at where the high-severity vulnerabilities are included. Layer 7 of the upstream image, where utilities were added for development or debugging purposes:
&& apt-get install --no-install-recommends --no-install-suggests -y
curl dev-scripts equivs git libxml2-utils lsb-release
xsltproc
For development, these inclusions make sense, but if you’re building from the upstream nginx image, these utilities will still be present at runtime unless you strip them out. Development and security teams around the globe are spending time building systems and processes to address these types of concerns and assess the impacts. New vulnerabilities are discovered constantly, at an accelerating rate.
In this instance, the vulnerabilities are present in libxml and depend on local access to exploit. Generally speaking, a development team's priority to address them would be low, but a security operator responsible for the infrastructure would need to spend cycles on the noise. They also lack context for the app and may have policies in place that high or critical vulnerabilities require remediation or exceptions.
The nginx team isn’t shipping images they believe to be exploitable; they go to great lengths to evaluate whether a vulnerability impacts them, including evaluating their upstream sources, whether the vulnerability is applicable, or if there is even a way that a vulnerability would be exploitable in the normal course of operating nginx. These are all reasonable evaluations for the maintainers of nginx to make better versions of nginx during the image build phase.
Companies have made a considerable investment in security tooling. That tooling looks at the containers and images and tries to assess whether a vulnerability is exploitable if it’s present. It also looks at the configuration of the infrastructure and what it is adjacent to and provides as consistent and clear guidance as possible to the security operators about the risk. This cuts down on some of the noise security teams are exposed to, but it doesn’t really solve the baseline problem.
Keeping vulnerable packages around, even if the likelihood of them being exploited is incredibly low, fills the security team's views with noise. They also present opportunities for an attacker to live off the land.
There is a better approach; customers can choose to make their investments in their existing security platforms more effective and efficient by eliminating 95% of the vulnerabilities in their container platforms at the outset by using Minimus base images. The time saved from chasing vulnerabilities that don’t impact the application allows security operators to focus on the vulnerabilities, configurations, and events that matter. Reduced vulnerability surface area makes the other investments customers make in securing their infrastructure much more effective. It dramatically reduces the noise problem that plagues most security programs.
The Minimus container image includes only the minimal components required to run. It’s built daily, or more frequently as needed, and has a dramatically reduced vulnerability surface. However, it is still a drop-in replacement for the standard nginx deployment that customers can build their image on top of.
In many ways, it’s easier to talk about what the Minimus nginx container image doesn’t contain than what it does, and why. Minimus images are hardened, but still include everything you need.
When you deploy containers built on a Minimus image, they do not contain a package manager or a shell. By removing the unnecessary components to run nginx, an attacker has a dramatically reduced ability to live off the land across the infrastructure components.
Minimus Images are still built directly from the source and use the standard file structure, but they leave out the components that aren’t required to run nginx. The Minimus nginx image is 20MB vs. 200MB for the upstream image.
Minimus images are signed and include an SBOM. Versions suitable for development can easily be replaced by the hardened production image.
The impact of this reduced attack surface is not only security for the instantiated environment but also savings in security operator and developer time. Minimus images allow developers to focus on delivering new products to the business instead of chasing patches. Security teams can avoid the noise of vulnerabilities and focus on addressing the actual configurations and threats in the environment.
If you want to understand how a drop-in replacement for your current container images can help you or your organization, try using Minimus as a one-line change in your nginx image builds. Minimus makes the latest image available to individuals and organizations, and subscribers to Minimus can access the historical images in the Minimus gallery. Try it today.
