Understanding SBOM Management and The Six Ways It Prevents SBOM Sprawl

While the concept of a software bill of materials (SBOM) has been around for a decade, it has moved front and center as organizations seek to improve the security of the software supply chain. As organizations ingest SBOMs for third-party software, generate SBOMs for open source components and their own code, and deliver SBOMs to downstream software users and customers, they can rapidly face SBOM sprawl, an overabundance of unmanaged and unorganized information. Hence SBOM management becomes a critical foundation for effective software supply chain management.

Why SBOMs Matter for Software Supply Chain Security

The role of an SBOM is to provide transparency about the components of a software application, providing a foundation for vulnerability analysis and other security assessments. For example, organizations that have a comprehensive SBOM for every software application they buy or build can instantly identify the impact of new zero-day vulnerabilities, such as the recent Log4Shell vulnerability in Log4j, and discern its exact location for faster remediation. Similarly, they can evaluate the provenance and operational risk of open source components to comply with internal policies or industry standards.

The importance of the SBOM was further highlighted in the U.S. Executive Order to Improve the Nation’s Cybersecurity. The Executive Order directs federal agencies to “publish minimum SBOM standard” and define criteria regarding “providing a purchaser a software bill of materials (SBOM) directly or publish to a public website.” This Executive Order will have a ripple effect across the industry, as software suppliers that sell to the U.S. federal government will increasingly need to provide SBOMs for the software they deliver. Over time these standards will spread as companies in other industries begin to mirror the federal requirements in their own software procurement efforts.

From Ad-Hoc SBOM Generation to Comprehensive SBOM Management 

As SBOMs are rapidly gaining acceptance, industry leaders have begun to develop approaches for creating, managing, and using SBOMs. These practices span the key stages of the software lifecycle: 

1. Store and manage SBOMs in a central repository

While individual development or application teams may store SBOMs in a repository alongside their code artifacts, security teams must maintain a centralized repository of SBOMs across all applications and development teams. When new vulnerabilities or security incidents arise, security teams and CISOs need the ability to quickly query the SBOMs of all of their software and instantly assess the impact instead of frantically scrambling to get individual assessments from each development team or having to waste valuable time finding and rescanning all of their applications from scratch. In addition, meeting regulatory requirements or compliance standards requires a centralized repository for reporting and other compliance activities.

2. Support SBOM standards, but don’t stop there

There are several SBOM standards, such as Software Package Data Exchange (SPDX) and CycloneDX that have evolved as a way to share SBOMs across organizational boundaries. An SBOM management system must, of course, ingest and produce SBOMs in these standard formats. However, all SBOM generation tools are not equal. Both Syft, Anchore’s popular open source SBOM generation tool, and Anchore Enterprise support these commonly used standards, but also produce a more comprehensive catalog of components and more detailed metadata including file paths, locations, and checksums that go beyond the minimum requirements of these standard formats. The ability to generate and store this richer set of metadata enables more accurate detection of vulnerabilities, creation of more granular policies, and fewer false positives.

3. Require SBOMs for all incoming software

To ensure that an organization has visibility into all of the software they use, it is important to gather SBOMs in order to analyze each software component or application. In the case of a third-party commercial software application, the software vendor would typically be required to provide the necessary SBOM which can then be ingested into your SBOM repository.

When using open source components to build custom software, the organization can directly scan an open source artifact (such as a container image) or the open source code repository prior to ingesting it into their development cycle. In some cases, the open source project may also provide a signed SBOM, which allows an organization to compare the SBOM they generate against the community-provided SBOM as an additional level of validation.

4. Generate SBOMs at each step in the development process and for each build

Organizations across all industries are developing custom software to meet their unique business needs. Most software is made up of significant amounts of open source code (50-90% depending on the application), as well as internally developed code and other 3rd party libraries. Because open source code often brings in additional dependencies at build time, it’s critical to scan your software application at each step in the development process and each time you build the software. This enables you to detect unexpected SBOM drift which can be caused by new dependencies or by tampering with the code. These SBOMs need to be tagged to the particular component or application they represent.

5. Create a comprehensive SBOM for each release of software you deploy or deliver

Whether you deliver software to customers or deploy it for use by customers, employees, or partners, you should create a comprehensive SBOM tagged to each release of a particular piece of software. This provides a tracking mechanism that enables organizations to quickly assess the security stance of each application or component they produce and evaluate the impact of new vulnerabilities that arise post-deployment. For organizations that sell software or provide it to external users, you also can now provide the required visibility and “trust reports” to downstream consumers of your software.

6. Apply automation for policy enforcement and alerts

With a centralized SBOM repository and effective SBOM management capabilities, organizations can then leverage an automated policy engine to apply policy rules that align to particular regulatory requirements or compliance standards. You can also apply any internal requirements that are specific to your organization. Automated alerts can then notify you of new vulnerabilities or violations of policies so that impacted teams can quickly remediate critical issues and prevent affected images from being deployed.

SBOM Management Using Anchore Enterprise

At the foundation of Anchore Enterprise are a comprehensive set of SBOM management capabilities that enable you to collect, store, manage and use SBOMs across the application and software development lifecycles. These combined with a broader set of features, including continuous security and compliance, policy enforcement, and trust reporting, to create an end-to-end platform for software supply chain management. Request a demo to learn more about how Anchore Enterprise enables you to better secure your software supply chain.