On Thu, 2025-12-11 at 19:03 +0100, Simon Josefsson wrote: > Felix Moessbauer <[email protected]> writes: > > > * Package name : debsbom > > Version : 0.5.1 > > Upstream Contact: Felix Moessbauer <[email protected]> > > * URL : https://github.com/siemens/debsbom > > * License : MIT > > Programming Lang: Python > > Description : Software Bill of Materials generator for distributions > > based on Debian > > > > debsbom generates SBOMs (Software Bill of Materials) for distributions > > based on Debian in the two standard formats SPDX and CycloneDX. > > The generated SBOM includes all installed binary packages and also > > contains Debian Source packages. > > This seems great! > > Do you have an example file for how these SBOMs will look like for some > Debian package?
Just to avoid misunderstanding here: The debsbom tool does not generate an SBOM for a single package (you could do, but that's not the main scope). Instead, it scans a rootfs and lists all installed packages along with their runtime, binary -> source and built-using dependencies. IOW: The SBOM contains a flat list of packages and a dependency graph pointing into this flat list. Please have a look at our list of examples [1]. There, we also have a trivial one showing how to scan a debian container image: CRT=$(podman create debian:bookworm) CHROOT=$(podman unshare podman mount $CRT) podman unshare debsbom generate -t spdx --root $CHROOT [1]https://siemens.github.io/debsbom/examples.html > How stable is the file format specification? Both CycloneDX and SPDX are well defined. However, how to fill in the fields of these specifications varies across tools. That's why we explicitly document in our design decisions how we map things [2]. [2] https://siemens.github.io/debsbom/design-decisions.html > > How is the plan to distribute and consume these SBOMs? I suppose they > can't be included in the package itself, if they contain hash checksums > of *.deb's etc. If they don't contain hash checksums, how do you deal > with multiple variants of a package with identical name and version? > There are known examples of this in the archive. These SBOMs can be distributed along with a rootfs, e.g. a container image or a bootable image as we generate with ISAR (that's what we developed the tool for). [3] https://github.com/ilbers/isar > > > The generated SBOM includes all installed binary packages and also > > contains Debian Source packages. > > That's not necessarily the entire story of what went into building a > particular package. Information about the running kernel and the > presence and version of any non-free firmware microcode is essential. > Not everything about the build environment is captured by the list of > installed packages. True. As stated above, we describe things as dpkg or apt sees it (which is the package metadata, along with checksums). We don't capture a build environment. Of course, the build tooling could also generate this data in SBOM format (e.g. similar to the .buildinfo files), but this is currently out of scope. One thing worth mentioning is how we identify packages, which is currently by PURL (Package URL) and boils down to the triplet <name> <version> <arch>. We further harden this by checksums. However this is not always precise enough, as discussed with the snapshot.d.o people in [4]. [4] https://lists.debian.org/debian-snapshot/2025/10/msg00000.html > > If there is a specification around this, commenting on that will be > simpler. Of course the formats themselves are documented, as well as we document how we map the debian data onto the fields in the documentation. Please have a look at our design decisions in [2]. Cheers, Felix > > /Simon -- Siemens AG Linux Expert Center Friedrich-Ludwig-Bauer-Str. 3 85748 Garching, Germany
