What SBOM contract language should we require? How about “None”?
- Jul 27, 2022 2:56 pm GMT
As we approach the August 10 deadline for federal agencies to start requiring SBOMs from their “critical software” suppliers, the question comes up regularly[i], “What contract terms should we require for SBOMs?” I used to take such questions very seriously, stroking my chin and intoning, “That’s a good question. This is something that needs to be addressed soon” – or some incredibly wise statement like that.
I’ve said that, even though I’ve always been skeptical about the usefulness of cybersecurity contract language in procurements. I’ve always believed that the important thing is to get the vendor’s agreement to take steps to mitigate a particular cybersecurity risk (e.g., implement multi-factor authentication for the vendor’s remote access system). This could be through including terms in a contract, but it could also be through getting them to state their agreement in an email or letter.
However, I’ll admit that commitments made in letter or email are de facto contracts, and an organization can be held to those commitments almost as easily as when they’re included in a contract. If a vendor balks at agreeing to contract terms, they’re unlikely to agree to essentially the same terms in either a letter or an email.
This is why I think it’s fine, in most cases, to simply get the vendor’s verbal commitment to do something, then document who made that commitment and when. You won’t do this in order to nail the vendor in a court of law because of their verbal commitment; you probably can’t do that, and it would probably result in the mitigation not being made for years, anyway. However, it’s amazing how many people seem to think that the goal of supply chain cyber risk management is to get the vendor to agree to improve their cybersecurity in a contract, but not to get them actually to do what they promised. These people think their job is finished when the contract is signed.
Here’s some news: Getting a vendor to sign a contract mitigates zero risk. The risk only gets mitigated when they do what you asked them to do. That’s true, no matter whether you asked them to commit in contract language (signed in blood or just plain ink), an email, a letter, a phone call, a conversation at a restaurant, a message in a bottle, Morse code, cuneiform tablets, whatever. You have to follow up with them – often repeatedly – to ensure they do what they said they’d do. Otherwise, whatever time you spent getting them to sign the contract, or commit in any other way, is wasted.
But, if the vendor has agreed to do something in a contract, isn’t it likely they’ll keep their promise? That depends on the vendor, and what actions you take if it appears they haven’t done what they agreed to do. Is your company’s policy to threaten to sue a vendor as soon as they fall a day behind the commitment they made, then put more and more legal pressure on them until they capitulate? If so, you’d better have a lot of lawyers on staff with nothing better to do than harass vendors.
Here’s an experiment: Ask your procurement people how many times they’ve sued a vendor about anything, let alone a cybersecurity term. When I’ve done that (admittedly not with huge companies, since they won’t answer the question at all), the answer is always that they’ve never sued over cybersecurity terms (or anything else having to do with performance. It’s almost always financial). Moreover, in most cases, the company has sued any vendor for anything at all fewer than maybe five times. Lawsuits are only an enforcement mechanism of last resort; they should never be your first resort – and they shouldn’t be threatened as your first resort, since that just reduces your credibility with the vendor to zero.
The fact is, if a vendor is doing at least a reasonably good job for your organization and they’re liked by the engineers or whoever is dependent on the vendor’s product or service to get their job done, you’ll never sue them over anything. Consideration of the effort and cost of finding a new vendor – and the strong possibility that whatever new vendor you settle on won’t measure up to the one you just fired – will almost always lead to your organization settling whatever dispute you had with the vendor.
So why even pretend that lawyers need to be involved? Sit down with the vendor as soon as a cybersecurity issue comes up and figure out a solution you can both live with: That is, they’re sure they can achieve the objective, while you’re sure that the value of whatever you gave up in your negotiations will be far less than the cost of retooling or retraining for a new vendor.
However, with SBOMs, it’s even more cut-and-dried: Given that SBOMs are just starting to be distributed to customers in dribs and drabs (although software developers are using them heavily now for internal product risk management purposes) and end uses have just about zero experience using them in their own cyber risk management programs, it makes no sense now even to talk about contract terms for SBOMs and VEX documents. Before contract terms will ever be useful, there needs to be widespread experience with SBOM distribution and rough agreement on best practices for mitigating those risks. But that agreement is years away and needs to follow experience, not precede it. That will be years from now. I estimate it will be 5-10 years before SBOMs are being widely distributed and used, and the world has at least a couple years of experience with them. Then we can think about real contract language.
However, I know that most companies of medium-to-large size require a contract with every purchase, and more and more companies want to mention SBOMs in every contract for software; of course, that’s a good thing, and I recommend it as well. However, the term should read something like, “Vendor will provide software bills of materials in a format and frequency to be agreed upon between Vendor and (our organization).”
Once that’s agreed on, then the vendor’s product security team and the customer’s supply chain cyber risk management team need to discuss the details of what the vendor will actually deliver. What should the customer ask for? If SBOMs and VEXes were already widely distributed and widely used, I would ask for at least the following (I’m sure I’ll think of other terms later):
- A new SBOM needs to be provided whenever anything in the product has changed, including major and minor updates, patches, new builds of existing versions, etc.
- Whenever a new SBOM is produced, the supplier should provide both an SBOM produced as part of the “final build” of the product and an SBOM produced from the actual binaries that are distributed. These include not just the software product binaries, but any container, installation files, “runtime dependencies”, etc. – anything that will remain on the system after installation and which may develop vulnerabilities, just like the product itself can.[ii]
- The supplier should provide a valid CPE identifier for every proprietary component in the product, and a valid CPE or purl identifier for every open source component.
- The supplier should not provide an update to the product that contains any exploitable vulnerabilities that pose a serious risk (I’m sure most current contract language regarding software vulnerabilities currently relies on the CVSS score as a measure of risk. However, people who know more than I do tell me that CVSS scores don’t really measure risk, or anything else that’s useful. If so, we need another readily available score to take its place. The EPSS score might be that, although I don’t know how widespread its use is. It measures the likelihood that a vulnerability will be exploited, although I need to point out that this is different from the exploitability addressed in a VEX document. See this post for more information). If the supplier can’t avoid doing this in some case, they need to discuss with your organization mitigations that might address the risk posed by these vulnerabilities.
- The supplier will patch new vulnerabilities that pose high risk within (15-30) days of publication in the NVD, availability of exploit code, or some other acceptable event.
- The supplier will provide a VEX notification that a vulnerability identified in the NVD for a component of their product is in fact not exploitable in the product itself. This should be provided as soon as possible after the supplier determines the vulnerability is not exploitable.
These are all worth discussing with the supplier, but you shouldn’t expect to get them to agree to any of these items for a few years (except for numbers 4 and 5. These aren’t dependent on SBOMs being released, so the supplier should be making commitments like these already). But that’s OK. Find out what they can commit to and agree on that, even though it will just be a verbal agreement.
And for heaven’s sake, give the lawyers the day off. Tell them to come back in 5-10 years, when it will be time to discuss specific contract terms regarding SBOMs.
Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at firstname.lastname@example.org.
[i] It comes up from private industry, which of course isn’t subject to the EO; the federal agencies have to utilize the FAR (Federal Acquisition Regulation) and thus don’t have much, if any, control over their contract language.
[ii] I’ll admit that this particular “requirement” is something that I personally think is needed – not necessarily the NTIA, CISA, The Tibetan Book of the Dead, Baháʼu'lláh, or any other entity.
No discussions yet. Start a discussion below.
Get Published - Build a Following
The Energy Central Power Industry Network® is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.
If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.