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<https://www.linuxfoundation.org/press-release/linux-foundation-announces-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<https://github.com/spdx/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<https://github.com/spdx/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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4093): https://lists.spdx.org/g/Spdx-tech/message/4093 Mute This Topic: https://lists.spdx.org/mt/83875398/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
