4 Reasons Software Developers Need a Bill of Materials

The recent Log4j/Log4Shell vulnerability was a wake-up call that threats aren’t going to wait until the industry gets up to speed on software supply chain security. While the Log4j open source component vulnerability caught us all off guard, it did highlight the need for software vendors to be more proactive in disclosing the composition of their products. It’s become painfully clear that analyzing open source libraries and third-party code should become standard practice to understand their makeup and the potential risks they introduce in commercial software applications.

Unfortunately, relying on open source projects to provide visibility into security vulnerabilities isn’t going to work. In most cases, these projects are grossly underfunded. At the time of the Heartbleed vulnerability, for example, OpenSSL received very little funding. Yet, open source usage increases each year. It’s imperative that commercial software organizations contribute to open source projects they use and share responsibility for the security of these products.

In addition to open source libraries, most vendors source third-party code from contractors or for-hire development organizations. Without documentation of the composition of the code developed by third parties, it’s impossible for commercial software vendors to proactively identify and manage risk before it’s implemented in their development cycle.

Using Software Composition Analysis (SCA) Tools

Where a software bill of materials (SBOM) is not provided, the onus should be on commercial software vendors to create one. This can be accomplished using software composition analysis (SCA) tools that analyze binaries and do not require access to source code. They can generate SBOMs to identify open source or third-party components in use, as well as track and manage security risks in the software supply chain.

Creating a comprehensive SBOM provides other benefits, since most open-source projects and contract developers are only likely to publish direct dependencies (if at all) and not look further into the dependencies of dependencies, and so on.

Four Benefits to Consider

Meanwhile, commercial software vendors can expect their customers to soon start demanding SBOMs since this will be a requirement under the cybersecurity executive order. Given this evolving landscape, commercial software vendors should consider the following four benefits for proactively implementing an SBOM program to govern the products they build:

  • Gain visibility into software supply chain risk to identify, reduce and remove vulnerabilities in reused software (ie open source and third-party). SBOMs provide data for business decisions on the software you have reused and purchased. It’s better to discover these risks before your customers do.
  • Preemptive supply chain qualification to ensure compliance with future requirements. SBOMs will soon be a requirement for doing business with the US federal government. Suppliers that meet the SBOM requirements during procurement will be given preferential treatment.
  • Improved security and downstream benefits that come with risk management and mitigation. Avoiding, detecting and remediating security risks before they become embedded in a product pays huge dividends during development and deployment. You’ll be better prepared for the next security event.
  • Common understanding of software assets that comes with a standardized SBOM shared amongst developers, suppliers and open source projects. An SBOM becomes a way to communicate software contents and dependencies within and outside an organization.

Taking a proactive approach to the software supply chain by creating SBOMs and demanding the same from suppliers will enable commercial developers to be better prepared for the next Log4j/Log4Shell vulnerability. It will also allow them to improve the software supply chain security posture of their end customers.

Leave a Comment