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 2022 “Open Source Security Risk and Analysis” (OSSRA) report, 97% 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 signiﬁcant 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.”
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.