Support for SPDX BOMs

[jblu42]

After reading this, I know this might be a sensitive topic
#1053

But I am currently having the problem that SPDX is on the way of getting the major SBOM format in my company, because of several reasons:

• It recently became ISO standard (ISO/IEC 5962:2021)
• The SBOM Topic is mostly driven by Open Source Compliance
• The major tool used to manage Open Source compliance only offers import / export SPDX BOMs

As the usage of SPDX will not go away this leaves me with this alternatives:

• Find an alternative to Dependency Track
• Convert SPDX to CycloneDX for Dependency Track
• Maintain two different SBOM formats (which will cause sync problems)

I am interested how this is handled for other people using dependency track and SBOMs, does anybody else having these problems? Are there any suggestions how to solve this?

As the removal of SPDX is politically driven not technically I am asking you to consider this decision which is imparing the usage and interoperability of Dependency Track.

[stevespringett]

It recently became ISO standard (ISO/IEC 5962:2021)

ISO now has two SBOM standards that cannot achieve the majority of cybersecurity use cases today. CycloneDX is an OWASP standard that achieves the majority of cybersecurity use cases and supports the most widely requested license use cases.

The SBOM Topic is mostly driven by Open Source Compliance

SBOM is driven primarily by cybersecurity use cases, not legal ones. If license use cases were not possible, SBOM would still be a requirement of Executive Order 14028. The NTIA minimum elements for SBOM do not contain any fields related to license, but do contain identity fields used for vulnerability analysis use cases including purl, CPE, and SWID. If your organization is driving SBOM adoption purely based on license requirements, that's an interesting situation and not representative of the software industry as a whole.

The major tool used to manage Open Source compliance only offers import / export SPDX BOMs

That's unfortunate. Most open source and commercial security tools that support SBOM, support CycloneDX. Some also support SPDX. It's not until you get out of the security industry and into license/IP specific tools that SPDX becomes the predominate format. It should be noted however, that CycloneDX SBOMs can be used as an OpenChain compliance artifact. So it's in that tools best interest to support CycloneDX.

Find an alternative to Dependency Track

There are a few open source and commercial tools available that are starting to compete with Dependency-Track. Competition is good. However, DT has been around since 2013 and these newer tools have a bit of catching up to do, which they eventually will. NCSC (Netherlands) refers to Dependency-Track as a reference implementation for SBOM cybersecurity use cases. So it may be difficult to find a replacement that can achieve what DT does today, but in time, there will be many options available.

Convert SPDX to CycloneDX for Dependency Track

That's possible, although, I haven't seen any good tools that do this. An alternative may be to standardize on CycloneDX because the CycloneDX CLI can export into SPDX 2.1 and 2.2 formats. We realize there's legacy tooling that only supports SPDX file formats, so the CLI supports them to make interop more accessible.

As the removal of SPDX is politically driven not technically ...

Removal of SPDX was expedited by LF behavior and plagiarism. Removal of SPDX was already planned as the standard does not support any of the use cases that DT is advancing in the v4.x series. If you refer to the DT 4.0 Preview video on YouTube, DT 3.x was about trying to achieve SCA-like things with SBOMs and not relying on SCA. This was a huge success and had never been done before. DT v4.x is about doing what SCA cannot achieve. So we're focused on services, have implemented and will be advancing SWID, will be integrating with ZAP for DAST analysis of services defined in SBOMs, will be versioning SBOMs based on changes, better supporting hardware, dynamically creating dataflow diagrams for threat modeling, etc, etc, etc. None of these are remotely possible with SPDX. It didn't make sense to drag along a format that cannot achieve any of these use cases today. So removal was already planned, but was certainly expedited by their own actions.

On a purely technical level, SPDX supports external references. These are essentially aliases of what a component is identified as. It supports multiple Maven coordinates, multiple purls, multiple CPEs, etc. This isn't possible in the real world. A component can only have a single identity. If you change that identity, you change other information about that component (e.g. changing a Maven coordinate alters the hash value of that component). Unfortunately, SPDX cannot state what something is, only what something could be. It does this though supporting zero or more external references of every component. This is an interesting capability but not a feature you'd want in a bill of materials format. The Dependency-Track project also removed support for importing Dependency-Check XML reports a long while ago - for the same reason. Any file format that relies purely on evidence rather than stating factually what a component is, isn't a good fit for Dependency-Track.

[dalibor-antovski]

I understand that that this is "fight between rivals", but I see this very unfair towards users/customers. GitHub as one of the most used Git platform supports export only SPDX, and DT supports only import of CycloneDX, great job! I accept your answer, but even if CycloneDX have advantages, why not to give a customers choice to decide? Same is valid for GitHub. :(

[stevespringett]

@antovski refer to #1746

[jblu42]

Thanks for your very detailed and comprehensive answer. I will accept this as an answer although I am still not happy with the outcome of removing SPDX.

We currently decided to keep Dependency Track and chose my least favorite option of doing SBOM in two different formats, so we will keep SPDX and also create CycloneDX exclusively for DT. At least they are based on the same data source, so I hope we can minimize any side effects.

As for the driver for SBOM, I think in most larger companies there is an even stronger driver than security and that is (legal) compliance.

In your linked documents for the executive order, I cannot find any reference, that security fields like PURL or CPE are a requirement, the possible SBOM formats that are listed include SPDX, CycloneDX and SWID. Only the identification of the software by name and version are the most important fields and that should be fulfilled by all three formats. This is how Microsoft fulfills the requirement by SPDX:

https://devblogs.microsoft.com/engineering-at-microsoft/generating-software-bills-of-materials-sboms-with-spdx-at-microsoft/

As a security person I see the value in CycloneDX, but being a standard now this will drive SPDX adoption. The best thing to hope for as a user is, that the product will support both formats, but then there will be products only supporting one (like DT) which makes adoption of SBOM harder in the end.

[stevespringett]

The Executive Order defers to NIST to define the technical requirements. However, NIST defers to their sister agency, NTIA, to define the minimum elements of an SBOM. The document that mentions PURL and CPE is published here: https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf

Keep in mind that SPDX 2.2 is what the ISO standard is for, and SPDX 2.2 does not support the majority of security use cases. Work is ongoing for SPDX 3.0 which adds a few new security use cases. SPDX 3.0 will not automatically be an ISO standard. They need to go through the standardization process again for that to happen. If SPDX 3.0 becomes a widely used SBOM standard used for security use cases, I'd be happy to reevaluate SPDX 3.0 support. However, I think translation tools will mature by that time and provide the necessary bridge.

[SihuiHu6]

Has supported SPDX BOMs now?

[sschuberth]

You might want to track #1746.