The “fall of Saigon”, April 29, 1975
In 1966, as the US rapidly
increased its involvement in the Vietnam War (or the “American War”, as it’s
known in Viet Nam), Senator George Aiken made a statement about what the US could
do to extricate itself from the conflict - without being seen to abandon our
allies, the South Vietnamese government. While the statement
was long and nuanced, it got shortened in the popular imagination to something
like “declare victory and leave”. And in 1975, we did exactly that – minus the “declare
victory” part, of course.
I was reminded of that statement while
participating in editing one of the documents being produced by the CISA SBOM
working groups (in this case, the document was about VEX). I pointed out to one
of the leaders of the VEX group in a comment that there are currently no
consumer tools that can produce what I consider to be the Holy Grail of the SBOM
vulnerability management use case: a continually updated list of exploitable
component vulnerabilities in a particular version of a software product, based
on analysis of SBOM and VEX documents. That means that the main tool available
for using SBOM and VEX documents currently is a JSON reader, which will simply display
the content of the document in English.[i]
What bothered me was that this
person – a leader of more than one of the CISA working groups – thought it was
OK that most software users aren’t going to be able to do anything more with SBOMs
and VEXes than read them in English.
Of course, it’s nice to be able to
read machine-readable documents in English – don’t get me wrong. However, I
consider that an admission of defeat. If the only thing the supplier is going
to achieve by producing a machine-readable SBOM or VEX document (whether in
JSON or XML) is to let their customers read it in English (or whatever language
they know how to read), why are they bothering to put out the document in the
first place? Instead, the supplier could implement the following high-tech solution
for getting SBOM/VEX information out:
1.
Put the SBOM or VEX
information (regarding a particular product/version) in a single English Word™ document;
2.
PDF the document;
3.
Create an email
addressed to all customers of the product; and
4.
Hit Send (this is the
part I sometimes forget).
Can you remember that? I can
assure you it’s a lot easier than what you have to do to create a
machine-readable SBOM or VEX, only to send it out to your customers and have
them read the document in a JSON reader as if it were a…well, a PDF file.
Why is it that we don’t have consumer
tools that ingest SBOMs and VEX information and output lists of exploitable
component vulnerabilities in a product/version? Is it really that hard to do
this? The answer is no, it isn’t that hard to do it in principle. However,
in practice there are two serious problems that are gumming up the works for anyone
who’s even thinking of creating a consumer tool today. These are the naming
problem and confusion
over VEX. While neither of these problems can be “solved” in the near term,
they can both be improved upon to the point where I think real SBOM/VEX
consumption tools will be possible by the end of this year.
However, note I said “tools” will
be possible, not “consumer tools”. The latter have to be brought to the level
at which they can be used by people (such as me) who don’t particularly enjoy
having to figure out tough technical problems on a daily basis – as would currently
be the case with an SBOM/VEX consumer tool, due to both the naming problem and
VEX confusion.
Fortunately, I believe that software
users who are concerned about cyber threats lurking in components of the
software products (and intelligent devices) they depend on won’t be faced with
the stark choice between not knowing anything about those threats and having to
devote significant amounts of time every day to troubleshooting various open
source tools they’ve assembled, while trying all along to get the tools to play
nicely with each other.
Instead, I think that third party
service providers will appear (perhaps as transformations of existing vendors)
that will a) have the expertise and time required to assemble, operate and
support the open source toolchains needed to achieve the “holy grail” service I
described above, and b) be able to develop a large customer base, so that the
time and money required for this service can be easily amortized over many users.
I think that at least one or two
of these service providers will be serving customers by the end of the year.
Moreover, I believe that for the next 2-3 years, it is unlikely there will be
any complete consumer SBOM/VEX consumption tools available. Instead, the service
providers will be the only way that software users can track component
vulnerabilities in products they utilize.
Let’s have no more talk of JSON
readers. They smell of defeat.
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]
There are multiple tools, including Dependency-Track,
that can ingest an SBOM and look up vulnerabilities for components in a
vulnerability database like the NVD or OSS Index. However, no tool takes the
next step and utilizes VEX information (contained either in one of the two
current VEX document formats, or in the VEX API that I’m pushing and hope will
be available by the end of this year) to distinguish the approximately 5% of
component vulnerabilities that are exploitable from the 95% that are not.
No comments:
Post a Comment