Re: [spdx-tech] Should SPDX endorse SCA tools?


Kate Stewart
 

We've got a lot of historical cruft in our SPDX repo as well.  Coming up with some criteria for inclusion & removal is overdue.

After we settle the 3.0 template issue,  you up for dedicating part of a call to sketch out the repository inclusion criteria?  Then we'll do an assessment/clean up pass. 

Thanks, 
Kate


On Tue, Jun 29, 2021 at 1:29 PM Thomas Steenbergen <opensource@...> wrote:

Hi,

 

Continuing the discussion in today’s SPDX Tech call here on “Should SPDX endorse SCA tools?” - so other people in the SPDX community get the opportunity to share their opinion.

 

Following  Software Bill of Materials (SBOM) Industry Standard, Research, Training, and Tools to Improve Cybersecurity Practices announcement, I got the feedback form within my network asking me about the “official” SPDX SCA* tool (spdx-sbom-generator) – some project/technical question and remarks about the quality of the SBOM it produces.

 

I then realized that as spdx-sbom-generator is hosted on spdx GitHub org one can see it as an endorsement from SPDX. In OpenChain community, who also develops it specification, a deliberate choice was made to not endorse any tools as I was told a specification should be tooling neutral to facilitate broad adoption and healthy tooling ecosystem supporting the specification.

 

I think it may be a good idea for SPDX to do the same, as it’s possible to validate a SPDX SBOM per the specification but we cannot easily validate if SBOM is actually a good representation of reality.

Most build tools are meant to build code and do not to produce an SBOM.  As a result, SCA tools on the market generally do a best effort approach and thereby miss OSS or get OSS license or metadata wrong.

 

Let me know what you think.

 

* SCA = Software Composition Analysis

 

Regards,

 

Thomas Steenbergen

 

 

 

 

 

 

 

Join spdx@lists.spdx.org to automatically receive all group messages.