Picture this: your security team scans your production containers and the report comes back clean. Zero critical CVEs. You ship with confidence. Three weeks later, a vulnerability is disclosed in a library buried four layers deep in your Python base image, a library that was already present and unpatched when you scanned, just not yet in the CVE databases. Your image hasn't changed, but overnight, you're exposed.
Most container images start their life as an official upstream operating system distribution release. An open source project takes that release, adds their own configuration and application layer, and publishes it as their release. When a new version of the primary application ships, the image gets rebuilt with a snapshot of the components in a base distribution that may be out of date.
But in between those releases, which can be weeks or months apart, the included packages bundled inside quietly accumulate new vulnerabilities. Nobody rebuilds the image. It just sits there, version tag unchanged, growing more exposed every day.
The version tag is a big part of why this goes unnoticed. When you pull an application image from Docker Hub, that tag tells you the application version. It says nothing about when the image was last rebuilt, or how fresh the other packages bundled alongside it are. And because most images are assembled on top of other images, each with its own patch cadence, by the time an image reaches your registry, it carries the accumulated debt of every layer beneath it.
Vulnerability scanners are essential, but they can only report on vulnerabilities that have already been disclosed and indexed, and importantly are noted in the vulnerability feed from the upstream provider. An image that scans clean today isn't necessarily a clean image. That's a reason to not treat a clean scan report as the end of the conversation.
The problems described in the previous sections aren't inevitable. They're the product of specific choices made at the build level, and different choices produce measurably different outcomes. Understanding what a more security-focused build process looks like helps clarify not just what to look for in an image provider, but why the structural approach matters more than any individual feature.
The common approach when building container images is to watch upstream registries, wait for a team to publish a new version to a container registry, then build on top of it.
Many “hardened” image providers fall into a similar group of simply repackaging standard OS distros like Debian or Alpine. Because they only compile a handful of components from upstream sources and rely heavily on generalized package managers, these images inherently carry two to three times as many components, resulting in more vulnerabilities and more risk.
More importantly, this approach surrenders control of your Mean Time to Remediation (MTTR) for CVEs. If a vulnerability is patched in a component by an upstream project, but the OS distro maintainers delays backporting it to their specific package universe, your “hardened” image still remains vulnerable, regardless of what your provider’s SLA claims.
A truly security-focused approach monitors upstream open source projects directly, with build triggers strictly tied to formal releases from the package maintainers themselves.
A formal release represents the maintainers' own signal that a version is stable, reviewed, and ready. A secure pipeline strictly avoids building from intermediate commits, as doing so risks pulling in changes that are unsigned, unreviewed, or not yet considered production ready by the maintainers who wrote them.
Pulling packages from an existing registry means inheriting whatever trust assumptions and accumulated history came with it. When building from source, you can have every package and dependency, inside a controlled pipeline with strict access controls and provenance tracking. This makes it possible to say with confidence that the binary in the image actually corresponds to the source code it claims to come from. Without that, provenance is an assumption, not a guarantee.
Distroless assembly directly eliminates the “live off the land” attack surface by removing the OS package manager, shells, and standard utilities. The image then includes only the packages required to run the application, with no shell, no package manager, and no build tooling in the runtime image, meaning every package that isn't there is a package that can't be vulnerable. This isn't a new idea, but it requires building from source to do properly. If you're layering on top of an existing image, you're constrained by what that image already contains.
Some providers market their images as frictionless drop-in replacements, claiming you can secure your pipeline by ‘just changing the FROM line’. However, an image that drops into your pipeline without requiring a single configuration change, like adjusting an entrypoint to accommodate the removal of a shell dependency, is an implicit admission that the image has not actually undergone thorough hardening.
Additionally, there is a common misconception that adopting distroless images built outside of standard Debian or Alpine ecosystems creates a ‘vendor lock-in’. In reality, this argument attempts to frame a legacy weakness, like reliance on generalized, slow to update OS package managers, as a strength.
Because true distroless images are compiled directly from upstream open-source code, they are free from proprietary package formats, custom security agents, or hidden vendor telemetry. The environment running your code consists strictly of pure upstream binaries. If a team ever chooses to migrate away, they aren’t forced to untangle proprietary platform dependencies. They are simply doing the standard engineering work of updating their Dockerfiles and entrypoints to consume a new base image, a fundamental step required when adopting any provider.
Deterministic visibility into what changes from build to build is essential for low-effort container security. Engineers need to know exactly which packages evolved and which vulnerabilities were remediated without conducting menial, time consuming investigations. This level of clarity is achieved through a comprehensive changelog and digest history, but maintaining that reliable paper trail requires a structural commitment to daily rebuilds.
An image that is only rebuilt when the primary application version changes will silently accumulate vulnerabilities in its supporting packages between releases. Consider an image that has been at the same primary version for eight months. A provider that rebuilds only on a version change, published it once and hasn’t touched it since.
A build process designed around security rebuilds every actively maintained image version daily, pulling from the freshest available packages each time. The overreaching version tag stays the same, while the digest and the SBOM reflect what actually changed inside. A provider running daily rebuilds might have rebuilt it dozens of times in that same window, each time incorporating upstream package fixes, each time reducing the CVE count a scanner would find on a fresh pull. (Same version tag, fundamentally different image.) This is exactly what the Minimus console's changelog and digest history surfaces for every image version it maintains.
A build process that produces clean images but can't prove it offers limited value to a security-conscious team. True verifiability requires generating precise artifacts around the components of a completed object. Every image build should ship with a comprehensive Software Bill of Materials (SBOM) that enumerates every package inside it at the version level, and importantly, both the final image and the accompanying SBOM must carry cryptographic signatures and build attestations.
This cryptographic proof allows end users to carry the chain of provenance directly into their own infrastructure. Rather than relying on blind trust, engineering and security teams can programmatically verify these signature and SLSA L3 build attestations within their own CI/CD pipelines before deployment.
Ultimately, this shifts container security from trust to proof. The integrity of your base image is no longer a promise, it’s a cryptographically guaranteed reality your team can verify on every image pull.
The build process described in the previous section isn't abstract, it has concrete, day-to-day effects on how engineering and security teams interact with container images. Some of those effects are immediately visible the first time you pull a Minimus image. Others accumulate over time as the operational model shifts from reactive to proactive.
The most immediate thing engineers notice when adopting a secure build process is the scanner output. Because Minimus images are built from source with only the required packages and rebuilt daily against the freshest available dependencies, the CVE count on a fresh pull is dramatically lower (97% lower on average).
Consider a standard Python microservice. To serve web traffic, it strictly needs the Python interpreter, standard libraries, and essential underlying system dependencies. It does not need a package manager like apt, a shell like bash, or network utilities like curl and wget. Yet, traditional base images built on top of standard OS distributions include all of these unneeded tools by default. By explicitly excluding everything that isn’t strictly required for the application to run, the baseline attack surface shrinks.
The alerts that do appear are more likely to represent real, actionable issues rather than noise from a library that hasn't been touched since the image was first assembled months ago.
When a CVE is fixed in a Minimus image, the changelog makes it visible. Every image digest maintains a complete record of what changed in each build, which packages were updated, when the build was published, and what the vulnerability count looked like before and after.
For an engineer who needs to confirm that a specific CVE has been addressed, or a security team that needs to demonstrate to an auditor that a known issue was remediated and when, that paper trail exists without any additional instrumentation.
The SBOM that ships with every build complements this changelog by providing a precise package-level inventory to work from. Rather than forcing security tools to scrape filesystem layers and guess at installed packages, teams have a cryptographically verified record of exactly what components are inside.
Build tools, compilers, and package managers need to be present when you're assembling an application but have no legitimate role in a production container. When the same image is used for both stages, those tools get carried into production by default, quietly expanding the attack surface.
Minimus images come in paired variants: a dev image that includes the tooling needed for your CI pipeline, and a production image that contains only the runtime. The split is already made, it doesn't require discipline or Dockerfile gymnastics to maintain.
For teams operating in environments with formal software supply chain requirements, SLSA compliance, SSDF alignment, or government-adjacent security frameworks, signed build attestations address a requirement that would otherwise need to be instrumented separately.
Every Minimus image is signed, and the attestation is verifiable. The provenance chain from upstream source to published image is documented and checkable. Crucially, compliance hardening is integrated directly into the image assembly phase.
Minimus natively provides FIPS 140-3 validated cryptography utilizing NIST CMVP certified modules like OpenSSL directly in the image, along with dedicated FIPS configuration options. Furthermore, the images are built to align with CIS application hardening benchmarks and support DISA STIG compliance verification.
For organizations where that audit trail and FedRAMP alignment is a compliance requirement rather than a nice-to-have, it arrives as part of the image rather than as a separate engineering project.
The Minimus console surfaces one more thing worth mentioning here: a live comparison between the current Minimus image and its equivalent public image, showing the CVE counts and package differences side by side.
This turns the security advantage from a claim into something a team can look at directly, evaluate against their own risk tolerance, and use to make an informed decision about whether switching makes sense for their environment. The comparison updates continuously as both images evolve, so it reflects the current state of both, not a snapshot taken at a convenient moment.
Teams can move to a process where they pull fresh images with known contents, have full visibility into changes through the changelog, and feed SBOMs into scanners rather than scanning blind. These teams tend to find that the volume of security work that lands on their plate looks dramatically lower over time.
One question that comes up when teams are evaluating a switch to Minimus is whether Minimus images will break existing deployments. Minimus images are OCI compliant and designed to match the behavior of their public equivalents (same default user, same entrypoint behavior, same working directory) so Docker, Kubernetes, Helm, and existing access and permission configurations work without modification in the vast majority of cases.
Where intentional differences exist, they're documented and visible in the image specification before you pull, not discovered at runtime. The most common adjustment involves entrypoint scripts that rely on a shell, which distroless images don't include, and involves a one-time migration that the Minimus docs walk through directly.
Every image is also tested in real Kubernetes clusters across amd64 and arm64 architectures before it's published, so Helm chart deployments and multi-arch environments are validated as part of the build pipeline rather than left to the user to discover.
The most straightforward way to evaluate the difference is to pull a single Minimus image alongside the equivalent you're currently running, put both through your scanner, and compare the results. The CVE count will speak for itself, and your environment will keep running exactly as expected.
CVE count at scan time has dominated the container security conversation for long enough that it's started to feel like the only metric that matters, but it's a lagging indicator. It tells you what was known to be wrong at the moment you looked, not what will be known tomorrow.
The questions that actually predict your security posture over time are quieter and less often asked. When was this image last rebuilt, not released, rebuilt? Can you trace every package back to the source code it came from? How much of your team’s week is disappearing into triaging alerts for vulnerabilities in packages that shouldn’t even be in your production image in the first place? And for the packages you do need, how much time is wasted investigating issues that were already fixed in a newer build nobody had pulled yet?
These aren't trick questions or an unreasonably high bar. A provider that monitors upstream releases directly, builds every package from source, assembles images with only what's needed, and rebuilds daily doesn't need to answer those questions defensively. The build process answers them automatically, for every image, every day. That's what good looks like, and it's the standard Minimus holds every image in our registry to.
If you want to see the difference rather than take our word for it: pick one image from the Minimus gallery, pull it alongside the equivalent you're currently running, and put both through your scanner. Most teams find the gap meaningful within the first five minutes.
Head straight to the getting started page to begin pulling images today, or schedule a demo with our team.
.svg)
.svg)
.svg)
.svg)
