Software Bill of Materials (SBOM) is a list of all open source and third-party components included in a code base. The Software Bill of Materials allows you to quickly respond to security, licensing and operational risks in the case of open source use.
SBOM also lists the licenses for these components, the versions of components used in the codebase, and the status of fix patches, allowing security teams to quickly identify associated security or licensing risks.
Software Bill of Materials (SBOM) is a list of all open source and third-party components included in a code base. SBOM also lists the licenses for these components, the versions of components used in the codebase, and the status of fix patches, allowing security teams to quickly identify associated security or licensing risks.
The concept of Software Bill of Materials is derived from the detailed inventory of all items incorporated into a product in industrial production. For example, in the automotive industry, manufacturers maintain a detailed bill of materials for each vehicle. This bill of materials lists parts manufactured by the original equipment manufacturer itself and parts from third-party suppliers. When a faulty part is discovered, the automaker knows exactly which vehicles are affected and can issue a recall to vehicle owners for repair or replacement.
Similarly, smart organizations that develop software maintain an accurate, up-to-date software BOM that includes an inventory of third-party and open-source components to ensure their code is high-quality, compatible, and secure.
There have been several high-profile security breaches in 2021, including Codecov, Kaseya, and most recently Apache Log4j. Such supply chain attacks prompted US President Biden to issue a cybersecurity executive order (EO) with detailed guidelines on how federal departments, agencies, and contractors doing business with the government should secure their software. Among the recommendations was a requirement for SBOMs to ensure the security and integrity of software applications used by the federal government.
While the Cybersecurity Executive Order is intended only for organizations doing business with the government, these guidelines, including SBOMs, will become the de facto foundation for how all organizations build, test, secure, and operate software applications.
Every organization that develops software is required to maintain an SBOM for their code base. To build software, organizations often use a mix of custom-made code, commercial off-the-shelf code, and open source components. As one chief architect at a leading software supply chain provider put it, “We have over a hundred products, and each of those products has hundreds, even thousands, of different third-party and open-source components.” A software Bill of Materials allows organizations to keep track of all components in their code base.
SBOM is a complete inventory of all open source components of a code base, the license and version information of these open source components, and known vulnerabilities in these components.
Do your software developers use open source components in your code? Open source helps reduce development time, increase execution speed, and deliver your products profitably to your customers. According to the 2021 “Open Source Security Risk and Analysis” (OSSRA) report , 98% of scanned code bases contain open source.
While we can’t say that using open source is any more or less risky than proprietary code, we can say that failure to secure it adequately will pose more risks 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 bill of materials containing open source components. A comprehensive SBOM lists all open source components in your applications, as well as their licenses, versions, and status regarding patches.
Do you know whether the licenses for open source components of your applications are permissive or viral? Are you using one of the best open source licenses or a one-off variation?
Failure to comply with open source licenses can expose businesses to significant risk of litigation and intellectual property theft (IP). More than 65% of the code base audited in the OSSRA report contained open source software license conflicts, often involving the GNU General Public License. These conflicts can lead to serious impacts through mergers and acquisitions, vendor disputes, and distribution issues. At this point, a software Bill of Materials allows you to fully identify and assess your legal and IP risk by listing the open source licenses of the components you use.
Do you know whether open source components in your codebase are protected? Operational risk can arise when your teams use outdated components, components with no new development activity, or components that lack an adequate developer community to maintain the code. Besides 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 bugs, making it an easier target for threat actors. SBOM provides a list of versions of open source components in your code that can be used to help determine if you are using any outdated, potentially unreliable code.
Do you know if the open source components you use have any known vulnerabilities? The OSSRA report revealed that 84% of the 1,500 code bases audited had at least one open source vulnerability. Only a handful of open source vulnerabilities can be widely exploited, such as the infamous Apache Struts or OpenSSL. But when such an exploit occurs, the need for open source security becomes front-page news, as in the Equifax data security breach of 2017. A major contributing factor to Equifax’s breach was that the company did not have a comprehensive inventory of IT assets, in other words, it did not have an SBOM. “This made it difficult, if not impossible, for Equifax to know if there were vulnerabilities in their network,” a report on the incident said. He concluded by saying. “If a vulnerability is not found, the patch cannot be applied.”
At the end of 2021, Log4j became another lesson in highlighting the importance of having an SBOM. Immediately after the vulnerability was announced, there was a race to apply patches to prevent malicious actors from exploiting them. In a situation where every second counts, having a software BOM can help you quickly identify and assess risks in your codebase.
A powerful software composition analysis (SCA) tool like Synopsys Black Duck® can create a complete open source SBOM and even offers the ability to add third-party and custom components. Most importantly, SCA tools can provide this information on an ongoing basis, ensuring you have the most up-to-date picture of your open source risks.
Considering that open source is a key component of application development today, it is essential for every software development team to use an effective SCA tool to inventory open source and third-party components in their code.
If you want to respond quickly to security, licensing and operational risks as well as using open source software, having an up-to-date software Bill of Materials is essential.
Source:
