Software Bill of Materials (SBOMs) in Your Vendor Risk Management Program

In today’s technology-driven world, many of us understand how to use complex software applications like project management tools, a customer relationship management system, and cloud storage services. But have you ever tried to understand exactly how these applications work or needed to verify the security of the components used to develop the application? If so, you may have seen the term Software Bill of Materials (SBOM), accompanied by a list of technical terms and concepts, though this practice is still new. An SBOM can be tricky to navigate, but it’s a valuable tool to use within your vendor risk management (VRM) program.

Let’s review the basic definition of an SBOM and how it can be used to identify vulnerable applications under your VRM program. You’ll also learn tips for requesting an SBOM from your vendors and next steps to take after reviewing them.  

What Is a Software Bill of Materials (SBOM)? 

A Software Bill of Materials is often described as a “list of ingredients,” or a recipe for building a piece of software. SBOMs list various details about the components such as:

• Origin – Components may involve code that is open source (available to the public) and/or proprietary (owned by an individual or organization).
• Dependencies – This describes any direct or transitive dependencies that the software needs to function correctly.
• Version – An SBOM also details the versions of each of these software components, which is helpful for tracking any updates and vulnerabilities. 
• Licensing – This tells you what type of license the component has. 

According to the Cybersecurity & Infrastructure Security Agency (CISA), SBOMs are used in three contexts: software production, software selection or purchasing, and/or software operation. SBOMs can also be used within the context of vendor risk management by identifying vulnerabilities in your vendor relationships and supporting different activities throughout the lifecycle. 

Using SBOMs to Identify Vulnerabilities in Vendor Risk Management  

One of the main uses of an SBOM is to identify software vulnerabilities so they can be addressed through patches or updates before they’re exploited by attackers. Using SBOMs in your vendor risk management program can serve a similar purpose of identifying vulnerabilities and risks in your vendor relationships. SBOMs can also create more efficiencies and help strengthen your overall VRM program.

Here are 4 benefits of using SBOMs in vendor risk management: 

• Provides deeper insight into vendor risks and vulnerabilities – An SBOM helps identify the inherent risk a software product presents without implementing any controls. These inherent risks may include compliance, cybersecurity, business continuity, and more. Your team can then determine the necessary controls to mitigate the potential risks identified.
  
  For example, a vendor’s SBOM can help an incident response team identify which vendor applications contain a vulnerable component. This enables you to make informed, risk-based decisions about how to continuously monitor and mitigate vendor risk. 
• Supports the vendor selection process – Sometimes, mitigation isn't possible, or the vendor is unwilling. In these instances, your organization needs to know if the specific software product’s vulnerabilities are a deal breaker or not. When you consider the increasing frequency of software supply chain attacks, it’s better to know about any vulnerabilities or unpatched weaknesses before selecting a vendor and purchasing a product.
• Enhances ongoing monitoring efforts – SBOMs are especially valuable during ongoing monitoring, when they’re used in conjunction with a vulnerability database (i.e., The National Vulnerability Database or the MITRE CVE Program). These databases stay updated with known software vulnerabilities and recommended mitigation strategies, which can help support proactive risk mitigation. Organizations can track these vulnerabilities and compare them to their vendors’ SBOMs to locate components in the vendor’s software that need to be updated or patched. 
• Improves documentation and reporting – Maintaining an inventory of vendor SBOMs can help support your documentation and reporting practices. For instance, imagine that your organization is impacted by a third-party security incident. Reporting on this incident will be a much smoother process if you possess the vendor’s SBOM and can document key details, such as which components were affected and how they can be protected from future incidents.

Requesting an SBOM From a Vendor

Some organizations may not be familiar with asking their vendors for SBOMs, so it helps to understand a few key points before integrating them into the due diligence process.

Here are some considerations for requesting an SBOM from your vendor:

• SBOMs are usually optional – Despite their benefits, it’s important to note that SBOMs aren’t a regulatory requirement for many vendors. The few exceptions are federal contractors and vendors that create certain medical devices. PCI-DSS 4.0 also has a requirement related to SBOMs in the payment industry, which will be enforced March 31, 2025. Many experts believe that SBOMs will eventually become a regulatory expectation, so your organization may benefit from requesting this information as a standard due diligence item from your software vendors, especially those that are higher risk.
• Frameworks haven’t been standardized – The process of creating and documenting SBOMs doesn't have a set standard; however, if the vendor doesn’t have an SBOM for the product, you should ask them to generate one. Luckily, there are legislative proposals and standardized frameworks in progress from various government agencies including CISA, the National Telecommunications and Information Administration (NTIA), and the National Security Agency (NSA). These standards generally include minimum elements such as information about the component’s supplier, version, and unique identifier. The non-profit MITRE corporation has advocated for SBOMs to be integrated into supply chain initiatives and frameworks, using an approach that includes automation, standardization, an integration with development, security, and operations (DevSecOps) practices. Until set standards and regulations exist for SBOMs, you should be prepared to ask for an SBOM when conducting due diligence on your software vendors. 
• Formatting can vary – SBOMs can come in three distinct formats – SPDX, CycloneDX, and SWID. None of these formats are particularly user-friendly, so, usually there is a learning curve, unless you have a tool to manage them. However, an SBOM's benefits make the learning process worthwhile for many organizations. And, when requesting an SBOM, you can always ask your vendor if their SBOM can be provided in a more accessible format (e.g., HTML, PDF, or CSV file).

Next Steps After Reviewing a Vendor SBOM 

A vendor’s SBOM should always be reviewed by a qualified subject matter expert (SME) who understands different aspects of the document and how the software can impact your organization. The SME should carefully evaluate the SBOM to verify its completeness and identify any security vulnerabilities or issues with compliance. 

After the SME reviews the vendor’s SBOM, consider these next steps:

1. Document red flags. Make sure the SME has documented any red flags, such as outdated or incomplete information, unpatched vulnerabilities, or components from unverified sources. Any discrepancies or inconsistencies between the SBOM and software should also be documented. 
2. Discuss issues with the vendor. Red flags should be communicated with the vendor to ensure awareness. The vendor may need to provide clarification and verify any remediation efforts. The vendor’s remediation activities should include a documented timeline that you can track for progress. 
3. Consider additional controls. The SME should recommend any additional controls that may need to be implemented in your system. Depending on the issues, this may include network segmentation or increased vendor monitoring. 

SBOMs can be a great tool to provide transparency into the risks associated with your vendor’s software. Although vendors aren’t required to follow set requirements or standards for SBOMs, they still offer many benefits for your vendor risk management program. With increased visibility into your vendors’ software, your organization can better identify and mitigate third-party risk.