What is a software bill of materials?
With a software Bill of Materials (SBOM), you can respond quickly to the security, license, and operational risks that come with open source use.
A software Bill of Materials (SBOM) is a list of all the open source and third-party components present in a codebase. An SBOM also lists the licenses that govern those components, the versions of the components used in the codebase, and their patch status, which allows security teams to quickly identify any associated security or license risks.
The concept of a software Bill of Materials derives from manufacturing, where a Bill of Materials is an inventory detailing all the items included in a product. In the automotive industry, for example, manufacturers maintain a detailed Bill of Materials for each vehicle. This BOM lists the parts built by the original equipment manufacturer itself and the parts from third-party suppliers. When a defective part is discovered, the auto manufacturer knows precisely which vehicles are affected and can notify vehicle owners of the need for repair or replacement.
Similarly, smart organizations that build software maintain an accurate, up-to-date software Bill of Materials that includes an inventory of third-party and open source components to ensure their code is high-quality, compliant, and secure.
Why do organizations need a software Bill of Materials?
In 2021 there were several high-profile security breaches, including Codecov, Kaseya, and most recently Apache Log4j. These types of supply chain attacks prompted President Biden to issue a cybersecurity executive order (EO) detailing guidelines for how federal departments, agencies, and contractors doing business with the government must secure their software. Among the recommendations was a requirement for SBOMs, to ensure the safety and integrity of software applications used by the federal government.
Although the EO is directed toward organizations doing business with the government, these guidelines, including SBOMs, are likely to become a de facto baseline for how all organizations build, test, secure, and operate their software applications.
Any organization that builds software needs to maintain an SBOM for their codebases. Organizations typically use a mix of custom-built code, commercial off-the-shelf code, and open source components to create software. As one principal architect of a leading software supply chain provider noted, “We have over a hundred products, with each of those products having hundreds to thousands of different third-party and open source components.” A software Bill of Materials allows organizations to track all the components in their codebases.
What’s in a software bill of materials?
An SBOM is a complete inventory of a codebase including the open source components, the license and version information for those open source components, and whether there are any known vulnerabilities in those components.
Open source components
Do your developers use open source components in your code? Open source helps shorten development time, increase speed of execution, and profitably deliver your products to your customers. According to the 2021 “Open Source Security Risk and Analysis” (OSSRA) report, 98% of the codebases scanned contained open source.
Although open source is no more or less risky than proprietary code, failure to adequately secure it introduces greater risk to your organization’s overall security. Few companies have much visibility into the open source they use, and even fewer can produce an accurate, up-to-date software Bill of Materials that includes open source components. A comprehensive SBOM lists all open source components in your applications as well as those components’ licenses, versions, and patch status.
Open source licenses
Do you know whether the licenses for the open source components your applications are permissive or viral? Are you using one of the top open source licenses or a one-off variant?
Failure to comply with open source licenses can put businesses at significant risk of litigation and compromise of intellectual property (IP). Over 65% of the codebases audited in the OSSRA report contained open source software license conflicts, which typically involved the GNU General Public License. These conflicts can lead to serious implications with mergers and acquisitions, vendor disputes, and distribution problems. A software Bill of Materials lists the open source licenses that govern the components you use, allowing you to pinpoint and assess your legal and IP risk.
Open source versions
Do you know whether the open source components in your codebase are being maintained? Operational risk can be introduced when teams use outdated components, components with no recent development activity, or components from projects without a sufficient developer community to maintain the code. Aside from poor code quality, reliability, and maintainability issues, operational risk can also lead to security risks. If there are no developers finding and fixing bugs, there are no developers finding, disclosing, and fixing security defects, making it an easier target for threat actors. An SBOM provides a list of the versions of open source components in your code, which can be used to help determine whether you’re using any outdated, potentially insecure code.
Open source vulnerabilities
Do you know whether the open source components you’re using have any known vulnerabilities? The OSSRA report found that 84% of the 1,500 audited codebases had at least one public open source vulnerability. Only a handful of open source vulnerabilities—such as those infamously affecting Apache Struts or OpenSSL—are ever likely to be widely exploited. But when such an exploit occurs, the need for open source security becomes front-page news, as it did with the Equifax data security breach of 2017. A major contributing factor to Equifax’s breach was the company’s lack of a comprehensive IT asset inventory—in other words, an SBOM. “This made it difficult, if not impossible, for Equifax to know if vulnerabilities existed on its networks,” a report on the incident concluded. “If a vulnerability cannot be found, it cannot be patched.”
At the end of 2021, Log4j served as another lesson that highlighted the importance of having an SBOM. Once the vulnerability was disclosed, it was a race to implement patches before malicious actors could exploit them. In a situation where every second counts, having a software Bill of Materials can help you quickly identify and assess risks in your codebase.
How do I get a software bill of materials?
A powerful software composition analysis (SCA) tool such as Black Duck® can generate a complete open source SBOM, and even offers the ability to include third-party and custom components. Most importantly, SCA tools can provide this information on a continuous basis, ensuring that you have the most up-to-date picture of your open source risks.
Given that open source is an essential component of application development today, every software development team should use an effective SCA tool to inventory the open source and third-party components in their code.
Maintaining a software Bill of Materials is vital if you want to respond quickly to the security, license, and operational risks that can accompany open source software use.
This post was originally published November 14, 2019, and refreshed March 16, 2022.
*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Fred Bals. Read the original post at: https://www.synopsys.com/blogs/software-security/software-bill-of-materials-bom/
