Tuesday, May 23, 2023

Is it time to “declare victory and leave” SBOMs?

                       

                              

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