Software developers could soon be required to document every component their applications contain, as companies increasingly demand to know what’s in the ‘secret sauce’ that makes software work – and exposes them to cybersecurity breaches.

Spearheaded by Dr Allan Friedman, director of cybersecurity initiatives at the US Department of Commerce’s National Telecommunications and Information Administration (NTIA), the ongoing NTIA Software Component Transparency project is refining a software bill of materials (SBOM) standard that will normalise the listing and exchange of software developers’ recipes.

“Everyone knows someone who has a food sensitivity or dietary restriction,” Friedman explained during the recent Consortium for Information & Software Quality Cyber Resilience Summit, “and the goal [of food labelling] is to empower them with the information to make the right risk based decision for themselves.”

“It’s crazy that we don’t have that for software.”

In 2014, the Heartbleed bug exposed millions of users of a common encryption library to potential compromise. And earlier this year, discovery of a cluster of vulnerabilities, known as Ripple20, saw makers of Internet of Things (IoT) devices warned that vulnerabilities in a commonly used communications stack could expose millions of devices to compromise.

SBOMs’ profile has increased in recent years as cybersecurity specialists come to grips with the vulnerabilities developers introduce by tapping open-source software (OSS) components to build their own applications.

A reported 96 per cent of enterprise applications use open-source software, with elements ranging from user interface components, encryption libraries and computational algorithms to entire databases and artificial intelligence tools.

Yet OSS vulnerabilities increased by 130 per cent last year alone – with some 968 specific vulnerabilities documented – and continuing growth in 2020 suggests that trend is only getting worse.

The 50 most popular OSS projects contain more than 2,600 known vulnerabilities, a May analysis by RiskSense found, while the recent Snyk State of Open Source Security report noted that commonly used OSS libraries like npm, Ruby, and Java were spawning hoardes of new vulnerabilities.

Fully 85 per cent of users blame developers for the introduction of OSS security issues, that survey found – but yet other survey results suggest that less than half of organisations actually have the ability to produce a SBOM showing where those issues might be.

Widespread adherences to a formal SBOM standard could see government and private-sector organisations demanding SBOMs from suppliers, as they work to contain their exposure to third-party risks they may not even know about.

“This stuff is buried there,” Friedman said, “and the goal is to make sure that those that are responsible for defending those networks, know where it is.”

In it to win it

A proposed 2014 US law, the Cyber Supply Chain Management and Transparency Act of 2014, emerged from the Heartbleed panic and would have forced government agencies to obtain SBOMs for all of their software.

That bill didn’t pass, but it did spur the development of SBOM standards for IoT, medical devices and other devices – as well as fostering an industry around source code scanning tools, and formalisation of operational models like the OWASP Software Assurance Maturity Model (SAMM).

Australian departments don’t have SBOM requirements, although the Department of Home Affairs recently released an “encouraged but optional” IoT Code of Practice intended to improve IoT device security.

There are signs that SBOM could rapidly hit the mainstream – with Gartner predicting that by 2024, providing a detailed SBOM will be a “non-negotiable requirement” for more than half of enterprise software buyers – up from less than 5 per cent last year.

NTIA’s SBOM project has expanded in scope over several years, with nearly 200 participants worldwide having achieved “some consensus around what an SBOM is,” Friedman said, noting that the effort had evolved into focusing on making sure the solution is machine readable, scalable, and modular.

A recent meeting, for example, explored evolving guidelines around exchanging SBOMs, challenges in identifying software, specific considerations for healthcare providers, and efforts to better convey the vulnerability exploitability (VEX) of a particular weakness.

Cross-industry participation had given the SBOM effort broad relevance, Friedman said, as the standards team worked to keep the standard “tight and lightweight, in a fashion that really brings together the entire community.”

“This is not about government regulation or source code disclosure,” he added, “and it’s not just about embedded software or commercial software.”

“We need to capture the entire supply chain – and once we have that, we can build a lot of other great tools on top of that.”