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):
1.
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.
2.
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]
3.
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.
4.
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.
5.
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.
6.
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 tom@tomalrich.com.
[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 comments:
Post a Comment