SBOM export support #4

thomasschafer · 2025-09-22T16:25:58Z

To do:

Update docs (see here)
Recreate PR with base as astral-sh/uv when ready for review, and link the original issue

woodruffw · 2025-09-24T16:59:42Z

crates/uv-configuration/src/pip_compile_format.rs

Nitpick: I think it's be nice to keep this in the export_format.rs module, since it's conceptually still a set of export formats, just limited to pip compile 🙂

Makes sense, done!

woodruffw · 2025-09-24T17:05:07Z

Do we need to update docs?

Yes, please 🙂

zanieb · 2025-09-24T17:19:23Z

I'm not sure if we talk about export much in the documentation right now. The most helpful thing would be to write a section explaining the format, how you'd generate it, and then how you'd consume it. I can figure out how to fit that content into the larger documentation story.

zanieb · 2025-09-24T17:20:15Z

Did you explore just making this format an enum member that's banned in uv pip compile? What motivates splitting the enum up? (I think it's probably fine, I'd just explore both options myself if I were making the change)

thomasschafer · 2025-09-25T09:14:08Z

Did you explore just making this format an enum member that's banned in uv pip compile? What motivates splitting the enum up? (I think it's probably fine, I'd just explore both options myself if I were making the change)

Are you meaning something like adding a runtime error when users attempt to use the SBOM format in uv pip compile? If so, we did consider that but had a couple of concerns. First, the auto-generated help text from clap would show cyclonedx1.5 as a possible option i.e.

$ uv pip compile --help | rg format
      --format <FORMAT>                                  The format in which the resolution should be output [possible values: requirements.txt, pylock.toml, cyclonedx1.5]

Also, we'd then need to add error handling to reject that format option when parsing the CLI args, and then add either errors or unreachable!() in the pip compile match statements, which didn't seem ideal.

Let me know if I'm missing something though or if you have other thoughts!

zanieb · 2025-09-25T12:53:41Z

Those seem like reasonable reasons to avoid it.

zanieb · 2025-09-25T12:54:50Z

crates/uv-configuration/src/export_format.rs

+    CycloneDX1_5,
+}
+
+/// The format to use when compiling to a `requirements.txt` or `pylock.toml` file.


This should probably be

Suggested change

/// The format to use when compiling to a `requirements.txt` or `pylock.toml` file.

/// The output format to use in `uv pip compile`.

zanieb · 2025-09-25T12:58:23Z

crates/uv-resolver/src/lock/export/cyclonedx_json.rs

+        Source::Git(url, _) | Source::Direct(url, _) => {
+            ("generic", format!("?download_url={}", url.as_ref()))
+        }


I was surprised to see Git dependencies are just "generic"

Thanks for flagging - for GitHub URLs specifically there is a github purl type which we should be using here, although for other Git sources I'm not aware of anything more specific. We'll revisit this to handle that case!

zanieb · 2025-09-25T12:58:43Z

crates/uv-resolver/src/lock/export/cyclonedx_json.rs

+    package.id.name.to_string()
+}
+
+/// Generate a Package URL (purl) from a package


We should indicate when this will return None

zanieb · 2025-09-25T13:01:29Z

crates/uv-resolver/src/lock/export/cyclonedx_json.rs

+
+    Component {
+        component_type: classification,
+        name: NormalizedString::new(&name),


It's a little weird that you use get_package_name to get a String then use &str here to construct a new NormalizedString owned type. I would probably omit the get_package_name and get_version_string helpers or at least avoid returning owned values since the caller needs borrowed ones anyway.

Good point - I've updated get_package_name to return a &str, although for get_version_string it looks like Version implements Display (here) to get a String but no way to get an &str (at least that I can see)

zanieb · 2025-09-25T13:04:00Z

crates/uv/tests/it/export.rs

 }
