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