SPDX 3 and OE-core CycloneDX support

SPDX 3 and OE-core CycloneDX support

[Alex Stewart]

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?

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?


[1] https://github.com/spdx/spdx-spec/milestone/3


Appreciate the input,

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

alex.stewart@ni.com

Re: [OE-core] SPDX 3 and OE-core CycloneDX support

[Richard Purdie]

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. 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.

Cheers,

Richard

Re: Re: [OE-core] SPDX 3 and OE-core CycloneDX support

[Alex Stewart]

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@ni.com

Re: [OE-core] SPDX 3 and OE-core CycloneDX support

[Alexander Kanavin]

On Sat, 4 Feb 2023 at 22:47, Alex Stewart <alex.stewart@ni.com> wrote:
> > 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.

This is entirely non-technical, but what is the reason for CycloneDX
to exist in the first place? SPDX is an older standard, it's managed
by Linux Foundation, and yet some people decided to go off and write
their own thing instead of working with SPDX to evolve that in the
desired direction. And then they promote it with a long list of
company logos. Xkcd's standards link would be too tired and obvious
here.

Alex

Re: SPDX 3 and OE-core CycloneDX support

[Joshua Watt]

On Fri, Feb 3, 2023 at 12:26 PM Alex Stewart <alex.stewart@ni.com> 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?

Our goal is to provide SPDX 3.0 with "example" SPDX 3.0 documents
before the initial release. This should benefit both projects, since
it means that we can give SPDX real examples of comprehensive SBoMs
before they release the 3.0 spec, and also means that Yocto project
SPDX output should be of high quality.

SPDX 3.0 is moving along and it's getting closer to release, but I
can't say exactly when the release will be. If you have serious
interest in this, I would recommend joining the SPDX meetings:
https://github.com/spdx/meetings/blob/main/README.md

>
> 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?

Yes. We should have support for generating either the current SPDX
2.2, or SPDX 3.0

>
> 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?

As stated, we don't really think supporting CycloneDX is worth our
effort in the project. That effort would probably be better spent
making the conversion tools better.

There's not really any documentation why we made this choice, I just
decided to do it this way when I wrote the implementation. TBH I think
both formats are technically fine, but SPDX had an edge because of the
LF connection between the two projects. Gvien that there are
conversion tools between them, I wasn't really concerned that choosing
one format of the other would cause problems.

>
>
> [1] https://github.com/spdx/spdx-spec/milestone/3
>
>
> Appreciate the input,
>
> --
> Alex Stewart
> Software Engineer - NI Real-Time OS
> NI (National Instruments)
>
> alex.stewart@ni.com
>

Re: Re: [OE-core] SPDX 3 and OE-core CycloneDX support

[Richard Purdie]

On Sat, 2023-02-04 at 15:47 -0600, Alex Stewart wrote:
> 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.

I think I share that same feeling but it is hard to put a finger on
why.

I'm not sure anything was documented but there was a discussion by the
TSC when we made the decision. Some rough random thoughts:

* SPDX did go the extra step of becoming an ISO standard

* We (as a community) have much better contacts with the SPDX 
  community. It is a fellow Linux Foundation project.

* We already were using SPDX license identifiers so this is a natural 
  progression/alignment.

* Looking at the CDX repositories and mailing lists, the discussions 
  and contributions do look to be from a much smaller ecosystem

* SPDX are interested in engaging with us, which as Joshua mentions, 
  does have benefits. If we run into challenges, we can likely seek 
  help. We're actively involved with 3.0 which means we can hopefully 
  ensure it works well for us.

Both specifications do encode roughly the same information so the
project alignment with SPDX and the "social" aspects likely tipped the 
balance.

> 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 think CDX added VEX information in the last year or so and SPDX plans
to do so in their 3.0. I have had the feeling it is due soon.

> > 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.

You could take that different ways but it could mean people aren't
finding a need to convert SPDX to CDX, meaning SPDX is working for
them.


I don't really want to have two partially implemented SBoM mechanisms
in YP/OE so I'd probably suggest any CDX code was a separate layer at
this point. If there is actual missing capability, I'd be asking SPDX
to resolve it :)

Cheers,

Richard

(copying Kate Stewart to the discussion)

Re: Re: Re: [OE-core] SPDX 3 and OE-core CycloneDX support

[Alex Stewart]

On 2/5/23 08:11, Richard Purdie wrote:
> On Sat, 2023-02-04 at 15:47 -0600, Alex Stewart wrote:
>> 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.
> I think I share that same feeling but it is hard to put a finger on
> why.
>
> I'm not sure anything was documented but there was a discussion by the
> TSC when we made the decision. Some rough random thoughts:
>
> * SPDX did go the extra step of becoming an ISO standard
>
> * We (as a community) have much better contacts with the SPDX
>    community. It is a fellow Linux Foundation project.
>
> * We already were using SPDX license identifiers so this is a natural
>    progression/alignment.
>
> * Looking at the CDX repositories and mailing lists, the discussions
>    and contributions do look to be from a much smaller ecosystem
>
> * SPDX are interested in engaging with us, which as Joshua mentions,
>    does have benefits. If we run into challenges, we can likely seek
>    help. We're actively involved with 3.0 which means we can hopefully
>    ensure it works well for us.
>
> Both specifications do encode roughly the same information so the
> project alignment with SPDX and the "social" aspects likely tipped the
> balance.

