On 2/3/23 17:06, Richard Purdie wrote:

On Fri, 2023-02-03 at 12:26 -0600, Alex Stewart wrote:

Hey Josh,

I have been roadmapping SBOM generation for NI's yocto distro and have a
few open questions about the future of SPDX and the create-spdx bbclass.
Since your name seems to be attached to both of those, I figure you
might have the best insight here.

Also posting to the OE-core ML so that this discussion can help other
members.


1. SPDX 3 timeline. I hear that SPDX 3 is going to be a complete rewrite
of the spec, with more support for modern SBOM discussion topics like
VEX and more comprehensive vulnerability tracking. And it also seems to
me that the timeline for its release is very behind schedule [1], but
still in active development. Can you give a SWAG for how close that new
spec is to completion? Are we months away or years?

2. If/when SPDX 3 support is released, is it to be assumed that the SPDX
facilities in OE core are going to be upgraded to handle it?

Assuming someone does the work, which is likely, yes. We did namespace
the class in master to prepare for that.

3. The rest of my org is interested in CycloneDX as our common SBOM
format. Have there been any discussions about supporting CDX SBOMs in
OE-core? Any blockers there; or is it something that my org could author
and upstream if we decide to go that route?

At this point OpenEmbedded/Yocto Project has decided to go the SPDX
route for various reasons.

Are those reasons documented somewhere?

Something about CDX rubs me the wrong way (besides it being named like an off-brand printer company), but I can't put my finger on what. So if there are technical reasons that it is less desirable for the OE usecase, I'd like to know about them.

My understanding is that CDX has better support for embedding vulnerability (+VEX) and attestation elements into its DOM, which is something that our Aero-Def customers will be interested in. I suppose I can build workflows to add that information after converting the OE-SPDX document to CDX, but I'd like to integrate the whole thing into an OE build, if possible.

I'm not sure I want to see two formats being
added directly to the core, the better solution would likely be to
translate the SPDX output into CycloneDX if/as needed.

I'm concerned about the lossiness of that conversion. Based on the CDX-SPDX mapping document in the cdx2spdx tool repo [1], they seem roughly compatible. But I haven't been able to find a clean tool which converts the other direction, nor a mapping document for the SPDX->CDX pathway.

Is anyone watching this thread doing SPDX to CDX conversions as a part of their pipelines today? If so, what tools are you using and are there any hazards to that approach?

[1] https://docs.google.com/spreadsheets/d/1PIiSYLJHlt8djG5OoOYniy_I-J31UMhBKQ62UUBHKVA/edit?usp=sharing


I appreciate the feedback, everyone.

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@...