CycloneDX 1.5: The missing link in SBOMs and software transparency?

CycloneDX — one of the most popular standards for describing the components of a software application, including source code binaries, libraries and containers — was created because modern software is a glued-together glob of third-party and open-source components that are rigged up “in complex and unique ways and integrated with original code to achieve the desired functionality,” as OWASP explains. 

The situation as it currently stands: Software is a black box. Lord knows what those components are, nor whether secure processes were used to cobble the bits and pieces together, nor whether potentially vulnerable bits are even invoked by the application. There’s no manufacturing bill of materials to tell you how it was cooked up. There’s no cryptography bill of materials telling you if software employs feeble encryption algorithms — such as the soon-to-be-verboten Triple-DES, enabler of brute-force attacks. 

All of this is why the Office of Management and Budget is requiring government agencies to collect cybersecurity attestations from the software providers whose services they use, and why OWASP is working to fill in all the blanks with a growing menu of Software Bill of Materials (SBOM) types. 

In this episode, Steve Springett, chair of the OWASP CycloneDX core working group, talks about the changes introduced in CycloneDX 1.5, what they mean for software transparency, and what’s coming down the pike in the upcoming 1. 6 release. A teaser: One thing we can look forward to is the Cryptography Bill of Materials (CBOE), which will address whatever wonky cryptography gristle — like Triple-DES — is going into your software soup. 

Episode source