There has been much written about
software bills of materials and how they will do wonderful things for users – everything
from curing asthma to finding lost car keys. However, a great deal of what has
been written, including (truth be told) some of my posts on SBOMs, has focused mostly
on the ultimate benefits of having SBOMs:
·
You’ll be able to find
and remediate every instance of the next log4j or Ripple20 vulnerabilities that
comes down the pike.
·
When you’re purchasing
new software or intelligent devices, you’ll be able to instantly determine which
of the products you’re considering are “safe” and which aren’t.
·
As you use software,
you’ll be able to learn immediately of any critical new vulnerability in one of
the components of a product you use, so that you can immediately bug your
supplier to get it patched.
I can promise you’ll be able to do
all of these things and more…within the next 5-10 years. But what about the near
term? And if you work for a federal agency, what will you be able to do next
August, with all of the SBOMs that your suppliers will be required to start
pushing your way? After all, an SBOM just lists components. By itself, it doesn’t
give you any information about the risks that apply to those components, the
most important being the risks due to vulnerabilities found in the components.
Of course, when you have the SBOMs,
you’ll then need to go to the National Vulnerability Database (NVD) and find all
of the vulnerabilities that apply to components. Without a low-cost or open
source tool or service to do this for you, you’ll find this involves a huge
amount of drudge work, since you will often have to search for the CPE names of
the components and since the average product has 135 components and lots of
products have thousands of components. Plus, you should really repeat this
exercise at least once a week and hopefully more often, for every software
product or intelligent device on your network.
Fortunately, there is one open
source tool that will do this for you now: Dependency-Track. In addition, there
will be at least one or two low-cost services available in the next few months,
to do what that tool does. And if open source isn’t your cup of tea, there are commercial
tools that will do this, ranging from not-too-expensive to quite expensive.
However, there’s another thing
that’s needed: Because the great majority of component vulnerabilities aren’t exploitable
in the software product itself, you’ll waste a lot of time (and you’ll waste
the supplier’s time) trying to find component vulnerabilities that aren’t
really there, even though the NVD swears up and down that they’re in the
components. You need to learn which component vulnerabilities aren’t in fact
exploitable in the full product.
This is what VEX
documents will do. They will be available by this summer, but you’ll need
to have a tool or service that will be able to ingest and interpret them (and don’t
even think about processing VEXes manually. You’ll go mad), then prune the list
of component vulnerabilities in the products that you use down to the 5-10% that
are exploitable.
This list is what you really need. How many tools (whether open
source or commercial) or low-cost services will do all of this for you today?
Zero, although I know there will be at least one service and at least one open
source tool (Dependency-Track, again) that will do that by the summer, when
SBOMs should start being more available, thanks to Executive
Order 14028.
What’s the moral of this story? The
big need now isn’t for SBOMs. Software suppliers are already producing them in large
quantities for their own component risk management purposes (the suppliers know
how valuable they are!). But at the moment, they’re not sharing them with their
customers, because the customers aren’t asking for them. And why aren’t the
customers asking for them? It’s probably because they don’t have tools or
services available to make use of them.
So the SBOMs and VEXes themselves do
you no good. They’re merely steppingstones to what you really need: a list of exploitable
component vulnerabilities in the software you use. Both the services and the
tools will get you that list, without your even having to see an SBOM or VEX,
let alone manipulate it in some way.
Now, I’ll be the first to admit
that it will be years before you have a complete, daily-updated list of all the
exploitable component vulnerabilities in all of the software you use. On
the other hand, the list you do have – say - six months or a year from now will
be a lot more useful than the empty list you currently have.
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.
No comments:
Post a Comment