bom: A Practical Look at the Kubernetes SBOM Generator

What bom Solves and Who It Serves

bom addresses a specific gap: producing SPDX-compliant Software Bills of Materials without requiring authors to hand-craft SPDX documents. The README states it was created as part of the project to create an SBOM for the Kubernetes project, so its origins are tied to a real, large-scale need. The tool targets software authors who want to generate an SBOM for their projects in a simple way, but it also serves anyone who needs to inspect or transform existing SPDX data. The documentation frames it as a general-purpose utility, but the focus on SPDX is explicit. If you work outside the SPDX ecosystem, this tool may not fit. The audience is primarily Go developers and Kubernetes contributors, given the installation method and the project's home under kubernetes-sigs.

How bom Generates an SBOM: Sources and Mechanisms

The generate subcommand is the core. It accepts directories, container images, docker archives (tarballs), and individual files as sources. The README shows that you can pass a directory as the first argument, use the -d flag for multiple directories, -f for files, and --image for images. For images, bom pulls from remote registries and analyzes the layers, expressing each layer as a subpackage in the resulting document. The tool also has a built-in license classifier that recognizes over 400 licenses from the SPDX catalog. That classifier is a meaningful feature because it automates a task that is often manual. The generate command supports output in JSON or tag-value formats, with JSON as the default. The data flow is straightforward: you specify sources, bom builds an SPDX package hierarchy, and writes the document to a file or stdout. The --provenance flag exports the SBOM data into an in-toto provenance attestation, listing all SPDX data as subjects, ready for later CI/CD stages. That mechanism is useful for supply chain security pipelines, but the README does not detail how to complete the attestation, so expect to consult external in-toto documentation.

The document Subcommand: Visualizing and Querying SBOMs

Beyond generation, bom includes a document subcommand with two operations: outline and query. The outline command renders the structure of an SPDX document as a tree. The README gives an example using a debian:bookworm-slim image, showing the ASCII art output with package relationships and counts. That visualization is helpful for understanding what an SBOM contains, especially when dealing with images that have many layers. The query command searches for information in an SBOM, though the README does not specify the query syntax or what fields are searchable. That lack of detail is a gap. If you need to extract specific package versions or licenses, you may need to experiment with the command or read the source code. The outline output includes emoji in the rendered tree, which is a cosmetic detail but indicates the tool prioritizes human readability over strict terminal compatibility. The document subcommand is a differentiator, as many SBOM tools only generate and do not provide built-in inspection.

Getting Started: Installation and Basic Commands

Installation is a single Go command: go install sigs.k8s.io/bom/cmd/bom@latest. That assumes you have Go installed and your GOPATH is set up. The README lists completion for shells as a subcommand, which is a convenience for interactive use. To generate an SBOM from the current directory, run bom generate . with no flags. For a container image, the example is bom generate -n http://example.com/ --image registry.k8s.io/kube-apiserver:v1.21.0. The -n flag sets a namespace or document name, though the README does not explain its exact meaning. For files, use -f flags as shown: bom generate -n http://example.com/ -f Makefile -f file1.exe. The generate command also supports a --config flag for a YAML SBOM configuration file, but the README does not show the config schema. That omission is notable. If you plan to use configuration files, you will need to inspect the source or examples in the repository, as the README alone is insufficient.

Limitations and Cases Where bom Is the Wrong Tool

bom has several limitations visible from the README. First, it is SPDX-only. The README mentions no support for CycloneDX or other SBOM formats, so if your compliance pipeline requires a different standard, bom will not work without conversion. Second, the analyzer support for images is described as 'a growing number of analyzers,' which implies it is incomplete. For base images with uncommon package managers, bom may not detect all components. Third, the --provenance flag produces an attestation that is 'otherwise ready to be completed by a later stage,' meaning it is not a finished artifact. That adds work to your pipeline. Fourth, the README does not document the YAML config file structure, so advanced users face a learning curve. Finally, the project's recent release cadence (v0.6.0 in January 2024, then v0.7.0 and v0.7.1 in September 2025) suggests the API may still be shifting. If you need a stable, long-term tool with a frozen interface, this may not be it.

Alternatives and How They Differ

A direct alternative is syft from Anchore, which generates SBOMs from container images and directories. The key difference is that syft supports multiple output formats including SPDX and CycloneDX, and it has a plugin ecosystem. bom is narrower, focusing on SPDX and integrating with Kubernetes-specific workflows. Another alternative is SPDX tools, the reference implementation from the SPDX project, which is a Java-based suite for validating and converting SPDX documents. That tool does not generate SBOMs from sources; it processes existing documents. In contrast, bom generates from sources and provides querying. If you need a source-to-SBOM generator with format flexibility, syft is more flexible. If you need to validate SPDX correctness, SPDX tools is the standard. bom sits between them, offering generation and inspection but only for SPDX.

Maintenance, License, and Upgrade Considerations

The project is licensed under Apache-2.0, which permits commercial use, modification, and redistribution with conditions. The repository is not archived, and the last push was September 2025, so it is actively maintained. The release history shows a gap of about 20 months between v0.6.0 and v0.7.0, followed by two releases on consecutive days. That pattern suggests maintenance is sporadic but bursty. The README mentions the project is incubating in the Linux Foundation's Automating Compliance Tooling TAC, which indicates governance but also that it is not a fully mature project. For upgrades, the go install command fetches the latest version, so updating is trivial. However, the lack of a detailed changelog in the README means you may need to review GitHub release notes to understand breaking changes between versions. The command-line flags appear stable across the examples, but the config file format may evolve. Before upgrading, test your existing SBOM generation commands against the new version to catch any flag changes.

Editorial conclusion

Adopt bom if you need an SPDX-focused SBOM generator that handles directories, container images, and individual files with a built-in license classifier and Go dependency analysis. It suits Kubernetes ecosystem projects and those already working with SPDX formats. Avoid it if you expect a general-purpose SBOM tool with support for multiple standards like CycloneDX out of the box, or if you need a stable feature set, since recent releases (v0.7.0 and v0.7.1) landed within a day of each other, suggesting active but potentially volatile development. Before adopting, verify that the current command flags match your workflow, especially the --provenance flag for in-toto attestations, and confirm the output format (json or tag-value) meets your downstream tooling requirements.

Frequently asked questions

Official sources

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