Saturday, December 16, 2023

Where’s Henry Ford, now that we need him most?


The OWASP SBOM Forum was formed in early 2022 for the purpose of exploring the reasons why software bills of material are not being used in any significant way among public and private organizations whose primary activity is not software development (they’re being heavily used by software companies, as well as by the software development arms of other companies; moreover, the rate at which they’re being adopted by those organizations is accelerating).

Early on, we identified the two most important reasons for this situation: the naming problem and uncertainty around VEX. More than a year ago, we put out a paper that set out our position on the biggest component (no pun intended) of the naming problem: how to move the NVD beyond the many issues that make it difficult to find a CPE name for a software component listed in an SBOM. We continue to discuss this issue.

This fall, we decided to tackle the issue with VEX:

1.      The concept of VEX (which stands for Vulnerability Exploitability Exchange) was developed by the NTIA Software Component Transparency Initiative in 2020 to address a specific use case. That use case was described this way in the only document on VEX published by the NTIA: “The primary use cases for VEX are to provide users (e.g., operators, developers, and services providers) additional information on whether a product is impacted by a specific vulnerability in an included component and, if affected, whether there are actions recommended to remediate. In many cases, a vulnerability in an upstream component will not be “exploitable” in the final product for various reasons (e.g., the affected code is not loaded by the compiler, or some inline protections exist elsewhere in the software).”

2.      After the SBOM effort moved under CISA in 2022, many more use cases for VEX were entertained by the VEX working group. In fact, the only definition published by the CISA VEX group (in this document on page 2) is “A VEX document is a binding of product information, vulnerability information, and the relevant status details relating them.” In other words, any document that ties vulnerabilities to products in any way is a VEX. Of course, this includes any vulnerability notification ever issued, machine readable or not, as well as any vulnerability notification that will ever be issued.

Leaving aside the question of what value there is in having such a broad definition, what we noticed was that this makes it impossible to have a consumer tool that can even parse a VEX document, let alone utilize the information from the document to advance an organization’s software vulnerability management efforts. The developer would need to address a huge (approaching astronomical) number of use cases, variations on those use cases, and combinations of all the use cases and variations; no developer is interested in devoting the rest of their life to developing a single product, no matter how needed. To quote Frederick the Great, “He who protects everything protects nothing.”

Once you state the problem this way, the solution becomes clear: Focus on just one use case and develop a specification that can be used to design proof of concept tooling for both production and consumption of documents based on that use case. Then build and test the tools, to make sure the production tooling can build documents that will always be readable by the consumption tooling, and that the consumption tooling will be able to read any document produced by the production tooling.

Even though there are a few tools that purport to produce or consume “VEX documents” today, there are certainly none that meet the above test. Once the initial use case has been addressed in this way, it will be possible to repeat that effort for other use cases. This follows the sage advice embodied in the answer to the question of how to eat an elephant: One bite at a time.

For the first VEX use case we’ll address, we chose the one we think is by far the most important: notifying software users that certain component vulnerabilities they may have discovered by running the supplier’s most recent SBOM through a tool like Dependency Track or Daggerboard are not exploitable in the product, even though they’re exploitable in the component considered as a standalone product. This means they pose no danger to the user organization. The fact that there is currently no completely automated way to provide this information to users is inhibiting many suppliers from producing SBOMs at all.

If it were sufficient just to put the VEX information in a PDF and email it to their customers, there would be no need for a supplier to provide the information in a machine readable document. However, given that trying to manage component vulnerabilities “by hand” – e.g., by using spreadsheets – would quickly turn into a nightmare, and that SBOMs themselves are machine readable, the VEX must be machine readable as well.

However, that’s hardly all that’s required. The information from the VEX document must be utilized as part of an automated toolchain that a) starts with ingesting an SBOM and looking up component vulnerabilities like Dependency Track does, b) continuously updates the exploitability status of the component vulnerabilities as new VEX documents are received, and c) on request from the user, provides a recently (at least daily) updated list of the exploitable component vulnerabilities in a format needed to ingest the list into a vulnerability or patch management tool. 

Currently no such tools or toolchains exist, and it will be years before they’ll exist in a form that can be utilized by an end user organization. This is probably due to the need to work around the naming problem and some other issues (suppliers producing SBOMs work around these issues every day. They have to). However, we’re sure that third party service providers will become interested in operating one of these tools as a service to end users, who will just download the data provided in step c) above and not have to worry about steps a) and b) at all.

These service providers will need to benefit from full automation of the above three steps; otherwise, they might not be profitable. This is why having a standard, constrained VEX format is so important; only if VEXes are produced in that exact format, and the consumption tool can be built to expect that format and no other, will it be possible to have true automation.

But standardizing the format alone isn’t enough. The processes followed by the supplier need to be strictly constrained as well. For example, many or most of the components found in an SBOM produced by fully automatic means will probably not have a CPE or purl identifier, yet at the same time, no major vulnerability database is based on any other type of software identifier. This means the supplier should include a CPE or purl for every component listed in the SBOM.

However, that is easier said than done, since in many cases it will not be possible to locate a CPE for a proprietary component[i]. What should the supplier do when they can’t find a CPE for a proprietary component? Should they leave the component out of the SBOM altogether? Should they leave it in, but enter “not available” as the identifier? Should they simply enter whatever identifier they have for the component, in the hope that a user who’s really concerned about looking up vulnerabilities for every component will at least have something to search on?

All three of those answers would probably be acceptable, at least for certain users. There are other questions like this as well. However, we need to answer each of those questions in some way, if we want to make production and consumption of VEX documents a completely automated process.

This is where Henry Ford comes in. In 1908, after having produced fancier (and non-standardized) automobiles for five years, he dropped all previous models and introduced the Model T, a “simple, inexpensive car most people could own.” Initially, the Model T was available in multiple colors. However, in 1914 he introduced a huge gain in efficiency by going to a moving production line. One tradeoff for that was he needed to limit the color options to one (to avoid having to clean the line between producing models with different colors).

In his autobiography published in 1922, he quoted himself as having said in an internal meeting, “Any customer can have a car painted any color that he wants so long as it is black.” There’s no way to prove he actually said that, but the lesson is clear: Automating a process often requires making a seemingly arbitrary choice among equally valid options. You need to stop deliberating and simply Choose One.

That’s how our group can achieve its goal of designing tooling for a completely automated process of delivering and utilizing both SBOMs and VEX documents. While there are many options available for both types of documents (in terms of use cases and variants on those use cases), we need to Choose One and move forward.

It's time to bring SBOM production and usage into the Model T era!

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 lead the OWASP SBOM Forum. If you would like to join or contribute to our group, please go here, or email me with any questions.


[i] Because purl doesn’t require a central database, the supplier should usually be able to create a purl for an open source component.

No comments:

Post a Comment