+
+#[test]
+fn cyclonedx_export() -> Result<()> {


You could also test a direct URL, e.g., by copying a wheel URL from PyPI

jkowalleck

could you add tests? maybe snapshot-tests on prepared test beds.?

Since you are crafting CycloneDX based on "untrusted" data, I'd encourage to also validate the SBOM results before returning it.
If you don't want to validate the SBOM in the production code, I would still validate them in tests, to show that you are producing valid SBOMS.

PS: I am not a rust export. but I understand that bom.validate() would run certain validations - for example that bomRefs are unique, and other schema- and plausibility-checks.

jkowalleck · 2025-09-25T16:49:42Z

crates/uv-resolver/src/lock/export/cyclonedx_json.rs

+    let version_specifier = version.map_or_else(String::new, |v| format!("@{v}"));
+
+    Some(format!(
+        "pkg:{purl_type}/{name}{version_specifier}{qualifiers}"


why do this yourself?
there is an official PURL library to craft proper package URL strings: https://github.com/package-url/packageurl.rs

@zanieb / @woodruffw any objections to me pulling that additional crate in?

the "official" library is mere a backup/fork of another lib's source code:
https://github.com/scm-rs/packageurl.rs

We're just constructing PURLs not parsing them, does a library have much to offer here?

I'm generally wary of more dependencies, especially for something straight-forward. I'm not sure what to think of there being a library that's just a fork of another here.

my hint with the fork is jost to give a heads up to use the right library, which appears to be https://github.com/scm-rs/packageurl.rs.

anyway, PURL is not just concatenating strings the correct way. Especially when using entrusted user input, crafting a malformed PURL is just so easy.
i mean, are you even aware of all the characters that are not allowed in a PURL, and the characters that must be percent-encoded, or the characters that must NOT be percent-encoded? (there is no sanitation or handing of these cases in the current code yet)
I encourage using a dedicated library for crafting valid PURL strings - otherwise you will just implement a thing that has been solved already....

PS: see the wrong implementation in action, where a library should have done the job -- #4 (comment)

I don't think this is being constructed from untrusted user input, this is being constructed from the output of a uv resolution and each of these types is validated, e.g., the package name and version specifiers are already parsed and normalized. This isn't to say we shouldn't use a package to construct the PURL, but we're not concatenating arbitrary strings here.

The transitive deps from that crate don't look too bad (and are already in our transitive closure), but I also agree with @zanieb that we don't have any arbitrary inputs in this context -- we know by construction that our name and version are well-formed. I'm also similarly hesitant to bring in another sidecar dep (and I similarly find the "official" fork thing confusing -- which one is authoritative if they diverge?). Overall I'd lean towards doing it ourselves here, unless there's some hidden complexity in the small subset of purls we emit.

(We do probably need to percent-encode the values in the qualifier, however, if I'm reading the purl spec correctly.)

thomasschafer · 2025-09-26T08:08:40Z

could you add tests? maybe snapshot-tests on prepared test beds.?

@jkowalleck there are already some tests here and we're planning on adding some more - is this what you were thinking of or did you have other ideas?

jkowalleck · 2025-09-26T11:46:28Z

crates/uv/tests/it/export.rs

+          "bom-ref": "[email protected]",
+          "name": "flask",
+          "version": "2.3.3",
+          "purl": "pkg:generic/[email protected]?download_url=https://github.com/pallets/flask.git?rev=2.3.3#3205b53c7cf69d17fee49cac6b84978175b7dd73"


broken result. the download_url was not properly escaped, so that the hash and the query string are propagated to the purl ...
expected outcome: pkg:generic/[email protected]?vcs_url=https://github.com/pallets/flask.git%3Frev%3D2.3.3%233205b53c7cf69d17fee49cac6b84978175b7dd73

Thanks! Fixed

SBOM export support - more changes

See PR here for reasoning: CycloneDX/cyclonedx-property-taxonomy#142

docs: uv export documentation

thomasschafer · 2025-10-30T19:31:36Z

Closing in favour of this PR

thomasschafer force-pushed the sbom-export-support branch 4 times, most recently from 5e494c7 to 8c3a41b Compare September 24, 2025 16:21

thomasschafer mentioned this pull request Sep 24, 2025

Software Bill of Materials (SBOM) output astral-sh/uv#6012

Open

thomasschafer force-pushed the sbom-export-support branch 2 times, most recently from 2853f6a to 3b592f9 Compare September 24, 2025 16:46

woodruffw reviewed Sep 24, 2025

View reviewed changes

thomasschafer force-pushed the sbom-export-support branch 2 times, most recently from feb3c90 to 41d8858 Compare September 25, 2025 09:24

zanieb reviewed Sep 25, 2025

View reviewed changes

thomasschafer force-pushed the sbom-export-support branch from 594c9f4 to 2fa4cd5 Compare September 25, 2025 14:46

jkowalleck reviewed Sep 25, 2025

View reviewed changes

jkowalleck reviewed Sep 26, 2025

View reviewed changes

thomasschafer force-pushed the sbom-export-support branch 3 times, most recently from ae20eeb to 80084c1 Compare September 29, 2025 16:31

thomasschafer force-pushed the sbom-export-support branch from 80084c1 to 803191b Compare October 15, 2025 11:14

thomasschafer force-pushed the sbom-export-support branch 2 times, most recently from 16fb577 to 4ddba58 Compare October 29, 2025 15:41

snyk-will and others added 20 commits October 30, 2025 15:00

Add tooling metadata field

7508199

Add dependency tree to CDX output

c053521

Tidy up dependency building and imports

6d50b13

Add tests for git deps and no deps

f3447ae

Update docs

e7f4fc7

Fix linting errors

35eb2c1

Move PipCompileFormat into export_format.rs

b6468e6

Update comments and return &str for package name

3e3e8ff

Add purl encoding

a5a8204

Add more tests

546bfff

Add workspace information

1abfbf1

Update component lookup

271c927

Add markers

08436aa

Replace python:environment_marker with uv:marker

5dab6e0

More fixes to properties

8fa0e3e

Merge pull request #5 from thomasschafer/sbom-export-support-2

843c4fa

SBOM export support - more changes

Guard sbom export behind preview flag

815faaa

Update cdx:python:package:marker to uv:package:marker

9f21a65

See PR here for reasoning: CycloneDX/cyclonedx-property-taxonomy#142

Update comment

64686bd

Skip conflict detection for SBOMs

8647def

thomasschafer force-pushed the sbom-export-support branch from 527a2b5 to 8647def Compare October 30, 2025 15:06

snyk-will and others added 7 commits October 30, 2025 15:13

docs: uv export documentation

5950799

chore: add preview message

605b59a

fix: resolve conflicts after rebasing

1b72fea

Add preview link to note

162e668

Merge pull request #6 from thomasschafer/sbom-export-docs

042d730

docs: uv export documentation

Refactor component map

afd04ac

Insert synthetic root when using --all-packages flag

de35a94

thomasschafer closed this Oct 30, 2025

	/// The format to use when compiling to a `requirements.txt` or `pylock.toml` file.
	/// The output format to use in `uv pip compile`.

SBOM export support #4

SBOM export support #4

Uh oh!

Conversation

thomasschafer commented Sep 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

woodruffw commented Sep 24, 2025

Uh oh!

zanieb commented Sep 24, 2025

Uh oh!

zanieb commented Sep 24, 2025

Uh oh!

thomasschafer commented Sep 25, 2025

Uh oh!

zanieb commented Sep 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thomasschafer Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zanieb Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkowalleck left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkowalleck Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkowalleck Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkowalleck Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thomasschafer commented Sep 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jkowalleck Sep 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thomasschafer commented Oct 30, 2025

Uh oh!

Reviewers

Assignees

thomasschafer commented Sep 22, 2025 •

edited

Loading

thomasschafer Sep 25, 2025 •

edited

Loading

zanieb Sep 25, 2025 •

edited

Loading

jkowalleck left a comment •

edited

Loading

jkowalleck Sep 25, 2025 •

edited

Loading

jkowalleck Sep 25, 2025 •

edited

Loading

jkowalleck Sep 25, 2025 •

edited

Loading

thomasschafer commented Sep 26, 2025 •

edited

Loading

jkowalleck Sep 26, 2025 •

edited

Loading