Yes. The requires list in the build-system table names packages that run to build your project, and the build-backend line names the tool that does the work. Anyone who builds your source distribution runs them, so they belong in your review and your inventory like any dependency.
What the table is
The Python Packaging guide describes the build-system table. The build-backend value names the backend that turns your project into distributable packages. The requires value lists the packages needed to run that build, usually just the backend, though it can include others and carry version constraints. The guide says the table should always be present.
[build-system]
requires = ["setuptools >= 77.0.3"]
build-backend = "setuptools.build_meta"
The guide also gives values for other backends, and says to copy them from each backend's documentation.
Why it counts as supply chain
Two groups run those packages:
- You, when you run a build before each release.
- Your users, when pip installs from a source distribution instead of a wheel. The pip documentation says pip uses the project's build backend to determine metadata, and that build dependencies from this table (PEP 518) are involved. See pip install: wheel or source.
So a compromised build requirement can run on both. These packages often do not appear in a runtime requirements file, which is why they are easy to forget. Our post on setup.py dependencies missing from your SBOM covers the inventory gap.
Keep it small and understood
- Use one build backend, and the smallest set of extras in requires.
- Set a lower bound for a reason, such as a feature you need, not a habit.
- Do not add plugins to requires that you cannot explain.
- Choose the backend deliberately. See how to choose a Python build backend for a new library.
- Review changes to this table in pull requests like changes to code. A new line here is new code that runs at build time.
Pinning for your own builds
A range in requires is convenient for users but lets your release build pick up a new version of the backend. To make your own release builds repeatable, build in CI from a pinned environment and record what was used. The build tool documentation says python -m build reads pyproject.toml and calls the backend to produce sdist and wheel files, and does not manage dependencies or virtual environments itself, so pinning is your job. Compare the approaches in pinning Python dependencies with requirements and lock files.
Add it to a checklist
Before each release:
- Read the build-system table. Has anything been added since the last release?
- Build in a clean environment in CI.
- Check what is inside the artifacts, as in checking your sdist for secrets and stray files.
- Upload through trusted publishing from the same workflow.
Try it yourself
Click through it at your own pace, or open it full screen. See how an inventory groups packages, then ask whether your build tools would appear in yours.
Quick check
Is the build-system table required?
The packaging guide says it should always be present, because it defines which build tool you use.
Does python -m build install my dependencies?
The build docs say it focuses on building and does not manage dependencies or virtual environments.
Sources
- Python Packaging guide: Writing your pyproject.toml
- pypa build documentation
- pip documentation: pip install
Last reviewed: 19 October 2026.
