Today, Slim.AI is making available on GitHub its Community Images Repository that demonstrates what the Slim.AI Automated Container Hardening process looks like when performed on common tech stacks that most developers know and understand.
This repository of more than 40 hardened images is “the proof in the pudding” for our latest set of features targeted at supply chain risk mitigation. It demonstrates the value of container optimization done the Slim.AI way.
It might as well be a scientific fact: there is a tradeoff between developer productivity and security. Most of us can easily see how adding more robust security measures could slow down the development cycle; but the converse is also true: some of the tools and techniques developers use to increase productivity also introduce security problems.
Take containers, for example. In the container era, developers gain speed and consistency by using commonly available public images – whether as base images for their own applications or fully functional applications to run alongside their apps.
While fully instrumented containers (think: node:latest) have the tools, libraries, and packages developers need to craft their applications, those same DevX conveniences equate to attack surface when shipped to production. On average, `:latest` images tend to be larger (1 GB+) and have more vulnerabilities (287 on average, according to our 2022 container report).
DevOps experts know not to ship `:latest` images to production, but the process for doing so can be complex and manual for application developers. It may involve changing operating systems (i.e., using Alpine base images), adopting “pre-hardened” images that are more difficult to use, or combining tactics in complicated multi-stage builds (the famed “hand-crafted, artisanal Dockerfile”).
This is something a lot of developers struggle with and for good reason — it’s currently a manual process, and it’s not easy! Therefore, in most organizations, container hardening is either performed sparingly or not at all, and almost always begrudgingly!
What we’ve been about at Slim.AI since Day One is creating an automated process to go from the development image that enhances developer productivity to the hardened production image that is secure and performant.
Slim.AI’s approach is to add a layer of sensors to the container — we call that instrumenting the container — then performing observations on that container while it's running through a test suite or in production. Based on these observations of what the container needs to run, the Slim platform rebuilds the container to be functionally equivalent, discarding anything that is not needed (for example, package managers, shells, or unused libraries).
Slim.AI’s Community Images Repository provides a “Before-and-After” comparison of Slim’s automated container hardening process across a variety of commonly used images.
Take Redis, for example, the mega-popular key-value store that can be found in most cloud-native applications. We instrument the “redis:latest” image from Docker Hub and then, using the Redis community’s own end-to-end testing suite, we “exercise” the running container, observing what’s necessary to run in production and what isn’t.
The result? We reduce the overall vulnerability count by 68%, remove almost four-thousand files from the container, and reduce the size to just 36 MB.
We’ve removed some of the most severe vulnerabilities in the container, allowing security teams to focus on just those vulnerable libraries and packages that are necessary for the container to run.
And best of all? We run the hardened container back through the end-to-end test suite to verify that it works as expected.
To be clear, our goal for this example library is not to be another “container store” or to replace base images for Node or Python or PHP. We offer two types of images in the repository:
While you could use Standalone Application images (like Redis, Grafana, or Drupal) as is, we don’t warrant or provide SLAs for these containers. They are “Use at your own risk”. Most containers require individual configurations unique to your use case, and we offer these containers as an example of how you can leverage Slim to take the busy work out hardening your containers for production. Hello World examples can serve as a way to replace our “Hello World” app code with your own and have an easy template for creating hardened images.
We’ve done this for every programming language and every kind of common container that people will encounter in a cloud-native development stack, and will be adding more images regularly in the future. PRs Welcome!
If you’re interested in what container hardening is all about, the Slim.AI Community Images Repository is like a picture book of proof. You can see evidence of how much bloat and security risk is in the most commonly used base images today, and you can see how Slim.AI’s automated container hardening process slims those images into more secure, better performing, production-ready containers. This might be the evidence you need to convince you to embrace container hardening in your development process.
And the big takeaway is, you don’t have to do this manually any more! Automated container hardening is available for any image. Results like those you see in Slim.AI’s Community Images Repository can be achieved using any programming language, any base image, any existing container. Whatever you’re using in your development pipeline, it can all be slimmed and slimmed continuously as a part of your CI/CD process using Slim.AI’s automated container hardening platform.
It’s easy to get started: Visit our Get Started guide to create a Slim.AI account today.