python-sbom

SBOMs for Python distributions. python-sbom writes a CycloneDX 1.6 SBOM into every wheel you build, at <name>-<version>.dist-info/sboms/<name>.cdx.json. That is where PEP 770 tells installers to keep SBOMs, so they land in the environment next to the installed package, where scanners look for them.

Why a wheel needs its own SBOM

General-purpose scanners read the dependencies a package declares or the packages an environment has installed. They cannot see a wheel your project ships as a data file, and they cannot say how the wheel was built. The SBOM this package writes records both: the wheels you bundle, with their hashes, licenses and vendored packages, and the Python version and packages of the build environment. A third party can use that record to rebuild the wheel and compare the bytes.

Quick start

For a project built with hatchling, add the hook to the build requirements and enable it in pyproject.toml:

[build-system]
build-backend = 'hatchling.build'
requires = ['hatchling>=1.28', 'python-sbom[hatch]>=0.1']

[tool.hatch.build.hooks.python-sbom]

Every wheel you build now carries the SBOM. For a project built with another backend, such as meson-python, run python-sbom embed dist/*.whl after the build; Use it shows both.

• Use it
  • With hatchling
  • With another build backend
  • Render it as SPDX
  • Check it in CI
• Extend it
  • Add content with a provider
  • Worked example: a seeder
  • Describe another archive
• How it works
  • Architecture
  • What the SBOM records
  • Reproducibility
  • Limitations
• Command line interface
  • options
  • embed
  • archive
  • spdx
  • validate
• Python API
  • python_sbom.__version__
  • Hatchling build hook
  • Content provider
  • Component types
  • Errors
• Changelog
  • Unreleased
  • 0.1.0 (2026-11-08)
• Contributing
  • How the code fits together
  • What each layer guarantees
  • Updating the schemas
  • Benchmarks
  • Changelog fragments