Why SBOM management is no longer optional

As with many zero-day vulnerabilities, organizations are scrambling to identify and remediate the impact of the Log4Shell vulnerability in Log4j. This particular vulnerability is extraordinarily dangerous because it was found in a pervasive library and is easy to exploit. One critical element here is that it was already being actively exploited before details were made public, making time of the essence.

Once security and application teams catch their collective breath after round-the-clock remediation efforts, they will conduct retrospectives and reviews to identify ways to better prepare for the next zero-day vulnerability, because there will be a next one. In this new environment, the software bill of materials (SBOM) is becoming a vital security imperative that enables visibility as software moves across the supply chain. Organizations must act now to establish a critical new capability: SBOM management.

Creating a comprehensive SBOM

Currently, the best practice being adopted by industry leaders is to generate a software bill of materials for each and every delivered or deployed release of an application. In fact, the recent US Executive Order on the Nation’s Cybersecurity will require software suppliers to provide federal agencies with an SBOM for the software they sell or deliver.

If we take a broad view here, generating an SBOM is only the first step. As Log4Shell has shown us, we need the ability to easily leverage and search SBOMs when a new zero-day occurs. Generating an SBOM is easy, but managing and tracking hundreds or thousands of SBOMs is a tall order, but also a hard requirement to address the changing threat landscape.

While it’s common today to scan for vulnerabilities before an application is delivered, this simply isn’t enough. Scanning applications to identify the components and relevant vulnerabilities should be an ongoing process that doesn’t run just once, but runs on a regular basis. Every time an application is scanned, the results must be logged and analyzed. In order to move from an ad-hoc system to one that is continuous, tooling and automation are important.

Applications developed by your organization will typically include a significant amount of open source code along with internally developed code and third-party commercial libraries. SBOM generation tools can examine the code you write as well as the open source code, but scanning commercial libraries may not be possible depending on the packaging. In this case, you should request an SBOM from your commercial suppliers. Once you have SBOMs for all of your components, you will need to combine them and produce an aggregated SBOM that covers the entire application.

Critical capabilities needed for SBOM management

Using SBOMs as a foundation for securing your software supply chain will create SBOM sprawl over time as more and more SBOMs are generated and ingested. Tooling and automation will be needed to solve the problem of SBOM management. Capabilities to seek out include:

• A centralized repository to store SBOMs across product teams and applications.
• Search capabilities to quickly find applications with problematic components.
• The ability to generate SBOMs or import SBOMs provided by software suppliers and open source projects.
• Aggregation of component-level SBOMs to create a comprehensive SBOM for an entire application.
• Support for rich SBOM formats as well as lightweight SBOM standards such as SPDX.
• Ability to store multiple SBOMs for multiple releases of an application, multiple builds, or different stages in the development process.
• Comparisons of SBOMs to detect drift and policies to alert of possible tampering.

SBOMs speed incident response

Once you have a definitive and accurate set of SBOMs for an application release, you need to store these SBOMs in a centralized repository to make it possible to quickly scan and search the contents of the SBOM. A centralized approach means that security teams will not have to waste time trying to determine what components are  deployed in their applications. When the next major vulnerability arises, the SBOM management tool should return results instantly. Applying a policy engine and policy rules will allow generation of notifications and alerts to all of the impacted applications teams. Knowing what is affected and how to remediate should be measured in minutes, not weeks.

The new realities of the SBOM

As you come up for air after the short-term Log4Shell remediation efforts, it’s critical to prepare for the new realities of software supply chain vulnerabilities and attacks. If your organization is not already generating SBOMs, it’s time to start. But generating the SBOM is only step one. You must also put in place processes to store and manage SBOMs. Then create workflows that enable you to quickly access and search that data when the next zero-day vulnerability hits.

Log4j was a very costly lesson to remind us why we not only need SBOMs, but also the ability to manage them as part of a complete software supply chain management strategy. Now is the time to be proactive about the security of your software supply chain. Implementing SBOM management is a critical requirement that will pay dividends when the next zero-day comes along.

Josh Bressers is VP of security at Anchore.

—

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.