2. These are all built continuously from upstream source on a distroless base… this makes a significant difference in attack surface and CVE count re DHI images and you can easily check our word with a few scans
3. These are truly free… no auth wall, no signup, no trial, no limit on numbers of images or pulls or anything like that
4. We have really invested in making these agent ready… we have a CLI (minicli) designed for both humans and agents to easily discover, understand, migrate to, and build on them… for example, check out the AI migration prompts we provide for each image, we’ve refined these across many customer deployments such that you can copy paste into your agent of choice, point it at a Dockerfile and have it do all / nearly all the work to move to these images
2. Isn't there a slight risk of upstream attacks being amplified by this? With the recent number of software compromises providing a way for people to use images X days old may be useful.
3. This ties into 2, if someone downloads and uses an image that is later found to be compromised they mostly have no way of being notified that happened. Not a huge issue, but is something that should be risk assessed.
I think the argument would be that consuming Minimus' containers would have a less severe amplification (or even reduction), as all upstream attacks that rely on a combination of third-party vulnerabilities would be rendered infeasible (since they reduce the amount of third-party dependencies in an image).
> 3. This ties into 2, if someone downloads and uses an image that is later found to be compromised they mostly have no way of being notified that happened.
For this you need a consumption-aware scanner anyways (e.g. that lists images running in your Kubernetes). Anything else will be too spammy, as you can't notify for everything for you have at some point in time have used as a base image.
For example, with EE, you can create an action to automatically trigger a webhook or send a Slack message when an image you're using has a critical CVE that's likely to be exploited (we also integrate threat intel from EPSS, KEV, etc).
Definitely still value in having runtime scanning / visibility too, but EE makes it easy to do purely on the 'left' side of things too.
1 and 2 are not a reason
3. no X, no Y, also not a reason
4. `rg agents`. Right
The build from source on distroless approach provides a meaningful advantage re attack surface and CVEs versus DHI images. You don’t have to take our word for it, just pull some images and scan with Trivy or Grype or whatever you prefer.
It’s simple but pretty granular too… ‘if this python image gets a fix for a critical CVE that’s actively exploited, trigger a GitHub action to rebuild the app with the updated image
Check out the changelog tab in each image listing and you can see exactly when and why we build each time