Software Bill of materials for docker image

I've personally not been tasked with something like this before, but I'd take a guess that looking at the history might be a good start:

# You may need to first run "docker pull node:12.14"
docker history --format '{{.CreatedBy}}' --no-trunc --human node:12.14

This will output the list of commands used to build the image and you'll have to decide what's appropriate for the team requesting the bill of materials from you.

Otherwise, you can look at the source for the Dockerfile directly at GitHub. This point in the history appears to be the latest commit that builds the 12.14 release (I could be wrong so please feel free to dig around that repository and its history yourself as well).

Docker just announced (Apr. 7th, 2022)

Introducing 'docker sbom' — the CLI command developed alongside @anchore (using their Syft project) that displays the SBOM of any Docker image.

CTO @justincormack explains how this functionality will help improve trust in the software supply chain by providing more visibility:

Announcing Docker SBOM: A step towards more visibility into Docker images

This command is just a first step that Docker is taking to make container images more self descriptive. We believe that the best time to determine and record what is in a container image is when you are putting the image together with docker build. To enable this, we are working on making it easy for partners and the community to add SBOM functionality to docker build using BuildKit’s extensibility.

As this information is generated at build time, we believe that it should be included as part of the image artifact. This means that if you move images between registries (or even into air gapped environments), you should still be able to read the SBOM and other image build metadata off of the image.

Example:

docker sbom neo4j:4.4.5

Result:

Syft v0.42.2
 ✔ Loaded image            
 ✔ Parsed image            
 ✔ Cataloged packages      [385 packages]

NAME                      VERSION                        TYPE
... 
bsdutils                  1:2.36.1-8+deb11u1             deb
ca-certificates           20210119                       deb
...
log4j-api                 2.17.1                         java-archive  
log4j-core                2.17.1                         java-archive  
...

Note that the output includes not only the Debian packages that have been installed inside the image but also the Java libraries used by the application.
Getting this information reliably and with minimal effort allows you to promptly respond and reduce the chance that you will be breached.

In the above example, we can see that Neo4j uses version 2.17.1 of the log4j-core library which means that it is not affected by log4shell.

Engin Diri adds (tweet)

The new @Docker sbom command is great in terms of UX.
Plenty of choices for the output format (@CycloneDX_Spec, @SyftProject, SPDX or even @github JSON!) Great collab with @anchore.

BTW: You can pipe docker sbom output via "--format syft-json | grype" into @GrypeProject to get the vulnerabilities displayed!