The investment in distroless and hardened container images makes sense on paper. Minimal, hardened images remove recurring operational and security work across platform teams. But not all minimal container images are built the same. In this post, we'll show how the right approach compounds value across security, engineering, and operations teams of any scale.
A Minimus image begins with a developer creating a recipe for building the packages that make up the image. That developer analyzes each component of the package or library, focusing on identifying the canonical source, its dependencies, where those components are sourced, how the upstream maintainer releases new versions, and other key factors.
This analysis allows Minimus to build directly from the upstream source, meaning we don't rely on a third party to create packages or release new versions outside of the package maintainer's own release cadence. By controlling the entire release process from the upstream source, Minimus is able to ship images at a pace that allows organizations as much time as possible to meet their SLAs.
Starting from an initial recipe results in far fewer packages. Fewer packages means fewer vulnerabilities out of the gate, and it also reduces the rate at which new vulnerabilities appear in each image over time.
Beyond continuously patching a reduced package footprint, Minimus offers the option to maintain custom images on a customer's behalf. Any additional packages that are traditionally added via package manager within a Dockerfile build can instead be moved into a Minimus custom image using Minimus Image Creator.
By doing so, maintenance of not only the base image, but any additional package, whether feature or vulnerability related, is handled by Minimus as part of the pipeline build process. Engineering teams no longer need to go back and update their Dockerfiles with new package versions every time a patch is needed.
Every Minimus image ships compliant by default, with alignment to the CIS for Docker Build Checks. Minimus engineers go through the painstaking process of ensuring these settings are compatible with every image build as part of the recipe process, then set a baseline after initial creation to ensure every subsequent build follows the same standard.
Minimus also ships application-hardened images. In addition to CIS for Docker compliance baked into the build process, application-hardened images offer an additional level of CIS hardening at the application level. Images for applications like PostgreSQL and NGINX, for example, are ready for immediate use by organizations that already align to such practices, or for those looking for an easier way to manage that alignment.
Given that the vast majority of open source software projects do not ship images in this capacity by default, this is a massive time saver for any engineering team that would otherwise need to go back and make changes when security or controls teams request further hardening to meet required organizational controls.
In addition to performing the actual hardening, Minimus provides out-of-the-box attestation evidence of every change that was made, exactly the kind of documentation that internal and external audit teams regularly require as proof. Capturing and gathering that proof is yet another layer of cumbersome work, and Minimus eliminates it entirely.
Attestation for alignment with CIS and NIST 800-190 is available for every image in the product. For applicable FIPS images, related FIPS certifications and DISA STIG documentation are also ready for consumption and distribution.
Minimus provides mechanisms to automatically sync your desired images into your existing registries. There's no need to configure pull-through cache settings or manually pull new images every time an update is required. Whenever a new version of an image is built, daily syncs ensure it's always available in your existing tooling and infrastructure, further reducing the operational burden on engineering and ops teams.
Minimus Actions let you automatically notify or trigger internal workflows whenever new images are created, with no additional SOAR integration or custom code setup required.
Minimus tells you when projects and versions are either End-of-Life (EOL) or nearing EOL. Staying aware of the current state and release cycles of every open source software project is a burdensome and largely unmaintainable effort for most organizations. Minimus empowers teams to receive this information in a timely fashion so they can begin preparing and migrating to new releases long before upstream software becomes archived or unmaintained.
All of the above work gets done in some capacity at every organization, regardless of size, because it has to - for security, compliance, and operational reasons. But it comes at great cost: employee time, friction between teams over priorities and risk classification, and the lost time that follows.
Minimus removes that pain immediately. By adopting Minimus images, organizations can eliminate the manual overhead, reduce cross-team friction, and reclaim the time and resources these processes have always quietly consumed. Get a demo to get started with Minimus.
.svg)
.svg)
.svg)
.svg)
