How to Use a Software Bill of Materials (SBOM) as Part of Your Third-Party Risk Management Program

Software supply chain attacks are driving new efforts to standardize software bills of materials. Here are six recommendations for using SBOMs in your third-party risk management program.
Brad Hibbert
Chief Operating Officer & Chief Strategy Officer
April 18, 2023
Blog sbom 0423

A software bill of materials (SBOM) is a structured list of components and dependencies that make up a software application or system. SBOMs include information such as the names and versions of all the components, the relationships between them, and their license and vulnerability information.

The evolution of SBOMs can be traced back to the increasing complexity of software applications and growing concerns about software supply chain security. For example, as software applications have become more complex and reliant on third-party components, it has become more difficult for developers and security teams to track and manage dependencies between the components.

Several high-profile security incidents, such as the SolarWinds hack, have emphasized the need for greater visibility and accountability in software supply chains. This has led to increased interest and adoption of SBOMs as a means of enhancing software security. In fact, the U.S. government is pushing for SBOMs, and they could become a leading element of third-party risk management monitoring and reporting in the near future.

This post examines how SBOMs apply to third-party risk management, reviews recent standardization efforts, and provides best practice recommendations to get started.

How SBOMs Apply to Third-Party Risk Management

SBOMs have several applications in third-party management, including:

  • Risk management: SBOMs can be used to identify and assess the risks associated with third-party components in a software application. By analyzing the SBOM, security teams can identify vulnerabilities and determine whether the components are up to date and properly configured.
  • Compliance: Many industries, such as healthcare and financial services, have strict compliance requirements that include third-party software components. SBOMs can be used to ensure that all components meet these requirements and are properly licensed.
  • Supply chain management: SBOMs can be used to manage the software supply chain by identifying the origin and ownership of each component. This can help organizations to ensure that they are only using components from trusted sources and to track any changes or updates to the components.

As the complexity of software applications continues to grow, it is essential that organizations have a clear understanding of their software components and their associated risks. SBOMs provide a structured way to achieve this visibility and accountability.

On-Demand Webinar: How to Assess Software Vendor Cybersecurity

Join Dave Shackleford, principal at Voodoo Security and SANS instructor, as he shares tips for strengthening your software supply chain security.

Initiatives with SBOM Requirements

While SBOMs have been around for some time, their adoption has grown as cybersecurity threats and regulations have necessitated more proactive approaches to managing third-party risk. The future of SBOMs in third-party risk management looks promising as more organizations recognize the importance of managing software supply chain risk. In fact, there are already initiatives underway to require SBOMs for certain types of software. Here are two examples:

SBOM Formats and Standards

One challenge with the adoption of SBOMs is the lack of standardization. Currently there are a few different industry standards for SBOM.

  • CycloneDX SBOM: One of the most widely used and accepted standards is the CycloneDX SBOM format, which is an open standard developed by the CycloneDX project. The CycloneDX format is designed to be easy to use and implement, and it includes support for a wide range of software components and package managers.
  • SPDX: Another widely used SBOM format is SPDX (Software Package Data Exchange), which is maintained by the SPDX working group under the Linux Foundation. SPDX is an open standard for describing software packages and their associated metadata, including licensing information and copyright statements.
  • SWID tags: SWID tags (Software Identification Tags) are a standardized way of identifying software components and their associated metadata.
  • BOMXML: BOMXML is an XML-based format for describing software components and their relationships.

Overall, the choice of SBOM format may depend on the specific needs and requirements of the organization or industry using it, as well as the tools and systems being used to generate and consume the SBOM data. This increases complexity for third-party risk teams and technologies as they may need to consume, interpret and analyze multiple formats.

How to Include SBOM in Your Third-Party Risk Management Program

Regardless of the complexities involved, the use of SBOMs is expected to increase. As their use becomes more widespread, it is likely that they will become a standard part of third-party risk management practices. Organizations will be able to use SBOMs to identify vulnerabilities in third-party software and take proactive steps to mitigate those risks. In addition, regulators may require organizations to provide SBOMs as part of their compliance requirements. Here are some recommendations for considering the SBOM as a component of third-party due diligence:

  1. Require vendors to provide SBOMs: As part of the due diligence process, require vendors to provide updated SBOMs for their software products. This will help you identify any potential vulnerabilities or licensing issues that may impact your organization's security and compliance.
  2. Assess third-party risk: Using an SBOM to assess risks associated with third-party software will help you determine which components may require additional scrutiny or mitigation measures.
  3. Evaluate license compliance: SBOMs can be leveraged to evaluate the compliance of third-party software components with licensing requirements and to avoid license infringements.
  4. Monitor for vulnerabilities: Use an SBOM to monitor for vulnerabilities in third-party software components, identify any potential security risks, and take proactive measures for risk mitigation.
  5. Develop mitigation plans: SBOMs can assist you in developing risk mitigation plans and addressing potential security or compliance issues before they become a problem.
  6. Keep SBOMs current: Ensure that SBOMs are kept current as new software components are added and existing components are updated. This will help you maintain an accurate and comprehensive view of your organization's software dependencies.

By incorporating these recommendations into your third-party due diligence process, you can ensure that your organization can effectively manage the risks associated with third-party software components.

At Prevalent, we support SBOM files as evidence within the due diligence process. For more on how we can help you incorporate SBOMs into your TPRM program strategy, request a demo today.

2014 04 10 Headshot Brad Suit
Brad Hibbert
Chief Operating Officer & Chief Strategy Officer

Brad Hibbert brings over 25 years of executive experience in the software industry aligning business and technical teams for success. He comes to Prevalent from BeyondTrust, where he provided leadership as COO and CSO for solutions strategy, product management, development, services and support. He joined BeyondTrust via the company’s acquisition of eEye Digital Security, where he helped launch several market firsts, including vulnerability management solutions for cloud, mobile and virtualization technologies.

Prior to eEye, Brad served as Vice President of Strategy and Products at NetPro before its acquisition in 2008 by Quest Software. Over the years Brad has attained many industry certifications to support his management, consulting, and development activities. Brad has his Bachelor of Commerce, Specialization in Management Information Systems and MBA from the University of Ottawa.

  • Ready for a demo?
  • Schedule a free personalized solution demonstration to see if Prevalent is a fit for you.
  • Request a Demo