Why OWASP’s CycloneDX will make you fall in love with SBOMs

It’s well-established: Triple-DES is a feeble encryption algorithm. 

In 2016, researchers successfully exploited Triple DES' short block size (CVE-2016-2183) — i.e.,  how many  bits are processed together — in various real-world protocols via a birthday attack called Sweet32. Known officially as the Triple Data Encryption Algorithm, Triple-DES was deprecated in 2018 and, per the National Institute of Standards and Technology (NIST), will be verboten after 2023. 

... All of which is to suggest that, when it comes to securing the software supply chain, it would be helpful to know who’s still using Triple-DES or other limp algorithms that fail to prevent brute-force attacks. And with the upcoming release of CycloneDX 1.6 and its introduction of a cryptography bill of materials (CBOM), that will finally be possible. 

OWASP is pounding out quality SBOMs

The CBOM is just one example of what  the Open Worldwide Application Security Project  (OWASP) — which maintains the CycloneDX project — is doing to ensure that Software Bills of Materials (SBOMs) are a helluva lot heartier, deeper, broader and more useful than the software equivalent of the ingredient label on a can of soup. After all, as Contrast Security CTO and co-founder Jeff Williams often puts it, just knowing what ingredients went into a bowl of soup won’t prevent you from getting food poisoning if you eat it. Likewise, just because software incorporates a component with a known vulnerability doesn’t mean that it poses an Application Security/application programming interface (AppSec/API) risk, given that much depends on how, and if, that component is actually invoked. 

CycloneDX 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 coding practices were used to cobble the bits and pieces together, nor whether potentially vulnerable globs of it are ever even invoked by the application. 

Right now, CycloneDX is one of the most popular standards for describing the components of an application, including source code binaries, libraries and containers. With the latest release of the specification — version 1.5 — OWASP expanded it even further to encompass hardware operations, manufacturing and artificial intelligence. The upcoming cryptography BOM is just one of a slate of new BOMs that promise a far more comprehensive SBOM experience, and we can expect even more in version 1.6. 

We recently invited Steve Springett, chair of the OWASP CycloneDX core working group, to chat with us about the changes introduced in CycloneDX 1.5, what they mean for software transparency and what’s coming down the pike in the upcoming release. That includes the CBOM, which will address whatever wonky cryptography gristle — like Triple-DES — is going into the software soup. 

It also includes a manufacturing BOM — the MBOM — for software that can describe the recipe for how something should be created, versus what actually transpired in the kitchen/software development process. “When it comes to identifying potential risk in components that we either create or consume from others, knowing how something was built is truly important,” Steve said during our Code Patrol podcast chat. 

An example of how that will matter is SolarWinds, the 2020 supply-chain attack on approximately 18,000 purchasers of the company's Orion software.

“That was not a vulnerable component,” Steve points out. “That was a vulnerability in the pipeline that existed that then affected the software delivery itself. And if they had captured the manufacturing bill of materials, if this had been a thing at that time, they could have potentially used that data to identify a potential gap, a potential weakness in their build pipeline and could have proactively put measures in place to to remove that gap. So we thought manufacturing bills of materials were truly important for transparency.”

Decreasing the chances of a devastating software supply chain attack such as SolarWinds is a laudable goal, and OWASP contributors deserve our gratitude for the hours they’ve contributed to the CycloneDX project in the work to achieve that and other software security goals.

If you’d like to contribute to the CycloneDX project, you can sign up here. 

Listen to the podcast to hear more about the current release of CycloneDX — CycloneDX 1.5 — and to find out more about what’s coming in Version 1.6. 

Read more:

• The five dimensions of SBOM quality
• Click here to participate in OWASP's CycloneDX project
• Securing the software supply chain starts with a Software Bill of Materials (SBOM)
• It’s SBOM time!
• Gartner Report: Innovation Insight for SBOMs