One of the most effective tools for finding and addressing such vulnerabilities and keeping software secure is the software bill of materials (SBOM).
Ensuring strong software security and integrity has never been more important because software drives the modern digital business. High-profile vulnerabilities discovered over the past few years, with the potential to lead to attacks against organizations using the software, have hammered home the need to be vigilant about vulnerability management.
Perhaps the most dramatic recent example was the zero-day vulnerability discovered in Apache’s popular open-source Log4j logging service. The logging utility is used by millions of Java applications, and the underlying flaw—called Log4Shell—can be exploited relatively easily to enable remote code execution on a compromised machine. The impact of the vulnerability was felt worldwide, and security teams had to scramble to find and mitigate the issue.
In November 2022, open-source toolkit developers announced two high-severity vulnerabilities that affect all versions of OpenSSL 3.0.0 up to 3.0.6. OpenSSL is a toolkit supporting secure communications in web servers and applications. As such, it’s a key component of the Transport Layer Security (TLS) protocol, which ensures that data sent over the internet is secure.
SBOMs as a solution
One of the most effective tools for finding and addressing such vulnerabilities and keeping software secure is the software bill of materials (SBOM). SBOMs are formal, machine-readable records that contain the details and supply chain relationships and licenses of all the different components used to create a particular software product. They are designed to be shared across organizations to provide transparency of the software components provided by different players in the supply chain.
Many software providers build their applications by relying on open-source and commercial software components. An SBOM enumerates these components, creating a “recipe” for how the software was created.
For example, something like the OpenSSL toolkit includes dependencies that are difficult or, in many cases, impossible for traditional vulnerability scanners to uncover. It requires a multilayered approach to help security teams identify third-party libraries associated with a software package. This is where an SBOM can help.
The U.S. Department of Commerce has stated that SBOMs provide those who produce, purchase, and operate the software with information that enhances their understanding of the supply chain. This enables multiple benefits, most notably the potential to track known newly emerged vulnerabilities and risks.
These records form a foundational data layer on which further security tools, practices, and assurances can be built, the Commerce Department says, and serve as the foundation for an evolving approach to software transparency.
A 2022 report by the Linux Foundation Research, based on a survey of 412 organizations from around the world, showed that 90% of the organizations had started their SBOM journey.
More than half of the survey participants said their organizations are addressing SBOMs in a few, some, or many areas of their business, and 23% said they are addressing them across nearly all areas of their business or have standard practices that include the use of SBOMs. Overall, 76% of organizations had a degree of SBOM readiness at the time of the survey.
The research showed that the use of open-source software is widespread and that software security is a top organizational priority. Given the worldwide efforts to address software security, SBOMs have emerged as a key enabler, it said. Growth of SBOM production or consumption was expected to accelerate by about 66% during 2022, leading to SBOM production or consumption use by 78% of organizations.
The top-three benefits of producing SBOMs identified by survey participants were that SBOMs made it easier for developers to understand dependencies across components in an application, monitor components for vulnerabilities, and manage license compliance.