That's good context. Thanks.

>> 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 think CDX added VEX information in the last year or so and SPDX plans
> to do so in their 3.0. I have had the feeling it is due soon.
>
>>> 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.
> You could take that different ways but it could mean people aren't
> finding a need to convert SPDX to CDX, meaning SPDX is working for
> them.

 From what I've seen, I think the SBOM ecosystem is too immature to say 
whether one is preferred over the other. It seems like most folks are 
just working with whatever falls out of their static dep analysis 
tooling, or gets handed to them by their security auditor.

I haven't yet seen evidence that any of our customers have an SBOM 
*pipeline* such that they would need to pick a common spec; but I 
suspect that is coming.

> I don't really want to have two partially implemented SBoM mechanisms
> in YP/OE so I'd probably suggest any CDX code was a separate layer at
> this point. If there is actual missing capability, I'd be asking SPDX
> to resolve it :)

Understood. I'll assume that we'll have to maintain our own layer, if we 
go that route.

> Cheers,
>
> Richard
>
> (copying Kate Stewart to the discussion)
>

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

alex.stewart@ni.com

Re: Re: [OE-core] SPDX 3 and OE-core CycloneDX support

[Alex Stewart]

Thanks for the context; I'll feed this back into our internal discussions.

Looks like I just missed the general meeting for this month. I've joined 
the ML and I'll try to attend in the future.

On 2/5/23 05:08, Joshua Watt wrote:
> On Fri, Feb 3, 2023 at 12:26 PM Alex Stewart <alex.stewart@ni.com> 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?
> Our goal is to provide SPDX 3.0 with "example" SPDX 3.0 documents
> before the initial release. This should benefit both projects, since
> it means that we can give SPDX real examples of comprehensive SBoMs
> before they release the 3.0 spec, and also means that Yocto project
> SPDX output should be of high quality.
>
> SPDX 3.0 is moving along and it's getting closer to release, but I
> can't say exactly when the release will be. If you have serious
> interest in this, I would recommend joining the SPDX meetings:
> https://urldefense.com/v3/__https://github.com/spdx/meetings/blob/main/README.md__;!!FbZ0ZwI3Qg!ofUCTG3cuMma5YvThWEwqKVzFJ2AWeMpZT8faPH4PrT-1fujpKm0yyXwYU9fcuvDPHNI0DnNjVqJWLTVF84$

>> 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?
> Yes. We should have support for generating either the current SPDX
> 2.2, or SPDX 3.0
>
>> 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?
> As stated, we don't really think supporting CycloneDX is worth our
> effort in the project. That effort would probably be better spent
> making the conversion tools better.
>
> There's not really any documentation why we made this choice, I just
> decided to do it this way when I wrote the implementation. TBH I think
> both formats are technically fine, but SPDX had an edge because of the
> LF connection between the two projects. Gvien that there are
> conversion tools between them, I wasn't really concerned that choosing
> one format of the other would cause problems.
>
>>
>> [1] https://urldefense.com/v3/__https://github.com/spdx/spdx-spec/milestone/3__;!!FbZ0ZwI3Qg!ofUCTG3cuMma5YvThWEwqKVzFJ2AWeMpZT8faPH4PrT-1fujpKm0yyXwYU9fcuvDPHNI0DnNjVqJbtlx0Hc$
>>
>>
>> Appreciate the input,
>>
>> --
>> Alex Stewart
>> Software Engineer - NI Real-Time OS
>> NI (National Instruments)
>>
>> alex.stewart@ni.com
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#176784): https://urldefense.com/v3/__https://lists.openembedded.org/g/openembedded-core/message/176784__;!!FbZ0ZwI3Qg!ofUCTG3cuMma5YvThWEwqKVzFJ2AWeMpZT8faPH4PrT-1fujpKm0yyXwYU9fcuvDPHNI0DnNjVqJtMJ4WK4$
>> Mute This Topic: https://urldefense.com/v3/__https://lists.openembedded.org/mt/96729387/3616788__;!!FbZ0ZwI3Qg!ofUCTG3cuMma5YvThWEwqKVzFJ2AWeMpZT8faPH4PrT-1fujpKm0yyXwYU9fcuvDPHNI0DnNjVqJ4LM7VOA$
>> Group Owner: openembedded-core+owner@lists.openembedded.org
>> Unsubscribe: https://urldefense.com/v3/__https://lists.openembedded.org/g/openembedded-core/unsub__;!!FbZ0ZwI3Qg!ofUCTG3cuMma5YvThWEwqKVzFJ2AWeMpZT8faPH4PrT-1fujpKm0yyXwYU9fcuvDPHNI0DnNjVqJMmHvq8k$  [alex.stewart@ni.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>

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

alex.stewart@ni.com