Supply chain management isn’t new, yet software development tends to lag in terms of best practices compared to other industries. The bill of materials concept (BOM) can be traced to W Edwards Deming’s work in manufacturing quality improvement, where it is used to track the source of each part to locate the producer in the event of a quality issue. The BOM is central to managing manufacturing processes for complex products and keeping track of parts, part numbers, lot numbers, dates and manufacturers.

Deming defined 14 principles for transforming businesses, which apply to all industries, including software. One, in particular, is especially relevant to software security:

“Avoid the need of mass inspections by developing a quality product right from the beginning of the chain.”

In addition, Deming emphasized the need to train and educate suppliers on quality. “Improve leadership and training among the members of the supply chain and involve active participation of each one of them. Break the barriers among the members of the chain and educate them in developing and maintaining high quality of the product throughout the supply chain.”

Evolution of the SBOM

Although it’s unclear when the first use of the phrase “Software Bill of Materials” occurred, it can be traced back to at least 1997. At the time, it was described as “files to be shipped as part of a release as described in a special file within the release called an SBOM.” This was in the context of configuration management and didn’t consider third-party code nor open-source dependencies at the time.

Over time, the importance of SBOMs grew with concerns over meeting the obligations of open-source software licensing agreements. The first GPL violation lawsuit was filed in the United States in 2007 against Monsoon Media by the developers of the open-source BusyBox project. The ruling forced Monsoon Media to compensate the developers and release the source of their modified version as required by the GPL.

Since then, software composition analysis with an emphasis on creating SBOMs to catalog software licenses has been used to minimize legal risk for non-compliance. The most common way to create an SBOM is using software composition analysis (SCA) tools.

The application of SBOMs to cybersecurity took root around 2013 when OWASP included “A9: Using components with known vulnerabilities” in their Top 10 list of vulnerabilities.

Meanwhile, US Federal legislation related to SBOMs, and the need to secure the software supply chain, go back to the Cyber Supply Chain Management and Transparency Act of 2014, which was introduced but not passed as a bill “To ensure the integrity of any software, firmware, or product developed for or purchased by the United States Government that uses a third party or open source component, and for other purposes.” It was ahead of its time, with the recent Executive Order on Improving the Nation’s Cybersecurity coming seven years later.

This 2014 Act states that the US government “shall issue guidelines for each agency that require including the following clauses in any contract for the acquisition of software, firmware, or product that contains a binary component: (A) Component list.—A clause that requires the inclusion of a comprehensive and confidentially supplied list, or a bill of materials, of each binary component of the software, firmware, or product that is used in the software, firmware, or product.”

Clearly, the necessity for an SBOM and tracking suppliers was known well before the current software supply chain situation.

Even when source code isn’t available, SCA tools that perform binary analysis can help organizations understand the SBOM contained in applications they buy and use and identify any security vulnerabilities associated with each component. For example, many organizations want a risk or vulnerability assessment of packaged or commercial off-the-shelf software (COTS) they deploy. This proactive approach to managing risk is gaining momentum due to work from home and other digital transformation initiatives.