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

[m7mdhka]

@jkowalleck Thanks for the feedback. I wanted to clarify the rationale behind this PR.

uv's native SBOM export is hardcoded to CycloneDX 1.5, not 1.7. Running uv export --format cyclonedx1.5 produces a v1.5 document, and there is currently no cyclonedx1.6 or cyclonedx1.7 option available.

CycloneDX 1.7 (released October 2025) introduces critical capabilities missing from 1.5:

• Citations / Data Provenance — enables verifiable chains of provenance for auditing
• Patent Information — essential for IP transparency and legal compliance
• Expanded CBOM (Cryptography Bill of Materials) — required for cryptographic governance and post-quantum readiness
• Traffic Light Protocol (TLP) — for distribution control of sensitive SBOM data
• License expression details with text attachments

Rather than waiting for uv to potentially add 1.7 support natively (which would require them to upgrade their CycloneDX crate dependency and implement new schema structures), this PR provides immediate access to CycloneDX 1.7 features for uv users through the established cyclonedx-py toolchain.

Regarding stability — while uv itself is not yet at 1.0, its lockfile format (uv.lock) has been stable enough for the ecosystem to build around. The Snyk partnership and native SBOM export (even if 1.5) demonstrate that the uv project considers SBOM support production-ready.

Happy to discuss how we can ensure this implementation remains maintainable as both uv and CycloneDX evolve.

[jkowalleck]

So uv already has a working SBOM generator. thats fantastic.

Out of interest, which of the features of CycloneDX 1.6 or Cycloned 1.7 would be of need for the uv SBOM?

Anyway, CycloneDX is backwardas compatible. Every CycloneDX 1.5 is a valid CycloneDX 1.7 and should convertable quite easy. THere are tools that can do that - see https://cyclonedx.org/tool-center/

---

Rather than waiting for uv to potentially add 1.7 support natively (which would require them to upgrade their CycloneDX crate dependency and implement new schema structures),

since uv already has a built-in SBOM generator, I would encourage discussing missing features and ways to get them done with the uv community.

this PR provides immediate access to CycloneDX 1.7 features for uv users through the established cyclonedx-py toolchain.

Which of the features would your feature implement, that the existing ones from uv does not have already?

---

PS: i dont see any need to implement such feature. please respond to the previously asked questions: #1029 (comment)