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


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



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




Thomas Steenbergen