One of the biggest questions we hear from customers working on their SBOM program is how to get them from suppliers. Until it becomes common practice for suppliers to provide SBOMs unbidden, there are some things consumers need to do to incentivize the action.
It’s not that suppliers don’t want to do the right things, but this may be new for them as well, and the guidance from industry has been ambiguous enough that they may not understand exactly what their customers are looking for. What are the right SBOM formats? How should suppliers transmit their SBOMs? How often should SBOMs be updated? What comes next?
The good news is we have a very effective mechanism to clear the air in the form of contractual requirements. The problem is most consumers never ask in the procurement process because they don’t involve their cybersecurity and supply chain security teams in the buying process until after the procurement closes, and then it may be too late.
Your supplier has one objective during procurement: to make sure the sale occurs. Part of this is successfully removing the friction for the sale. Your sales contact will do everything in their power to make this happen. Your job is to introduce just enough friction to get your requirements met.
But before you even start this process, it’s best to have a clear idea of what you are asking for and to get your internal teams on board with the ask. This will reduce confusion with your supplier, and when you do your due diligence, everyone will already know what the expectations are. There are no surprises. This will reduce friction inside your own supply chain risk management process and get everyone on the same page.
We always recommend that the SBOM initiative be supported with a charter and a governance process that has been authorized by executive management. Procurement requests can come from multiple parts of your organization, and driving these initiatives from the top demonstrates management support. This enables line-of-business vendor relationship owners to communicate requirements early in the procurement process, and quality and compliance gates within procurement will align with these expectations. But what are the right requirements?
Early Considerations
When you are first getting started, focus on the basics. While taking a risk-based approach may be a more mature tactic, if you are just starting out, you probably just need to get something in place — especially if you don’t have a grasp on what constitutes a risky procurement yet. Don’t worry if it’s not perfect. It’s more important to start doing the work, and doing so consistently. We can optimize things later. Secondly, consider the fact that you may be working on multi-year procurements, and it becomes doubly important that you get something in place as soon as possible since you may not have a chance again for a few years.
Another consideration when looking at the following requirements, and really any set of contractual language, is the topic of negotiation. There are items you will ask because you’d like for them to comply, and then there are provisions you might demand as a minimally acceptable requirement for the procurement to close. Make sure you are very clear on the “musts” and the “mays” in your contract language. Give yourself room for negotiation.
With that out of the way, let’s explore the areas to consider when requesting SBOMs in your contracts. You will likely start with a general overview, a statement that SBOMs are required. And then you will need to get a lot more specific on what this means for your organization. But throughout each of these requirements, consider how you will use the information provided. You should assume that the more work you ask the supplier to do, the more likely that you will see a cost increase for your procurement. Make sure that what you are asking for actually drives value for your process.
Submission Frequency
How often do you expect an SBOM? Is this only for the initial procurement, or do you expect your supplier to continue providing them throughout the ownership of the product? Do you need them for every software release or patch, or only major releases? Remember, the more you receive, the higher the volume of processing for your operational teams. With this in mind, we recommend requesting a cadence no more frequent than your ability to act. Meaning, if you can’t patch software more than once every 60 days, it may be wasteful to expect SBOMs from your supplier more frequently than that.
However, regardless of how frequently you can process SBOMs, it’s critical to make sure the supplier is producing them on every software build for themselves. Because even if the supplier doesn’t send the SBOM to you, it’s important that they are paying attention to their own vulnerability management inside their software development process.
Some customers we have spoken with also tend to use the initial SBOM as a baseline document and look for more iterative updates in the form of a VEX. These vulnerability exploitability reports tend to be more dynamic in nature than SBOMs, and assuming you trust the assertions made by your supplier, that may be sufficient.
Scope
What needs to be included in the SBOM: only open source components, or proprietary software as well? Think about how you will use this information. Some suppliers do not include proprietary code in their SBOMs, because how do you look up that information in vulnerability databases? The reality is you never know what will happen in the future, so it’s a good idea to ask for full transparency; however, you should be prepared for pushback on that.
How deep does the SBOM need to go? Can it just include top-level components, or should it inventory all software components? Is there any flexibility here, and what should the supplier do if there are unknown components in their build? Is a partial SBOM acceptable?
The reality is that while it is helpful to understand all of the components in the SBOM, including transitive, I would suggest these may be less important than direct dependencies. Transitive dependencies are harder to directly resolve, and it is common that they are used less frequently than direct dependencies. That too means they are less likely to be exploited or exploitable in your software project. If you have the opportunity, though, you should seek complete transparency. If this is not possible with your supplier, consider the risk of the software and how it is used in delivering your critical mission to determine if this is acceptable.
From the earlier days of the NTIA SBOM efforts, more specifically, the guidelines set forth in the framing document, the need for complete transparency has been clear. But so too has been the understanding that supply chain transparency is a journey that we are all on different stages of. Even though the FDA SBOM requirements align with the NTIA documents in their approach, a 2023 FDA webinar noted that while full transparency was desired, they realized that not all suppliers were prepared to do that yet.
When you are just getting started, even just the top level is more visibility than you had previously. And, if you are working with a supplier that is supporting an EU customer base, it would not be surprising to find they have adopted Cyber Resilience Act (CRA) criteria, which does not require more than that.
We should also note that if your organization sells into the U.S. federal government and is bound by NTIA requirements, your SBOM should include transitive dependencies (or, at minimum, include enough detail so transitive dependencies can be sought out recursively). These efforts are early in their enforcement period and are likely to become less forgiving over time, so it’s best to be prepared.
All things considered, completeness should definitely be an aspirational goal, if not a specific requirement in your SBOM program. Ideally, every supplier you work with can and will support this level of transparency. And, by specifying these requirements in your contracts and holding your partners accountable, you can gain assurances that they are managing their critical software supply chains responsibly.
Delivery Channel
How should the supplier provide the SBOM to you? One consideration for you may be to consider your SBOM ingestion and management process here. It is certainly easier for you if you don’t have to deal with raw SBOM objects and they can just be consumed directly into your SBOM management portal. We have seen everything from FTP, email, API, GitHub, and third-party SBOM repositories, but the more you can streamline this, the easier your SBOM program will be. The flip side of this is if your process is difficult for the supplier, you may be faced with a decision to either accept what they provide you (and how they want to provide it to you), or receive nothing at all.
Formats and Minimum Elements
What formats do you want the SBOM provided in? Do your tools support CycloneDX or SPDX? JSON or XML? With robust SBOM management tools it may not matter, but you will certainly want to specify that the supplier provides an SBOM that is conformant with the schema for the formats your tools support.
It’s important to pay attention to the versions of the format as well. An SBOM in an early version of CycloneDX or SDPX may contain very different information than one in the latest version. Establish the minimum you are willing to accept, but be reasonable, as this space changes rapidly. For instance, we see a lot of tools still producing CycloneDX 1.4, and these are still very useful documents.
Deciding which data fields should be included in the SBOM is important as well. The NTIA’s minimum elements (mandated as part of the US Executive Order 14028) set a baseline, and most quality SBOM tools align with these criteria. However, many open source tools still do not quite meet all the requirements, so making sure to specify what metadata to include in the SBOM is an important consideration.
Other useful metadata above and beyond the NTIA’s minimum elements might include the cryptographic hash of the component, or digital signature verifying authenticity of the information. Unique URI for where the component was sourced from and other unique identifiers such as PURL are highly useful in performing data correlation for vulnerability risk management as well.
Quality
Do you have expectations on the quality and accuracy of the SBOM? Is there an acceptable confidence level? What happens when data is missing or inaccurate? The topic of SBOM quality can relate to schema compliance, minimum metadata fields, optional SBOM fields that may be important to your program such as licensing information, or other factors. The use of open source utilities such as sbomqs can provide a standard way to measure quality.
Vulnerability Reporting and Response
What should a supplier do when a vulnerability is identified? Are they required to tell you? Do you have a specific SLA for specific types of vulnerabilities, and what should happen when a supplier fails to remediate the issue in time?
Both VEX and VDR are companion documents to SBOM and have emerged as machine-readable mechanisms to convey additional information about vulnerabilities related to the components documented in an SBOM. Do you require a vulnerability report? And, more importantly, if the supplier provides one, what do you plan to do with it?
Penalties for Non-Compliance
Lastly, when a supplier fails to meet their obligations, do you have a mechanism for enforcement? It is advisable that there be clear penalties for non-compliance in your contract. Financial penalties are an effective means of incentivizing your supplier, but definitely make sure that your contractual terms don’t overstep your negotiating power. You will likely find that your organization's size and your supplier's size are inversely proportional to the success you will have in driving these requirements.
Sharing SBOMs
Like we mentioned, there are multiple ways of transmitting SBOMs from organization to organization. One option that may work well for both software producer and supplier is to use FOSSA’s SBOM Portal. The SBOM Portal enables software suppliers to securely upload their SBOMs and provide least-privileged access, which may help combat concerns over exposing IP. Manufacturers can then easily analyze the SBOM for security, code quality, and license compliance issues directly in the FOSSA app.
Also, don’t forget that an SBOM itself has a license too, just like your software. And, as the author of that SBOM, you get to decide how to license your intellectual property, including the SBOM, and whether it is allowed to be shared by the recipient or not.
For more information on the SBOM Portal, please get in touch with the FOSSA team.
