In yesterday’s post, I started what will most likely be a long series of posts on what I’ve learned about SBOMs recently. This is the second in that series.
Of course, before I start writing a lot of posts, I need to
tell you why I think SBOMs are an important topic you should know about (if you’re
in any way involved with cybersecurity), vs. say new developments in beekeeping.
Here is the way I see it:
·
According to a 2020 report
by Sonatype, the average software product has 135 components included in it.
·
If we assume that any software (whether a
component or an end user product) has a probability X that a vulnerability will
be identified in it in a given year, then the probability that a vulnerability
will be identified in any component is also X. This means that the probability
that a component of a product will develop a vulnerability is 135 times the
probability that the product itself will.
·
However, the vast majority of vulnerabilities in
components don’t end up being exploitable in the product itself, for various
reasons (e.g. a library has three modules, but only two of them were incorporated
into the product – and the vulnerability was in the other module). Veracode
estimated recently that around 5% of component vulnerabilities are actually
exploitable, meaning that the probability that a component will develop a
vulnerability is about seven times the probability that the product itself
will. While this is better than 135 times, it still means that component
vulnerabilities are seven times as much of a threat as are product
vulnerabilities themselves.
·
This wouldn’t in itself be a huge problem. It
means you would have to spend 7 or 8 times as much time patching or mitigating vulnerabilities
in components as you now spend addressing product vulnerabilities, but in
principle it could be addressed by hiring more warm bodies. However, the
problem is that in many cases, you will never hear about the component
vulnerabilities.
·
In fact, a 2017 Veracode study
said “A mere 52 percent of companies reported they provide security fixes to
components when new security vulnerabilities are discovered. Despite an average
of 71 vulnerabilities per application introduced through the use of third-party
components, only 23 percent reported testing for vulnerabilities in components
at every release.”
And here is the problem: While there are certainly many
software suppliers who make sure to patch (or otherwise mitigate)
vulnerabilities in components, half of them don’t do that. And it’s highly
unlikely those suppliers will even tell you about the component vulnerabilities
they haven’t patched, so you could at least take some action on your own to
mitigate them. You just won’t know about them, period.
Enter SBOMs. If you have an SBOM that shows the components
of a software package your organization has installed on its network, you can
then keep an eye out for vulnerabilities in those components. Currently, you’ll
probably have to do that manually, but in the near future there will be services
that will do this for you. That is, they will:
1.
Ask you up front to provide them a list of
software packages, which you want to monitor for component vulnerabilities.
2.
Receive current SBOMs from suppliers (since an
SBOM needs to be updated whenever the software changes, or whenever a component
changes) and identify vulnerabilities that apply to the components.
3.
For each software package that you’ve listed,
provide you a list of the components[i]
in it, along with any vulnerabilities identified in those components (of
course, this information would need to be regularly updated).
Sounds pretty simple, right? Just three steps! However, I’m 99%
certain that currently no such service exists, mainly because very few
suppliers are providing SBOMs now. So how can we get suppliers to start providing
SBOMs? Beat them over the head with sticks? Threaten to throw their CEOs in
jail? Clearly not. Suppliers will provide SBOMs when it’s clear to them that
their customers are demanding them.
But how can customers demand SBOMs if they don’t know what
to ask for or how they will be able to use them? It seems clear to me that both
the software suppliers and the software consumers need to work together to
figure this out. That’s what the NTIA does, as described in my previous post. They
do it through conducting proofs of concept for particular industries, including
(hopefully) the power industry in the near future.
But the lack of SBOMs is far from the only problem that needs to be addressed, before SBOMs are freely available and usable. I'll discuss other problems in further posts, coming soon to a blog near you.
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]
Initially, it will be very hard to get anything other than a two-level SBOM;
the first level is the software package itself and the second is its immediate
components. It will be a while before you will be able to see the components of
those components, the components of the components of those components, etc.
The holy grail would be to have a nested list that you could expand until you
reached components that themselves have no components. But that’s probably
impossible in any practical sense, since almost all software has components.
And frankly, the farther down you go in the tree, the lower the likelihood that
a vulnerability in a component will be exploitable in the software you’re
running on your network. So it’s probably not likely that anyone would invest
resources in going down more than say four or five levels. However, just having
a two-level SBOM is challenging enough nowadays. Once that problem is nailed in
say 5-10 years, we can worry about more levels.
No comments:
Post a Comment