In our January 2024 mOSS article “Where to next for the SBOM?” we posted about the future with regard to software bills of material (“SBOM”).
Here we want to focus more specifically on the automated formatting tools available to support the compilation, utilization and the usefulness of SBOMs in the supply chain.
Both from a regulatory and a risk management perspective, the incentives for software developers, software vendors and software users for creating, maintaining, supplementing and sharing SBOMs are becoming increasingly clear.
Cyber security and license compliance are front and center but other equally important quality-related topics are being talked about as critical risk ‘identifiers’ which could be worth millions of $$$$ to your organization for example:
end of life components (maintenance no longer provided by vendor)
deprecated software packages (outdated or unsupported components)
so-called “technical debt” (software code produced imperfectly with the expectation of later reworking)
identifiers for export control risk
software with foreign origin or influence (political risk)
AI related data and software risks
The two main SBOM formatting standards, SPDX (a Linux Foundation project) and Cyclone DX (an OWASP project) are not surprisingly in high demand. According to the experts, while they have much in common, each approaches the topic from a slightly different angle, the former being more focused on license compliance, the latter more attuned to cybersecurity.
Is this a problem for interoperability across the supply chain?
If my company is using SPDX as my SBOM tool, how will I manage a supplier whose SBOM has been formatted using Cyclone DX or vice-versa. Do I have to work with both formatting tools so that my systems can easily interpret and use an SBOM whichever format it is contained in? Or, can I simply rely on my Software Composition Analysis tools to paper over any cracks.
It seems that there are ways of converting from SPDX into Cyclone DX and vice-versa but as is often the case in software workarounds there seem to be also certain pre-conditions or complimentary program downloads that are needed to make this conversion happen. For example, there is a utility in GitHub for converting Cyclone DX to SPDX v.2.3, but for this to work (again according to the experts) you need to be running either Docker Desktop or operating in an environment running Java 11+ with Maven.
Even if you are able to convert using your existing computing environment, there is the risk that certain data may be lost. Cyclone DX provides a command line interface tool (CLI) which enables conversion between the two formats. However, this tool maps to SPDX v2.2 rather than SPDX v.2.3. Unlike the SPDX tool mentioned above, the Cyclone DX CLI does not include annotations for items dropped in the conversion.
In any event, you will need to validate the result of your conversion. That said, we came across a GitHub issues list in the CycloneDx/ cyclonedx-cli repository which seems to indicate that the resulting conversions are far from smooth sailing, including one open issue since September 2023 regarding false validation.
Do we really need two standards?
If you are a supply chain professional, sales or procurement manager or you are advising on contracts from a commercial or legal perspective, you may be scratching your head at this point. Surely, one standard throughout the whole supply chain would be preferable in order to avoid:
time and expenditure in adapting the computing environment
misunderstandings as the SBOMs or rather the information contained in them are communicated up and down the supply chain
time spent on checking, validation and trouble-shooting
What happens if, instead of converging, future versions of SPDX and Cyclone DX start to diverge in certain aspects. Both are current and live OSS projects so future releases are to be expected. And as we have indicated in this article the SBOM is not a static thing. The inclusion of additional data and risk identification points within the current SBOM structure, schemas and metadata is more than likely.
Those who are contributing to both SPDX and CycloneDX working groups will have an important role to play as they are uniquely placed to influence the direction of the respective standards but it will be interesting to see how this development plays out globally.
Under the EU Cyber Resilience Act for example, the EU Commission is given the power to standardize formats and elements for the SBOM. How will they seek to exercise this power going forward?
Perhaps the key to unlocking these questions will be Open Chain. Open Chain Project is an open standards project dedicated to improving the way companies manage OSS. They have introduced two ISO standards since 2021: one for license compliance and the other for security assurance. They have regional working groups active since 2019 in Asia (Japan, China, Korea, Taiwan), India and since 2020 in Europe (Germany, UK). Many large global players especially in the automotive and telecoms sectors are promoting these standards. Importantly for SPDX, Open Chain is also housed under the umbrella of the Linux Foundation.
SPDX is evolving quickly. It has a specification V2.2.1 available with accreditation as ISO/IEC 5962:2021, which starts to fill in on implementation level, the Open Chain high level license compliance standard. A next generation SPDX version 3.0 was released recently, though not yet approved as an ISO standard.
In conclusion, as SBOMs mature and as global industry recognition of standards advances, this is a space that needs careful watching.
Your mOSS team
Leave a Reply