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?
High-profile security breaches like Codecov, Kaseya, and most recently Apache Log4j - all 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. CISA recently released their secure software development attestation form; any providers of software for use in critical infrastructure have 90 days to provide a completed form, and all other providers of software to the U.S. government have 180 days to do the same.
eBook
Five considerations for securing your software supply chain
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 2024 “Open Source Security Risk and Analysis” (OSSRA) report, 96% 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 53% 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 81% of the 2,400 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.”
Vulnerabilities like Log4j serve as another lesson that highlight the importance of having an SBOM. Once severe vulnerabilities like Log4j are disclosed, it is a race to implement patches before malicious actors can 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 blog was fact checked by Mike McGuire.
Continue Reading
.jpg)