Skip to content

Add CycloneDX v1.5 writing#3176

Open
RossComputerGuy wants to merge 1 commit intoanchore:mainfrom
DeterminateSystems:feat/cyclonedx-write-version
Open

Add CycloneDX v1.5 writing#3176
RossComputerGuy wants to merge 1 commit intoanchore:mainfrom
DeterminateSystems:feat/cyclonedx-write-version

Conversation

@RossComputerGuy
Copy link
Copy Markdown

It is useful to be able to write CycloneDX v1.5 VEX since the CycloneDX Rust crate does not support v1.6 yet (ref: CycloneDX/cyclonedx-rust-cargo#769). Rather than waiting for the crate to support that, or spending the time to implement it, it is simpler to just make Grype support it.

@RossComputerGuy RossComputerGuy force-pushed the feat/cyclonedx-write-version branch from 91d0890 to 94a72ef Compare January 21, 2026 18:53
Comment thread internal/format/format.go Outdated
CycloneDXFormat Format = "cyclonedx"
CycloneDXJSON Format = "cyclonedx-json"
CycloneDXXML Format = "cyclonedx-xml"
CycloneDXFormatv1_5 Format = "cyclonedx-v1.5"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should use this format exactly. We have handling in Syft for formats in different versions with the syntax: <format>@<version>, for CycloneDX, it would be cyclonedx-json@1.5. There is some logic to handle versions nicely including finding the latest version where only a major version is specified, for example spdx-json@2 results in spdx-json version 2.3. It would be nice to reuse this logic, but it looks like it's somewhat specific to an sbom.FormatEncoder. In the meantime, we should use an identical syntax in Grype, e.g.: cyclonedx@1.5, cyclonedx-json@1.5, and cyclonedx-xml@1.5

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't aware of there being a specific format to the versioning. Would it be good to change Format into a struct and use some of the logic from FormatEncoder?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We want to update the Grype presenters to be more like Syft formats, but I wouldn't ask you to do this as part of your PR here unless you felt like it. The main thing is the version strings specified should be the same between the tools

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, that makes total sense to me. I'm not fully familiar with Go so I'll probably just update the formatting stuff to handle the version.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I've gotten it to use the Syft formatted version string. Not the prettiest implementation but it's straightforward and it works.

@RossComputerGuy RossComputerGuy force-pushed the feat/cyclonedx-write-version branch 3 times, most recently from 52fb622 to 8f9440f Compare January 21, 2026 20:37
@kzantow
Copy link
Copy Markdown
Contributor

kzantow commented Jan 29, 2026

Apologies for not running the tests earlier -- it looks like there are some static analysis failures -- these seem straightforward: unnecessary conversion and Format specifier. And some test failures; are you able to get these cleaned up?

Signed-off-by: Tristan Ross <tristan.ross@determinate.systems>
@RossComputerGuy RossComputerGuy force-pushed the feat/cyclonedx-write-version branch from 8f9440f to 9116f39 Compare January 29, 2026 17:08
@RossComputerGuy
Copy link
Copy Markdown
Author

Great, I believe those should be fixed now. I tried running make unit locally but it fails because it doesn't like my systems being aarch64 so Docker things fail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants