Managing software bills of materials

Key features you need in your SBOM tooling

Greg Mohler

Greg Mohler

Manager Advisory, Cyber Security Services, KPMG US

+1 610-937-9271

Caleb Queern

Caleb Queern

Director, Cyber Security, KPMG US

+1 571-228-8011

Software Bills of Materials (SBOMs) help organizations know what open-source software libraries and components are found in their applications. The value of SBOMs is only growing as security vendors develop new capabilities to serve growing demand for SBOM management. However, some product features are more important than others when selecting a solution that will scale to the size of large enterprises with hundreds of applications.

Without the following capabilities, remediating vulnerable dependencies and conducting incident response investigations will prove more difficult and take more time.

1. Latest Version / Fix Version Flags

One of the core security use cases of SBOM management is the identification of vulnerabilities that have been disclosed for a given software component. However, triaging a vulnerability and developing a remediation plan often require the answer to two questions:

  • Is there a more recent version of the dependency that addresses the vulnerability?
  • If so, which version introduced the vulnerability’s fix?

SBOM tools have started to address these common and necessary questions by adding “latest available version” and “fix version” flags next to each software component in your portfolio. These flags will identify which version of the component addresses the disclosed vulnerabilities, and whether a software component’s version is already up to date.

2. Dependency Graphs

When a nested software component is vulnerable, triaging the root cause can take significant time away from the task at hand. Dependency graphs allow you to quickly visualize where a software component sits in your application’s forest of dependencies, which components depend on it, which components consume it, and most importantly, which root dependency you need to upgrade or replace to address the original vulnerability.

3. Scalable Access Control

SBOM analysis platforms can be a very helpful tool for developers when they have sufficient access to the platform to quickly identify risk in an application and see a suggested solution for their problem. How do you enable such self-service access while limiting visibility to a need-to-know basis? The combination of integration with your organization’s identity provider and application-level granularity in access control allow for the scalability that large organizations need to maximize value from an SBOM platform.

4. Interoperability

There are currently two major formats used to generate most SBOMs: OWASP’s CycloneDX and the Linux Foundation’s SPDX. Both are valuable. Ensure your application security software vendor solution offers the generation of SBOMs in at least one or perhaps even both of these formats. This way the SBOMs your team uses are more likely to be understood by other tooling and perhaps serve more advanced security functions such as security monitoring of build pipelines.

In the same way cloud computing enables faster delivery of value to customers, leveraging open-source software accelerates new feature development and is here to stay in enterprise software development. Managing the risk of open-source libraries and components is a relatively new capability even in some high performing DevSecOps organizations so it’s important to start on the right foot. Before procuring a new SBOM management & analysis platform, consider prioritizing the features above so that you can spend less time gathering information, more time reducing risk, and your organization is better enabled to compete and win in the market.