Glossary¶

A build frontend asks a build backend for a wheel. python-sbom runs inside that build, through a build hook or the wrapper backend, and writes an SBOM into the wheel where PEP 770 tells installers to look. The SBOM is a CycloneDX document. It names the supplier, lists each component the wheel holds or declares, and records in its formulation the source revision and the build tools, the facts a reproducible build needs. A content provider adds what python-sbom cannot read from the wheel. Validation checks the document before upload, and python-sbom renders it as SPDX for tools that read only that format.

API¶: Application programming interface. Here, the Python classes and functions python-sbom publishes for content providers and build integrations, listed in Python API.
archive¶: A zip file other than a wheel that holds distributions, unpacked or as wheels, such as a zipapp. python-sbom describes it the way it describes a wheel.
build backend¶: The tool that turns a project’s source into a wheel and an sdist, such as hatchling, setuptools or maturin. A build frontend calls it through the interface PEP 517 defines.
build frontend¶: The tool a user runs to build or install a project, such as pip, uv or build. It installs the build backend in an isolated environment and asks it for the artifacts.
build hook¶: A plugin a build backend calls during its own build. python-sbom has one for hatchling, pdm-backend and setuptools, and writes the SBOM before the backend finishes the wheel.
bundled wheel¶: A wheel a project ships as a data file inside its own wheel, as virtualenv ships pip. The SBOM lists it as a component with its hashes, license, files and vendored packages.
CI¶: Continuous integration: the automated jobs, such as GitHub Actions workflows, that build, test and publish a project on each change.
component¶: One entry in the SBOM: the project itself, a file, a bundled wheel, a declared dependency or a build tool.
content provider¶: A class a project writes to add components and properties python-sbom cannot read from the artifact. Every integration loads the one the project’s configuration names.
CycloneDX¶: The CycloneDX SBOM standard, which python-sbom writes in version 1.6 as JSON.
formulation¶: The part of a CycloneDX document that records how the artifact was made: the build workflow, the tools it used, and the build time when the environment set it.
IRI¶: Internationalized Resource Identifier, defined by RFC 3987: a URL that may hold any Unicode character. CycloneDX requires every link to be one.
JSON¶: JavaScript Object Notation, the text format CycloneDX and SPDX documents use.
PEP 517¶: The Python Enhancement Proposal that defines the interface between a build frontend and a build backend.
PEP 660¶: The Python Enhancement Proposal that adds editable installs to the interface of PEP 517.
PEP 770¶: The Python Enhancement Proposal that gives a wheel a folder for SBOMs in its metadata directory, so installers copy them into the environment where scanners look.
PyPI¶: The Python Package Index, where projects publish their wheels and sdists.
reproducible build¶: A build that yields the same bytes from the same source and tools, as Reproducible Builds defines it. The SBOM records the source revision and each build tool with its files, so a third party can rebuild the wheel and compare.
SBOM¶: Software bill of materials: a document that lists what a piece of software contains and how it was built.
sdist¶: Source distribution: the archive of a project’s source from which a build backend builds a wheel later. python-sbom stores the source revision in it, so a wheel built from it still names its commit.
SHA-1¶: Secure Hash Algorithm 1, an older hash function that SPDX 2.3 requires for every file.
SHA-256¶: The 256-bit variant of Secure Hash Algorithm 2, the hash function a wheel’s file list records for each file and the SBOM copies, so anyone can check the bytes.
source revision¶: The commit a build ran from, and whether the checkout had uncommitted changes.
SPDX¶: Software Package Data Exchange, another SBOM standard. python-sbom renders the CycloneDX document as SPDX 2.3 on request.
supplier¶: The organization that ships the project. The configuration names it, and the SBOM records it as the document’s supplier and manufacturer.
URL¶: Uniform Resource Locator: a web address.
validation¶: The check of a finished SBOM against the CycloneDX schema, its own references and an optional license policy, meant to run in CI before upload.
vendored package¶: A package copied into another package’s source instead of installed as a dependency. The SBOM lists it under the bundled wheel that carries it.
wheel¶: The built distribution an installer unpacks into an environment, and the file python-sbom writes the SBOM into.
wrapper backend¶: python-sbom’s own build backend, which passes each call to the backend the project names and adds the SBOM to the wheel it gets back. It serves backends without a build hook.
zipapp¶: A Python application packed into one zip file that the interpreter runs directly, as the zipapp module builds it.