Asking the very obvious question (as it's not apparent from the website): Why would I use this over DHI (Docker Hardened Images) or Chainguard Images, both of which also have a set of free hardened images?

▲

morellonet 7 hours ago | parent | next [-]

1. These are all >1200 of our images, including FIPS, and all versions… others gate many of their images

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

▲

pixl97 6 hours ago | parent | next [-]

>are all built continuously from upstream source

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.

▲

hobofan 4 hours ago | parent | next [-]

> 2. Isn't there a slight risk of upstream attacks being amplified by this?

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.

	▲	morellonet 4 hours ago \| parent [-]
		Also note that one of the features of Enterprise Edition is our integrations with Slack, email, GitHub, webhooks, etc. This enables really simple but powerful notification and automation scenarios based on image fixes (amongst other triggers like a version you're using going EOL). 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.

▲

s_ting765 5 hours ago | parent | prev [-]

Pausing software updates by X days old is a hack at best for specific distribution platforms (npm), not a general security recommendation.

▲

AmazingTurtle 5 hours ago | parent | prev | next [-]

how can one be sure you don't do rugpull in the future?

▲

itintheory 2 hours ago | parent [-]

Pull-through cache the images. Sure, they could decide you can't pull anymore, or impose problematic rate limits, but you shouldn't add a runtime dependency on their registry in any case.

	▲	morellonet an hour ago \| parent [-]
		Yep, these are just normal OCI compliant images served from a normal OCI compliant registry. You can cache them however you'd like.

▲

ramon156 6 hours ago | parent | prev [-]

The question was "why over DHI?"

1 and 2 are not a reason

3. no X, no Y, also not a reason

4. `rg agents`. Right

▲

morellonet 6 hours ago | parent | next [-]

Not sure what you mean… we have more images than DHI, we have FIPS images available freely, and all our images are built from source on a distroless base. These are just objective facts.

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.

▲

yjftsjthsd-h 5 hours ago | parent | prev [-]

3 is exactly the reason I've never bothered to try docker's offering; that definitely is a reason

	▲	morellonet 5 hours ago \| parent [-]
		Re 3, one of the features in Enterprise Edition is integrations with Slack, GitHub, webhooks, etc. a key use case is getting a push notification (or even triggering automation) when an image you’re using gets an update. 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

▲

phishin 7 hours ago | parent | prev [-]

Agreed. Also on front page the nginx container is 6 days old, so no daily builds

	▲	morellonet 7 hours ago \| parent [-]
		We build anytime any component within an image has a new upstream version. If there’s no new upstream versions, no reason to build. Check out the changelog tab in each image listing and you can see exactly when and why we build each time