Support enriching SPDX SBOMs

[garethr]

Currently parlay only support CycloneDX. Implementing for SPDX would be useful, though not all information may be applicable to the SPDX spec.

[mcombuechen]

Hey @garethr
happy to take a stab at this. I think we need a sort of strategy pattern solution that invokes different code based on whether handling CycloneDX or SPDX.

Some questions:

1. Are the contents of lib intended to be used by 3rd party tools outside of parlay? (I think this would be great, maybe we rename the directory to pkg to make it more Golang idiomatic)
2. The enrich interface (enrichSBOM functions in lib that is) is currently bytes in, bytes out, which is a pleasant UX. However, it would require us to apply brute force to understand the given SBOM in a sea of possible permutations (CycloneDX? SPDX? Schema version? XML? JSON? YAML? Text?). Should the interface change to require the SBOM schema, or do we want to invest in a brute force solution?

[garethr]

Good questions:

1. Yes, I think we should formalise a library interface, and make the package names more idiomatic. Parlay could be used by SBOM generation tools to just do the enrichment at the same time as build. Have a tracking issue for that Document/formalise use of Parlay as a library #10.
2. I've though about it only in passing, pros and cons to both. I'm not strongly opinionated in theory. I think it's a case of writing some code and one approach hopefully feeling more pleasant. Maybe a slight bias towards an explicit interface?

[goneall]

Not being a Go programmer myself, I won't be able to contribute code - but I can point you to some libraries supported by the SPDX community that may be helpful. My apologies if this is already known info.

• tools-golang - Includes a library that can read/write SPDX documents
• SPDX JSON Schema
• cdx2spdx - Java utility that converts CycloneDX to SPDX - might be useful to understand how to translates different fields

Ping me if you have any SPDX questions and I'd be glad to help.

[mcombuechen]

Draft PR open here: #20

[mcombuechen]

@garethr I had a play with the brute-force idea in this draft PR. It lead me to believe that we need to extend the interface beyond just bytes and ask consumers to specify the given format, I see too many cons otherwise. WDYT?

[goneall]

I had a play with the brute-force idea #20. It lead me to believe that we need to extend the interface beyond just bytes and ask consumers to specify the given format, I see too many cons otherwise. WDYT?

@garethr I tend to agree with @mcombuechen - the brute force could be problematic.

[mcombuechen]

@garethr Should we close this issue?

[garethr]

Now shipped in v0.2.0