Re: Urgent need for SPDX-formatted bill of materials.

Armin Kuster

On 5/18/21 3:02 PM, Richard Purdie wrote:
On Tue, 2021-05-18 at 17:28 -0400, Trevor Woerner wrote:
On Tue, May 18, 2021 at 4:59 PM akuster808 <> wrote:
On 5/18/21 11:32 AM, Trevor Woerner wrote:
I'd like to recommend this be a round-table topic for next week's OE
Developers Meeting?
If meta-doubleopen addresses the issue for folks, what is the topic of
this Round-table?
I'm still investigating and putting together a set of ideas.
I'd like to try and put some guidance around the discussion if I may?
There are a ton of things we could do here but I think the need
is comparatively clear and pressing. Discussions are good where
the outcome is unknown and options need to be explored. I think
some of this is relatively clear for the reasons I'll mention below.

meta-doubleopen says "This meta layer is intended for use with 
Double Open's open source license compliance workflow". *license*
workflow, we're talking about SBOMs. The fact they produce SPDX 
files isn't all that's required to create an SBOM. SPDX is just
a file format. In fact there's nothing in that layer that says 
anything about SBOM. From what I can tell, all meta-doubleopen is 
producing is an SPDX version of the various manifest files one 
would find if buildhistory is enabled.

SPDX is only one of several file formats that can be used to 
generate an SBOM in a standard way. It could be worth a discussion 
to at least mention the others.
Can I suggest we adopt the position that we aim for SPDX unless someone
produces a strong argument that something else has advantages?

The reason I say this is that it is the standard most projects are
consolidating around, it shows alignment with other work at the LF
and SDPX is aiming to become an ISO standard. To do something different
would put us in a difficult position IMO. People complain that LF 
projects don't collaborate enough, here we have an opportunity I want
to make work.

We could look at what an SBOM is, and what are the minimum required 
fields to produce an SBOM.
We do need to find out what the legislation says about this so we can
meet it.
Why? OE nor YP sell to the US Government?  This seems to be more of a
concern for commercial vendors.  They are the ones who need to come to
the table and help support these efforts. Being this is such a new
thing, things will change.  Remember, this is the US Government, just
because the President said this, does not mean each Federal agency will
adopt it for verbatim. 

Another question for the round table: should we integrate this into 
oe-core, or leave it as a separate layer?
We need to be able to say that OE/YP generates SBOM manifests for
images out the box, preferably by default. If we don't do that, we will
lose out to projects which can claim this. I think that makes the 
decision clear.

The round table is also a great way of introducing this important topic
to the community at large. I bet you half the people attending the 
conference have never heard of an SBOM, but might be interested to 
know YP/OE is looking into integrating it into the build system 
especially now that the US government has released an Executive Order 
regarding SBOMs, and that the EU is also looking into these sorts of things as well).

I'll look into inviting the DoubleOpen people to the meeting.

Joshua mentioned that the company he works for is also investigating 
generating SBOMs from YP/OE builds, so let's make sure everyone is 
working on one project, instead of scattering the community.

So there are a couple things we could talk about :-)
I think aspects which do need discussion is how to handle:

* SPDX data at the do_package/do_packagedata level
* SPDX data at the archiver and do_populate_lic level
* whether we can replace existing image manifests
* whether we need tooling to take an SPDX image manifest and process it to 
various forms for end user/tool use (e.g. actual file output or API?).
Transitioning to a more accepted format is something YP/OE should
discuss but don't do it to meet the needs of the US Government.


This probably translates into some kind of plan with different phases.



Join to automatically receive all group messages.