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

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:

• National Telecommunications and Information Administration (NTIA): The National Telecommunications and Information Administration (NTIA) in the United States has been leading the effort to develop a standardized SBOM format, which has gained traction among industry leaders and regulators. In addition, the Cybersecurity and Infrastructure Security Agency (CISA) recently issued guidance that recommends organizations incorporate SBOMs as part of their software supply chain risk management practices, referencing the NTIA recommendations.
• Executive Order on Improving the Nation’s Cybersecurity: U.S. President Biden has issued an Executive Order and released an updated cybersecurity strategy brief that would require SBOMs for all software sold to the government.

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.