Large-scale supply chain attacks have become a huge challenges for information security professionals. The past three years has seen a staggering 742% surge of supply chain attacks , according to cybersecurity firm Sonatype.
To evolve software supply chain security, organizations should start by using the tools the open source community offers, said Thomas Steenbergen, head of the open source program office (OSPO) at EPAM Systems, during the State of Open Con 23 conference. This includes when developing software bills of materials (SBOMs).
The first occurrence of an SBOM requirement was seen in US President Joe Biden’s May 2021 executive order on Improving the Nation’s Cybersecurity, published in response to the SolarWinds supply chain attacks in late 2020.
Since then, other countries have started to follow suit. For instance, the UK has suggested introducing “requirements in government procurement [such as] accredited software vendors [and] SBOMs” in their Call for views on software resilience and security for businesses and organisations, published on February 6, 2023.
“Now, government agencies are starting to translate these principles into more actionable requirements, and the talks have expanded outside federal and national supply chains. The private sector is also looking into it,” noted Rao Lakkakula, executive director at JPMorgan Chase.
The issue with SBOMs, Lakkakula continued, is that “although it could look like an ingredient list for a chocolate bar, in real life, where organizations rely on so many software dependencies, which are themselves based on other dependencies, producing SBOMs is closer to making a list of ingredients for a box of boxes of chocolates.”
Another problem in producing SBOMs, Steenbergen argued, is that “it’s too often an afterthought.”
“We need to build SBOMs upstream to automate those lists so that they come directly from the package manager,” he added.
Open Source, The Way to Go for SBOMs
While it’s difficult to do this for the software provided by vendors, tools exist to produce automated SBOMs for open source software – representing 90% of modern software applications, according to Snyk. Steenbergen presented one of them, the Open Source Software Review Toolkit (ORT), during a State of Open Con session.
ORT is an open source software policy automation and orchestration toolkit that Steenbergen and other OSPO representatives started working on back in 2015. It offers scanning tools for software licenses and security (software vulnerabilities, patches…), provides best practices based on company standards and InnerSource, a software development strategy that applies open source practices to proprietary code and can be used to produce SBOMs.
“In terms of producing perfect SBOMs, we’re not there yet, but it’s good that countries start asking for minimal requirements of SBOMs even if they’re still very incomplete because it’s a first step forward. Are they useful? Probably not, but it’s a leap towards functioning ones – and we’re coming a long way from paper-based processes, with a different format for nearly every provider. It’s a journey, and we’re moving forward,” Steenbergen told Infosecurity.
“We’re past the awareness stage, getting somewhat good at producing SBOMs, and working to make them upstream. So, for that, I think open source SBOMs is the way to go.”
The next step, he continued, will be “the consuming side of SBOMs, still in its infancy.”
Among the challenges to overcome in that area are twofold. First, the need for a standard vulnerability exploitability exchange (VEX), a system used to give security advisories for each package – “there are at least four such initiatives in parallel,” Steenbergen recalled. Second, the need for a test suite that links the code to a line in an SBOM. “Today, if you give the same software package to multiple SBOM tools, you will get very different results,” Steenbergen noted.