With an average of 500 components in an application, it’s difficult to know what’s in your software. The right security tools and expertise are here to help.
A software Bill of Materials (SBOM) is an inventory of what makes up a software application: the “ingredients list” of everything in it. There’s pressure today for companies to make SBOM information available, and it has implications for who is liable when there are issues in the software.
A food analogy is apt. When you read the ingredients list of chocolate chip cookies, you will see flour, sugar, butter, chocolate chips, eggs, vanilla, baking soda, salt, etc. But within those chocolate chips is a subinventory ingredients list—chocolate chips contain sugar, chocolate, cocoa butter, nonfat milk, milkfat, and soy lecithin.
What if somehow there were tainted cocoa butter in the chocolate chips and a recall needed to be placed on any product including this cocoa butter? Who is responsible, and how are customers protected from eating bad cookies? It’s important that the cookie company be aware of its ingredients—but also those used by its suppliers.
Just as chocolate chip cookie manufacturers are responsible for the ingredients in their cookies, software manufacturers need to know the components within their software applications, to protect themselves and ultimately to protect the end user from “eating bad cookies”—that is, using components that may be tainted with security vulnerabilities or software licensing issues.
President Biden’s Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity was issued on May 12, 2021. This bellwether put SBOMs at the forefront of software procurement practices. The EO will make SBOMs required for any company wanting to sell software to the U.S. government, and this requirement will likely bleed over into the commercial sector as well.
An SBOM is living document, and vendors will need to keep them up-to-date. With each newly identified software vulnerability, software vendors will be asked, “What did you know? When did you know it? And how fast did you fix it?” These are the exact questions Equifax’s CEO fielded in front of Congress after that company’s well-publicized data breach based on a vulnerability in an unpatched open source component.
As with most new processes, there are challenges. One challenge with SBOMs is the number of variables in software applications. Another is that an SBOM should both identify components and use a standard nomenclature for each identification. Communities and ecosystems will need to work collectively on the standards, processes, education, and tooling to mitigate risks to global supply chains.
Fortunately, we already have some SBOM standards and tools to implement stronger software security practices throughout supply chains. Standard SBOM formats such as Software Package Data Exchange (SPDX) and CycloneDX help companies more easily exchange the information, thus building trust and transparency in how software is created, distributed, and consumed throughout supply chains.
Last year SPDX became one of the standard formats for SBOMs as noted in ISO/IEC JTC1 5962:2021, which is an international open standard for security. SPDX already plays an important role in software security and integrity across some of the world’s largest commercial supply chains. Companies like Hitachi, Samsung, Microsoft, Intel, Cisco, Siemens, Google, and many more have already been producing and consuming SPDX SBOMs for years.
And yet, the SBOM market is still immature. Standards help companies exchange the information, but how to use and track that data remains a challenge. And the completeness and accuracy of SBOMs must also be addressed. The SBOM for the chocolate chips better include the cocoa butter or someone is going to be in trouble.
In conducting research for our most recent Open Source Security and Risk Analysis (OSSRA) report, we discovered the average application contained around 500 software components. The complexity of tracking all the components that make up an application requires an automated software composition analysis (SCA) tool. Black Duck® SCA from Synopsys makes it easier for users to secure their software supply chain by enabling them to quickly build and export SBOMs in formats such as SPDX and CycloneDX.
And if you are new to building an SBOM and plan to generate one internally, you may want guidance from an SBOM expert regarding what applications should be included in your inventory. Synopsys SCA tools and SBOM generation services have been leading the market for two decades. Our experts can provide guidance on building trust in the completeness and accuracy of the SBOMs your company is producing or receiving from vendors so that you know you are protected when the cookie crumbles.
Julie Courtnay has supported technology customers since 2004 in industries ranging from the design and verification of semiconductors, to storage, to high-performance computing, to software due diligence. She has advised on over 400 software audits. When not supporting her customers, Julie loves to ski, hike, play tennis, and read.