Feature request: Add native uv project support (pyproject.toml + uv.lock) via cyclonedx-py uv subcommand

[m7mdhka]

Is your feature request related to a problem? Please describe.

Yes. cyclonedx-py currently supports generating SBOMs from environments, requirements, Pipenv, and Poetry projects, but there is no first-class uv project workflow in released versions.
This makes it harder for teams using uv to generate lockfile-based SBOMs directly from pyproject.toml + uv.lock, and can block adoption in projects where uv is the package manager of record.

Describe the solution you'd like

Add native uv project support as a dedicated CLI subcommand (for example, cyclonedx-py uv) that:

• accepts a project directory (or uv.lock path),
• reads pyproject.toml and uv.lock,
• resolves dependency groups/extras in a way consistent with uv,
• generates CycloneDX JSON/XML output with the same quality and validation behavior as existing subcommands,
• is documented in README and docs/usage.rst,
• includes integration/unit tests and snapshot coverage.

Describe alternatives you've considered

• Environment scan (cyclonedx-py environment): works for installed packages, but is less lockfile-centric and can differ from the exact declared lock resolution.
• Converting/exporting through external tools first: adds extra steps and potential drift between source lock data and generated SBOM.
• Maintaining custom scripts: increases maintenance burden and reduces consistency with official tool behavior.

Additional context

uv adoption is growing quickly, and users expect parity with other mainstream Python dependency workflows.
A dedicated uv subcommand would improve reproducibility, reduce friction in CI pipelines, and align with lockfile-driven supply chain practices.

Contribution

• I am willing to provide an implementation
• I will wait until somebody else implements it

[m7mdhka]

• see feat: add uv subcommand #1028

[jkowalleck]

what are the benefits over the existing methods, like running

cyclonedx-py environment --pyproject pyproject.toml "$(uv python find)"

---

you wrote

Describe alternatives you've considered
Environment scan (cyclonedx-py environment): works for installed packages, but is less lockfile-centric and can differ from the exact declared lock resolution

you claim a uv environment "can differ from the exact declared lock resolution".
how and why is this possible?
What would be the benefit of an inaccurate/wrong SBOM generated from a lockfile, over an accurate one describing your actual environment?

---

could you craft such an example where the actual py env differs from the lockfile?
please add pullrequest such a testbed - you may alter the existing testbed: https://github.com/CycloneDX/cyclonedx-python/tree/main/tests/_data/infiles/environment/via-uv

[jkowalleck]

Implementing a uv subcommand might look easy at first, getting a narrow feature set to life sounds feasible. The hard part is feature completeness, and maintenance while this external tool grows.
under these aspects, we usually encourage ecosystem maintainers to build and maintain SBOM tools themselves.

Did you reach out to the uv community and ask them how they think about implementing an SBOM command themselves?

The CycloneDX team encourages native implementations in the past, lately we helped the community around pnpm (pnpm/pnpm#10592) to build first level support for SBOM.

---

nevertheless, uv is not stable yet. Therefore, I do not like the idea of adding premature support.

---

• See also: feat: Support for uv.lock file from uv package manager #907
• related: Software Bill of Materials (SBOM) output astral-sh/uv#6012