Noted power industry cybersecurity
consultant Patrick Miller recently put up a blog
post consisting of a recorded interview and transcript of a discussion of
software bills of materials. He did a good job of articulating the most
important argument for having SBOMs: they will allow software users to find out
about dangers lurking in components of the software they run, vs. being totally
blind to those dangers.
However, Patrick gets off track
when he discusses how the users will actually learn about those dangers, in
this passage:
PATRICK:
Effectively what happens is (the
users) take (the SBOM) from the manufacturer, they use a tool to compare the
two, and they know what's in there. They can say, 'Yes, all the things we
expect are in there and nothing else is in there. They didn't insert garlic
into my soup and now I'm going to get sick,' for example.
GAIL:
As part of the critical infrastructure,
I ask for the SBOM, the manufacturer produces an SBOM, I run my tool against
what they've given me, and it comes back a little different. What happens then?
PATRICK:
Well, that's when you have a risk.
You have to have the conversation with the vendor to find out: did you actually
get what you expected?
In some cases, there are things
like file integrity and certificates that can go a long way to helping this. In
some cases, it may just be that there's a mismatch in the tools. But that's an
interesting conversation for you to have with your vendor and should be the
first thing you do if things don't match up. You need to talk to your vendor
right away, because things should line up.
I think
Patrick is describing a sequence like this:
1.
The user receives software
(either new or an update to software they’re already using); the supplier
provides an SBOM with it.
2.
As a check on the
supplier, the user uses a binary analysis tool to create an SBOM from the
delivered software binaries (this isn’t an easy thing to do for various
reasons, but it’s possible for someone with the right software development
experience).
3.
The user compares the
SBOM they received from the supplier to the one they created and looks for
discrepancies.
4.
If they find a
discrepancy, the consumer talks with the supplier to find out whether this was
due to an innocent mistake, or whether it was a deliberate attempt to hide something
– perhaps there’s a vulnerable component in the software and they don’t want
the customers to know about it?
However,
this sequence simply couldn’t happen, for several reasons. First, SBOMs are
almost all generated by automated tooling on the supplier side, usually as part
of the software build process – and I’m talking about machine-readable SBOMs, which
are the only ones that scale. There are single software products, including one
that’s installed today on millions of corporate desktops across the US, that
have upwards of 5,000 components; the average product contains over 100 components.
It’s kind of hard to create those SBOMs by hand. While it would certainly be
possible to edit the JSON or XML code that constitutes the SBOM after it’s been
produced, it wouldn’t be easy.
More
importantly, it’s just about 100% certain that there will be a mismatch between
an SBOM produced from binaries (as in step 2 above) and one that’s created with
the final software build, without the supplier having to obfuscate anything.
There are various reasons for this, including that there are almost always
other files or libraries that aren’t part of the software as built, but that
are essential for it to run; the binary analysis will capture these files, as
well as those for the “software itself” (and unfortunately, the fact that SBOMs
created from the build process don’t include files installed with the software
means that the SBOM your supplier sends you will almost always leave out these
additional files – and therefore you won’t learn about vulnerabilities in those
files. This is an ongoing problem with SBOMs, although it’s certainly not a
fatal one).
A bigger
reason is the one I alluded to in step 2 above: creating SBOMs using a binary
analysis tool is always going to be much harder than creating one through the
build process, since the output from the tool will inevitably miss a lot of components
and misidentify others. That’s why there is a lot of judgment required to clean
up the output from the tool; and even after applying that judgment, the resulting
SBOM will virtually never match an SBOM produced from the final build.
Binary
analysis is required in order to learn anything at all about the components of
legacy software, for which no SBOM was produced at build time (i.e. just about
all legacy software today). It’s like a colonoscopy: It has to be done, but it
certainly isn’t a lot of fun.
More importantly,
if the supplier decides to alter one SBOM (perhaps by renaming a few vulnerable
components with the names of non-vulnerable components), they are going to have
to replicate this work in future SBOMs for the same product. A new SBOM needs
to be generated with every change to the software, which means with every new
version and every patch application. The devious supplier will have to make the
same change in all of these new SBOMs.
But the biggest
reason why Patrick’s scenario is highly unlikely is this: Why should the
supplier go to a lot of trouble to obfuscate vulnerable components, when virtually
any SBOM you look at has vulnerable components (i.e. components for which one
or more open CVEs are listed in the NVD) – and it’s certain that new vulnerabilities
will be identified in those components in the future?
The
problem isn’t so much that there are vulnerable components. The real question
is how the supplier deals with component vulnerabilities, whenever they appear.
A 2017 study
by Veracode stated “A mere 52 percent of companies reported they provide
security fixes to components when new security vulnerabilities are discovered.”
I would hope that number would be higher nowadays, but one thing is certain: It
will definitely be higher, once most software suppliers are distributing SBOMs
to their customers. Components in the software will have fewer vulnerabilities,
plus suppliers will work to patch those vulnerabilities more quickly than they
would have otherwise (if they would have patched them at all).
Is this
because the suppliers have all just experienced a Road to Damascus moment, and
decided to completely change their former ways? No, it’s because it’s human
nature to pay closer attention to doing your work correctly when somebody is
looking over your shoulder. That’s why the SBOM effort by NTIA (and now CISA)
is called the Software Component Transparency Initiative. It’s all about
transparency.
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.
No comments:
Post a Comment