DHI Build now available!

[cdupuis]

We just made the DHI build images available at https://dhi.io/catalog/build/guides; we'll making the source available soon too,

You can use those to build DHIs from the https://github.com/docker-hardened-images/catalog repository:

$ docker buildx build https://raw.githubusercontent.com/docker-hardened-images/catalog/refs/heads/main/image/alpine-base/alpine-3.23/3.23.yaml \
  --sbom =generator=dhi.io/scout-sbom-indexer:1 \
  --provenance=1 \
  --tag my-alpine-base:3.23 
  --load

After running this command, you'll have a freshly build version of the dhi.io/alpine-base in your Docker engine image store:

$ docker images my-alpine-base
                                                                                                                                                                                                               i Info →   U  In Use
IMAGE                 ID             DISK USAGE   CONTENT SIZE   EXTRA
my-alpine-base:3.22   c8725cd56d68       3.48MB          1.2MB

Next step would be to clone the ttps://github.com/docker-hardened-images/catalog repository and potentially make changes - such as adding packages.

Looking forward to hearing your feedback.

cd

[pombredanne]

Thanks. It looks like these are not freely downloadable?

[pombredanne]

Note that dhi.io is linked also as the sources for licensing details, so it must be an oversight that it is password protected?

See https://github.com/docker-hardened-images/catalog/blob/9794c43897d69c4e71d4f28efa8c51b63fa142f5/LICENSE.txt#L11C1-L15C48

By using these images, you agree to the combined license terms of the included
software. The list of licenses is available in the Software Bill of Materials
(SBOM) at:

                             https://dhi.io

[pombredanne]

Even if I were to signup on https://dhi.io , nothing seems to be available either there. (Not that I want nor should have to sign up to access open source images, but I tried too).

[cdupuis]

@pombredanne, appreciate your feedback.

dhi.io uses Docker Hub authentication. You can create a free account at https://app.docker.com/signup. Once you ran docker login dhi.io you can freely pull images; after login at https://dhi.io with your Docker Hub user, can you browser the DHI catalog including all SBOM content, guides, etc.

cd

[pombredanne]

@cdupuis Thanks, but signing up means agreeing to a commercial contract at https://www.docker.com/legal/docker-subscription-service-agreement/ which makes the Apache license moot. And in all cases, even then it does not work.

[cdupuis]

And in all cases, even then it does not work.

Sorry, you lost me now: what does not work after signing up and logging in?

[mathiasror]

I could not get this to work with the commands listed. I am using Rancher Desktop on macOS, as I cannot use Docker Desktop at work due to licensing.

 $ docker buildx build . -f image/alpine-base/alpine-3.23/3.23.yaml \
                                             --sbom=generator=dhi.io/scout-sbom-generator:1 --provenance=0 \
                                             --tag my-alpine-base:3.22 --load
[+] Building 0.0s (0/0)                                                     docker:rancher-desktop
ERROR: failed to build: Attestation is not supported for the docker driver.
Switch to a different driver, or turn on the containerd image store, and try again.
Learn more at https://docs.docker.com/go/attestations/

I was able to build successfully when I omitted the --sbom= and --provenance= parameters. However, if we were to migrate to these images, an SBOM would be a hard requirement. It is possible that this would work when building in a CI/CD environment, but I have not yet tested that.

That said, maintaining our own base image builds is far from ideal and would introduce additional complexity.

It is also unclear why these images cannot simply be pulled like other open-source Docker images. Especially given the claims made in the announcement, such as:

DHI now gives the world a secure, minimal, production-ready foundation from the very first pull.

If it sounds too good to be true, here’s the bottom line up front: every developer and every application can (and should!) use DHI without restrictions.

Total transparency in every part of our minimal, opinionated, secure images.

• At present, DHI does not appear to be production-ready for non-paying users.
• There are restrictions in place that contradict the expectations set by the announcement.
• The explanation provided regarding these restrictions is vague and leaves several open questions.

[cdupuis]

@cyanboy, thanks for your feedback.

I was able to build successfully when I omitted the --sbom= and --provenance= parameters. However, if we were to migrate to these images, an SBOM would be a hard requirement. It is possible that this would work when building in a CI/CD environment, but I have not yet tested that.

To be able to build and store attestations in your Docker engine it needs to be set up in the correct way. To do this, follow the steps provided in the linked documentation from the error message: https://docs.docker.com/build/metadata/attestations/.

If Rancher doesn't support attestations it is a problem that you should raise with Suse. There is an open issue from 2023 at rancher-sandbox/rancher-desktop#6029.

That said, maintaining our own base image builds is far from ideal and would introduce additional complexity.

Understood, which is why you can pull these images freely after authentication.

cd

[glauberferreiranees]

@cdupuis I have tried to build the catalog/image/docker/debian-13/29-dev.yaml, but it uses scout, whose repository is private: https://github.com/docker/scout-cli-plugin.git. Is it possible to disable some part of YAML, by configuration, in order to build the image successfully?

[alkersan]

we'll making the source available soon too

Hi @cdupuis , is there a reference spec of the dhi build syntax? I was reading through various catalog image source, and found one pipeline type, that seems undocumented. For example, in the keycloak image:

pipeline:
  - name: patch
    uses: mvn/patch@v1
    with:
      dependencies: /src/patch/mvn-deps.json
      dependencies-key: dependencyManagement.dependencies
      mvn-root: ${source.dir}/keycloak
      properties: /src/patch/mvn-properties.json

What exactly is this uses: mvn/patch? Current DHI docs only mention that pipeline stages are shell scripts, but here it looks like a github action invocation (but apparently it is not)