Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add CycloneDX 1.6 Support #2974

Closed
ashearin opened this issue Jun 19, 2024 · 3 comments · Fixed by #2978
Closed

Add CycloneDX 1.6 Support #2974

ashearin opened this issue Jun 19, 2024 · 3 comments · Fixed by #2978
Labels
enhancement New feature or request good-first-issue Good for newcomers

Comments

@ashearin
Copy link

ashearin commented Jun 19, 2024 •
edited
Loading

What would you like to be added:

Support for CycloneDX 1.6 Specification.

Why is this needed:
Teams and Tools that leverage Syft as part of the SW supply chain security have a need for the additional fields and to avoid compatibility issues when working with sboms

Additional context:
The underlying go library used for cyclonedx has added support for 1.6 (as of v0.9.0) and is already in use with syft as of this PR.
@ashearin ashearin added the enhancement New feature or request label Jun 19, 2024
@ashearin ashearin changed the title Add CycloneDX 1. Add CycloneDX 1.6 Support Jun 19, 2024
@kzantow kzantow added the good-first-issue Good for newcomers label Jun 19, 2024
@ragaskar
Copy link
Contributor

This is related to anchore/grype#1951, as grype appears to be using the syft internal cyclonedxutil decoder for decoding. ... I may take a shot at PR-ing a fix this evening, let me see if I have enough time.

@ragaskar
Copy link
Contributor

ragaskar commented Jun 20, 2024 •
edited
Loading

Just a quick note after digging into syft. I now believe I'm incorrect about this being the root issue behind my particular problem. It's very related in the sense that if someone updated the list of supported cyclonedx versions to include 1.6 in syft my problem would go away -- for now ... but the core problem seems to be that grype, when it emits an SBOM is simply calling cyclonedx.NewBOM, which uses the latest available cyclonedx SpecVersion by default, whereas syft (very reasonably, imo!) has their own internal list of default + supported versions.

I'd like to fix both problems and not run into the grype problem again when cyclonedx spec 1.7 comes out, so I think I might start over there.

ragaskar added a commit to ragaskar/syft that referenced this issue Jun 20, 2024
@ragaskar
Add 1.6 to supported cyclonedx spec versions.
c995449 
- Resolves anchore#2974

Signed-off-by: Rajan Agaskar <ragaskar@gmail.com>
@ragaskar ragaskar mentioned this issue Jun 20, 2024
Merged
ragaskar added a commit to ragaskar/syft that referenced this issue Jun 20, 2024
@ragaskar
Add 1.6 to supported cyclonedx spec versions.
ab7cb32 
- Resolves anchore#2974
- Also add detailed instructions re: updating schemas (necessary when
  a new CycloneDX spec version becomes available.

Signed-off-by: Rajan Agaskar <ragaskar@gmail.com>
ragaskar added a commit to ragaskar/syft that referenced this issue Jun 20, 2024
@ragaskar
Add 1.6 to supported cyclonedx spec versions.
cf08eda 
- Resolves anchore#2974
- Also add detailed instructions re: updating schemas (necessary when a
  new CycloneDX spec version becomes available.
- The DefaultVersion constant has been updated to "1.6" -- it's not
  clear to me how this is used at this time (it may be redundant given
  other code), but effectively unless a specific spec version is
  configured, `syft` will emit the "most recent" spec version available
  for cyclonedx. Users who wish to pin back to a "older" specVersion
  (e.g. to preserve compatibilty with utilities that have not yet bumped
  to latest) can either set this in a syft config file or pass a
  name@spec_version pair to the output flag (e.g. `-o
  cyclonedx-json@1.5=some-1.5-spec-bom.cdx.json`)

Signed-off-by: Rajan Agaskar <ragaskar@gmail.com>
ragaskar added a commit to ragaskar/syft that referenced this issue Jun 20, 2024
@ragaskar
Add 1.6 to supported cyclonedx spec versions.
a8fe39d 
- Resolves anchore#2974
- Also add detailed instructions re: updating schemas (a necessary task
  when a new CycloneDX spec version becomes available).
- The DefaultVersion constant has been updated to "1.6" -- it's not
  clear to me how this is used at this time (it may be redundant given
  other code), but effectively unless a specific spec version is
  configured, `syft` will emit the "most recent" spec version available
  for cyclonedx. Users who wish to pin back to a "older" specVersion
  (e.g. to preserve compatibilty with utilities that have not yet bumped
  to latest) can either set this in a syft config file or pass a
  name@spec_version pair to the output flag (e.g. `-o
  cyclonedx-json@1.5=some-1.5-spec-bom.cdx.json`)

Signed-off-by: Rajan Agaskar <ragaskar@gmail.com>
ragaskar added a commit to ragaskar/syft that referenced this issue Jun 20, 2024
@ragaskar
Add 1.6 to supported cyclonedx spec versions.
8ad9f3f 
- Resolves anchore#2974
- Also add detailed instructions re: updating schemas (a necessary task
  when a new CycloneDX spec version becomes available).
- The DefaultVersion constant has been updated to "1.6" -- it's not
  clear to me how this is used at this time (it may be redundant given
  other code), but effectively unless a specific spec version is
  configured, `syft` will emit the "most recent" spec version available
  for cyclonedx. Users who wish to pin back to a "older" specVersion
  (e.g. to preserve compatibilty with utilities that have not yet bumped
  to latest) can either set this in a syft config file or pass a
  name@spec_version pair to the output flag (e.g. `-o
  cyclonedx-json@1.5=some-1.5-spec-bom.cdx.json`)
- Regenerate relevant .golden files (there seems to be a way to do this
  via flags, but I couldn't quite figure out the right set to pass
  correctly, esp. since (as a relative go novice) I found it difficult
  to run just a single test file. I ended up "brute-forcing it" by
  changing the *updateSnapshot val to "true" and running it in Goland.
  A brief comment giving an example of regenerating fixtures usage would
  be helpful.

Signed-off-by: Rajan Agaskar <ragaskar@gmail.com>
@ragaskar
Copy link
Contributor

OK, that one looks ready for review.

An update on my goal of avoiding sbom generator surprises around cdx spec versions:

  1. I was incorrect about how the DefaultVersion constant I saw worked. It looks like syft is configured to pick the latest available spec version (for formats for which syft supports "all versions").
  2. I think grype just unintentionally uses latest (via calling cyclonedx.NewBOM() and not using the EncodeVersion to select a specific output version) to emit. That said, after beginning to get my head around how syft encoding/decoding works, I'd suspect I should take another look at grype to see if I correctly understood the flow -- perhaps grype accepts similar configuration and there is a near-term workaround if you don't want 1.6 (beyond just pinning back).
  3. For those of us concerned with surprises with backwards incompatible spec versions, syft supports configuring a cyclonedx spec either in a syft config file or by passing a "format@specVersion" pair to the output flag (e.g., -o cyclonedx-json@1.5=some-json-1.5.cdx.json). In some ways this is the best of both worlds, the defaults encourage lib owners to quickly support newer specVersions, but as a user you can protect yourself by locking down to a version (above issue with grype aside).

@BrewTestBot BrewTestBot mentioned this issue Jun 24, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request good-first-issue Good for newcomers
Projects
OSS
Archived in project
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add 1.6 to supported cyclonedx spec versions. ragaskar/syft
3 participants
@ragaskar @kzantow @ashearin