Container security conversations tend to focus on what you add: scanning tools, admission controllers, runtime security agents, network policies. Minimus focuses on what you remove.
Most container images are larger than they need to be. You start from a base image, add your application, add its dependencies, and end up with a container that includes hundreds of system packages, libraries, and binaries that your application never touches. Each of those packages is potential attack surface. If a vulnerability is discovered in a package your container ships but never uses, you still get the CVE, you still get the scanner alert, and you still need to rebuild and redeploy.
The fix is minimization: removing everything from the container that your application does not actually need at runtime.
What Minimus Does
Minimus analyzes your container image and identifies which files, libraries, and binaries are actually accessed when your application runs. It does this by running the container in an instrumented environment and tracing filesystem access patterns during a representative workload.
Based on the access trace, it generates a minimal image that contains only the files your application actually used. Everything else is removed.
The reduction in package count is dramatic for typical application containers. A Go binary that compiles to a self-contained executable and runs in an Alpine container might only need a handful of system files. A Python application has more legitimate dependencies, but a traced Minimus image still typically removes 60-70% of the packages in a standard Python slim base image.
Fewer packages means fewer CVEs. Not because the packages you removed were vulnerable, but because they are no longer in scope for vulnerability scanning. The scanner cannot report a CVE for a package that does not exist in the image.
The Trade-offs
Runtime tracing captures filesystem access during the trace period. If your application has code paths that are not exercised during tracing, the files those paths depend on will not be in the minimal image. Running that code path in production will fail.
This makes test coverage during the Minimus trace phase critical. If your tracing run does not exercise all significant code paths, including error handlers, maintenance endpoints, and infrequently used features, you may ship a container that works in most scenarios and fails in others.
The mitigation is running the trace against a comprehensive test suite and staging environment, not just a quick startup check.
Integrating into a CI/CD Pipeline
Minimus works best as a final build step. Build your container normally, push it to a staging registry, run the Minimus trace against a test environment, produce the minimized image, and push that to production.
This pattern keeps your build process standard while adding minimization as a post-processing step. The minimized image is what gets deployed. The full image lives in the staging registry and is used for future trace runs when you rebuild.
For teams where CVE fatigue is real, where every scanner run produces dozens of alerts for packages that are never actually called, Minimus is a practical reduction in noise. Fewer packages in the image means fewer alerts, and the alerts that remain are for things your application actually uses.