-
Notifications
You must be signed in to change notification settings - Fork 568
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.
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
Support format SBOM conversion #563
Comments
I'd start converting Syft to any of those, as detailed in the example. Another option could be to support multiple output formats instead of a single output format as today. wdyt ? |
This definitely makes sense — and I'd say this is a separate feature, which we happen to have captured in #325 |
Relevant to this is the cyclonedx's SPDX taxonomy > CycloneDX/cyclonedx-property-taxonomy#7 |
from refinement:
|
For SPDX this the encode/decode process has data loss, I suspect: due to library differences, we encode it via our JSON definition, and decode using SPDX's go lib. Moving to SPDX's official lib might help us here in two fronts: offload code we have to maintain AND fix data loss.
|
Open Q&As:
MVPing itBasic supported fields:
Other relevant points
|
Syft can output multiple SBOM formats, however, once you have that format you can't convert to another format. This could be most useful if you have a syftjson formatted document and you want to produce SPDX (which should be lossless). In these cases something like this would be nice:
It's not clear what to do in cases where there is potentially lossy behavior (e.g. convert from cyclonedx to syftjson):
--force
or similar option)One question that comes to mind: do we want to restrict these conversions to only documents that syft created to begin with? Or be able to generically convert between formats for a document that was generated from another (non-syft) tool? (does thing bring on more complexity? or not?... if so, how much?)
The text was updated successfully, but these errors were encountered: