Where is Your Risk? Vulnerabilities in Open Source Software
The first post of this series on the software-related risks organizations are facing looked at vulnerabilities introduced in development. In this post we look at the risks of open source vulnerabilities.
Organizations are increasingly dependent on third-party software, including open source code, but current tools provide limited visibility and require a lot of manual work. To securely leverage third-party software at scale without losing speed to market for new software releases, organizations need a better set of tools to detect, prioritize and remediate risk automatically.
How Serious Are Open Source Vulnerabilities?
Consider the case of the zero-day vulnerability discovered in Apache’s popular open source Log4j, a logging utility used by millions of Java applications. The flaw, called Log4Shell, was relatively easy to exploit to enable remote code execution on compromised devices. The vulnerability had a worldwide impact, as organizations using the utility rushed to find and fix the bug.
Organizations can’t ignore the risks associated with open source code, given how prevalent it has become. A report by Linux Foundation Research in 2022, based on a survey of 412 worldwide organizations, showed that the use of open source software is widespread.
How an SBOM Addresses Open Source Vulnerability Risk
One of the most effective solutions for ensuring the security and reliability of software is the software bill of materials (SBOM). An SBOM is a formal, machine-readable record that contains the details and supply chain relationships and licenses of the various components used to create a software product.
SBOMs are designed to be shared across organizations in order to provide transparency of the software components that are coming from different players in the supply chain, including open source developers. They provide detailed lists of software components, essentially creating a recipe document on how the software was created, which suppliers provided the components, dependencies among components, etc.
The U.S. Department of Commerce said SBOMs provide organizations that produce, purchase and operate software with information that improves their understanding of the software supply chain. This provides several benefits, including the potential to track and mitigate known and emerging vulnerabilities. SBOMs form a foundational data layer on which further security tools, practices and assurances can be established, the Commerce Department says, and serve as the foundation for an evolving approach to software transparency.
The Linux Foundation Research report noted that more than half of the survey participants said their organizations were addressing SBOMs in a few, some or many parts of their business. About one quarter said they were addressing SBOMs across nearly all areas of their business or have standard practices that include the use of SBOMs.
An SBOM is most effective when it is dynamic. Software is not static, and neither should SBOMs be static. They need to keep up with the near constant changes in the market, including new releases, components, etc. It’s important, therefore, that organizations look for tools with the ability to incorporate updates automatically as changes occur.
By leveraging Dynamic SBOMs, security and development teams can ensure that they’re keeping the open source software they rely on as secure as possible.
