kubernetes-sigs/bom: an SPDX SBOM multitool for images, directories and files

What bom actually produces, and why the source type matters

Most SBOM tools pick one input and do it well. bom takes the opposite position: the same binary should describe a directory, a container image, a tarball, a single file, or a combination of those in one document. The README frames it as a general-purpose tool that can generate SPDX packages from directories, container images, single files, and other sources, and the usage text confirms that multiple sources can be combined into one manifest.

That matters because the hard part of an SBOM is usually not the format, it is the boundary. A Go service has vendored modules, a base image has operating system packages, and a release tarball has neither of those things but does have file hashes. bom lets you express all three in one SPDX document rather than stitching three outputs together afterwards.

The audience is therefore fairly specific: release engineers and platform teams who already have an SPDX consumer downstream, and who need the generator to accept whatever artifact they happen to be shipping that week. The project grew out of the effort to produce an SBOM for Kubernetes itself, which explains the container-heavy examples and the Go dependency analysis.

The generate pipeline and the analyzers behind it

bom generate is the entry point. According to the README, it currently supports creating an SBOM from files, images, and docker archives, and it can pull images from remote registries for analysis. When you point it at an image, the layers are expressed as subpackages in the resulting document. That is the data flow: the image is pulled or read from a tarball, each layer becomes a package, and relationships connect the top-level image to what it contains.

The analyzers are the second half. The README describes a growing number of analyzers designed to add more sense to common base images, and the dependency list names the ecosystems involved: go-rpmdb for RPM databases, the Alpine Go bindings, and a SQLite driver, which together suggest that package databases inside image layers are read directly rather than inferred from filenames. The Go dependency analysis comes from the module graph, and .gitignore is honored when scanning git repositories, so build output does not silently become part of the manifest.

License detection is not a separate pass. The project ships a built-in license classifier that recognizes the 400+ licenses in the SPDX catalog, so file-level license identification happens during generation. The output format is controlled by --format, which supports json and tag-value and defaults to json.

Installing bom and generating your first manifest

There is no package manager step documented. The README gives a single Go install command, which places the binary in your Go bin directory:

go install sigs.k8s.io/bom/cmd/bom@latest

After that, bom generate with no arguments beyond a path produces an SPDX document for the current directory. The README's first example is exactly this:

bom generate .

The default output is JSON. If you want the tag-value rendering instead, pass the format flag:

bom generate --format tag-value .

The more interesting first run is against a container image, because that is where the analyzers do visible work. The README's example pulls an image and writes the result to a file:

bom generate --output=debian.spdx --image \
  debian@sha256:0aac521df91463e54189d82fe820b6d36b4a0992751c8339fbdd42e2bc1aa491

To check what you got, use the document subcommand, which the README describes as drawing the structure of an SPDX document:

bom document outline debian.spdx

You should see a tree: the document, the packages it describes, and the relationships between them. For a Debian-based image the README's sample output shows one package described and a CONTAINS relationship into a layer package with dozens of further relationships beneath it. If your output is a flat list with no relationships, the analyzers did not recognize the image's package database and you are looking at file-level data only.

Where bom is the wrong tool

The format support is the first constraint. The README lists json and tag-value for --format, both of which are SPDX renderings. CycloneDX appears in go.mod only as an indirect dependency, pulled in through protobom and the SPDX v3 packages, not as a documented output option in the README. If your downstream consumer requires CycloneDX, bom is not the generator to reach for.

Language coverage is the second. Go dependency analysis is called out explicitly in the README. There is no equivalent claim for npm, Python, Maven or Cargo manifests. A Node or Python service scanned with bom will get file hashes and license classification, but not a resolved dependency graph, and a reader expecting transitive packages will be disappointed.

Cadence is the third, and it is the one worth stating plainly. The last push to the repository was on 2025-09-26. The release history shows v0.6.0 in January 2024, then v0.7.0 and v0.7.1 within a day of each other in September 2025. That is a long quiet stretch followed by a burst, which is normal for a project that tracks upstream format work but is not what you want if you need a tool that absorbs new package ecosystems quickly. The repository is not archived, but the gap between v0.6.0 and v0.7.0 is the honest signal here, not the version number.

bom against syft, and what the difference means in practice

The obvious comparison is Anchore's syft, which is the other widely used generator in this space. The difference is not quality, it is where each tool puts its effort.

syft is built around a cataloger model: a large set of ecosystem-specific catalogers feed a normalized internal model, and output formats (SPDX, CycloneDX, and others) are pluggable writers on top. That design optimizes for breadth of ecosystems and for switching formats without changing tools.

bom is narrower and more SPDX-shaped. Its internal representation is protobom, which is SPDX-oriented, and its document subcommand is built around inspecting SPDX structure rather than converting between standards. The in-toto provenance export, enabled through the --provenance flag, is another SPDX-first feature: the README says the output lists all SPDX data as in-toto subjects, ready to be completed by a later CI/CD stage. That is a supply-chain attestation workflow, not a format-conversion workflow.

So the choice is roughly this. If you need one tool that speaks every ecosystem and every output format, syft covers more ground. If your pipeline is SPDX end to end, if your artifacts are container images and Go binaries, and if you want to inspect the resulting document graph from the same binary, bom's narrower focus is an advantage rather than a limitation.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2025-09-26. Upgrades arrive as tagged releases rather than a rolling main branch, which is the sensible model for a tool whose output feeds compliance records: you want the generator version pinned alongside the artifact it described. The release history shows a single patch release, v0.7.1, immediately after v0.7.0, which suggests the maintainers do respond to regressions in a fresh release.

The practical upgrade cost is low for the binary itself, since go install pins whatever version you name, but higher for the output. Changing generator versions can change package graphs and license classifications, and any downstream consumer that diffs SBOMs between builds will see that churn. Pin the version explicitly rather than tracking @latest in CI.

The licence is Apache-2.0, which is permissive and includes an explicit patent grant. That is the standard choice for Kubernetes SIG projects and is compatible with commercial redistribution. This is a description of the licence identifier, not legal advice; if you are embedding bom in a product, review the LICENSE file and your own obligations with counsel.

Editorial conclusion

bom fits teams that already produce SPDX and want one binary that can describe a directory, a remote image and a tarball without a plugin ecosystem. It is a poor fit if you need CycloneDX as the primary output, if your stack is not Go-centric, or if you need a tool with a fast release cadence: the last push was on 2025-09-26. Before adopting it, generate an SBOM for one of your own images and run bom document outline on the result to see whether the package graph is detailed enough for your consumer.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes