There’s been a lot written about the role of SBOMs (software bills of materials) in addressing widespread vulnerabilities like log4j (not that there have been many vulnerabilities as serious as log4j). It runs the gamut from “If you had SBOMs, you’d know in ten seconds whether any of the 10,000 software products running on your network contains log4j, as well as any of their components, components of components, components of components of components…yea verily, unto the 20th degree of component” to “SBOMs will be quite helpful in finding log4j. An SBOM and $4.70 will get you a tall no-foam latte. That will keep you awake as you look for instances of log4j.”
What’s common to just about all of these
statements is they’re written in the subjunctive mood: “IF we had SBOMs….”
Because we simply don’t have SBOMs now, to any degree that would be very helpful
in researching the simplest vulnerability, let alone as widespread a
vulnerability as log4j.
I’d like to suggest that it’s not
useful to speculate about what SBOMs could or could not do in this or any other
case, any more than it’s useful to speculate about whether, if there is a
multiverse, there’s a universe in which the Pope is Jewish.[i] What’s much more useful is
to ask a question like, “What are the use cases in which SBOMs will help me,
and what do I need in order to make those use cases real?”
SBOMs aren’t an all-or-nothing
proposition, where you either have SBOMs for all of your software, or you have
nothing. It would of course be nice to have a current SBOM for all software
that you own (or rent in the cloud), but right now, you’ll be way ahead of the
game if you have an up-to-date SBOM for even five software products on your
network. After all, that’s probably five more SBOMs than you had last year.
What can you expect to have at the
end of 2022? Executive Order 14028’s mandate
for federal government agencies to require SBOMs from their “critical software”
suppliers kicks in next August. Even if you’re not a government agency, it’s
likely your suppliers will be able to provide SBOMs, since they’re already producing
them for the agencies. You should at the minimum start asking for them from
your suppliers. And you should especially start asking for a recent SBOM
whenever you’re purchasing software.
But the bigger question is what
you do with the SBOMs when you get them. While there is a use case for SBOMs
for software license management (in fact, that was the first use case), that is
mostly applicable to software developers. The SBOM use case for the
overwhelming number of users (and the only use case addressed in the EO) is software
vulnerability management. I break that down into three types:
The first is responding to emergency
vulnerability notices like log4j and Ripple 20, in which the vulnerability (or
vulnerabilities) isn’t applicable to particular final products, but to
components of final products. While it would be good for you to have an SBOM
for each product so that you know which ones contain log4j, what’s even more
important is that you lean on your supplier to tell you whether or not log4j is
a “first-level” component of their software, and also whether it’s a component
of any of their first-level components (i.e. it’s a second-level component). But
they shouldn’t just tell you this; they should issue a patch (or patches) to fix
the problem.
Of course, if you had an SBOM that
included both the first-level components and SBOMs for each of those
components, you would then know whether the product is affected by log4j, down
to the second level of components. That would be quite helpful, but it’s also
unlikely that the supplier will give you an SBOM for each of the first-level
components, since they often won’t be available from the second-level suppliers
(most of which are probably open source communities). Again, something is
better than nothing. Having the first-level SBOM and even a few second-level SBOMs
is better than what you have now for almost all of your software: no SBOMs at
all.
The second use case is reducing
procurement risk – i.e. reducing the risk that you will purchase a product whose
supplier doesn’t have a good program for vulnerability management. Notice that
I don’t say “a product that is free of vulnerabilities”. Yes, it’s a good idea
to ask for an SBOM for a product you’re considering for purchase, then check each
of the components in the NVD, to see if there are any serious open
vulnerabilities applicable to them (you can define “serious” as you like, but a
CVSS score of 7.0 or higher counts as serious in my book. And there could be
lower scores that still might be considered serious, if accompanied by other risk
factors. If you decide to purchase the product, you should require the vendor,
in the purchase contract, to patch any serious component vulnerabilities,
unless they say that the vulnerability isn’t exploitable.
However, vulnerabilities appear
all the time. Just because you buy a product that’s free of serious vulnerabilities
on Monday, this doesn’t mean that on Tuesday, five serious vulnerabilities in
components won’t be identified. Often, this is because a researcher just
discovered that a certain string of code, previously thought to be perfectly
safe, can be exploited in a particular way so that bad things happen – and five
of the components of the product happen to have that same code.
What’s most important for
procuring secure software is the track record of the supplier. If you can get a
current SBOM for the product (and hopefully at least a few previous SBOMs, say at
least one for every six months), you can answer questions like:
1.
Does this supplier let
components in their product get very long in the tooth before replacing them? If
there are a lot of components that are 2-3 years old, or maybe five or six
versions behind the current version, this should be cause for concern.
2.
If a serious
vulnerability is identified in a component, on average how long does it take
the supplier to replace it (this question might be hard to answer, unless you have
an SBOM for every 2-3 months in the past. You may not get those, but it
certainly wouldn’t hurt to ask for them)?
3.
Are there any open
source components that are effectively end of life, since the community that
supports the component is no longer providing patches or updates? This is a big
problem. Unfortunately, there’s no gun that goes off to let you know that an
open source component is EOL. To learn this, somebody (and there are services
that do this) needs to watch activity in the project and raise a flag when
there’s been no new activity for say six months. Another indicator is that
there are serious vulnerabilities that haven’t been patched, months after they
were identified.
4.
Does an important open
source component suffer from the “Nebraska problem”, described by this famous cartoon? The cartoon illustrates the risk
posed by an important open source project that is now dependent on a “single
maintainer”. Again, there are services that will do this, but you can also check
for “commits” to the project on GitHub. If only one person has committed for
say six months or more, you should at least have a conversation with the
supplier about this. You might also put a term in the contract that they will
replace this component within say six months.
There are lots of other questions
you can ask as well, that having SBOMs will help you answer when doing your due
diligence for procurement.
The third use case is probably the
most important: ongoing vulnerability management for software operated by your
organization. This includes a) getting regular SBOMs from your suppliers (say,
at least for every major new version, and hopefully every time there has been any
change in the software, including just applying a patch); b) keeping a running
list of the components in each product; c) regularly checking in the NVD for vulnerabilities
that apply to those components; d) adjusting the list of vulnerabilities for
any notifications received from a supplier that a component vulnerability isn’t
exploitable in the product itself (i.e. the type of notification that a VEX
would provide); e) asking the supplier when they’re going to patch any serious
component vulnerabilities that are exploitable in the product; and f) confirming
that the supplier keeps any promises they make regarding patches.
This is obviously the most time-consuming
use case, since it needs to be conducted day in and day out, for as long as
your organization operates software (i.e. up until the day you decide computers
aren’t worth it, and just buy a bunch of typewriters and postage stamps. At
that point - but only then - you can bid farewell to SBOMs). However, this is
also the use case for which you’ll be able to find service vendors that will
perform these tasks for you, as well as perhaps other risk management tasks that
you hadn’t thought of.
Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they shared by the CISA’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. 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] Of
course, the answer to that question is “Definitely!” If there are an infinite
number of universes (which is always the assumption with multiverses, since
there would be no way to limit the number according to any scientific
principle. After all, the laws of physics will be different in each universe in
the multiverse, so you could never identify a constraint on their number), then
there’s definitely one in which the Pope is Jewish, in which I’m rich, in which
Covid-19 never appeared (now, that would be nice!), etc.
No comments:
Post a Comment