You have an SBOM. Congratulations. Now tell me, with a straight face, that it lists every package your image actually contains, at the versions your build actually resolved, tied to the digest your registry actually holds. Still confident?
On June 25, Docker published a guide on generating SBOMs for container workflows. The choice it forces on your pipeline is: bake the bill of materials at build time, or scan the finished image and reconstruct it after the fact. Docker's post lands firmly on one side.
The two places an SBOM can be born
At build time. The generator runs inside the build system with access to the resolved dependency tree, the lock files, and the full build context. For containers, that means BuildKit's native attestation output: the SBOM comes out as an in-toto attestation, gets bound to the image digest, and is pushed to the registry in one operation. Every transitive dependency the build resolved is in the file because the build resolved it.
After the fact. A scanner walks the finished image, matches package-manager metadata and file signatures against a database of known patterns, and infers what is inside. It works on any OCI image, which is useful when you did not build the image yourself. It also misses statically linked binaries, vendored dependencies, and OS packages that lived in intermediate stages. Heuristics, not build graph.
