Saturday, August 5, 2023

Playing pro ball vs. keeping score at home


As I made clear in this recent post, I no longer think it makes any sense for the end user of a software product or intelligent device to bear the responsibility for analyzing SBOM and VEX information to identify exploitable component vulnerabilities in a product they use. Instead, the supplier should bear this responsibility for five main reasons:

1.      The supplier chose to include the components in the product. They did this because utilizing pre-built components is now the only realistic way to create software, due to the huge savings of money and developer time that result from this practice. While some of the economic benefits of using components accrue to the end users of software because of the overall lower level of software prices that results from this widespread practice, it is hard to deny (at least for me) that the greater part of the benefits of using components accrues to the supplier. This is due to the savings that developers realize through accelerated development time and lower overall development costs.

2.      Currently, there are no tools available to software end users (which I define as consumers of software that are not utilizing the software they acquire to create downstream products, but instead utilize it to fulfill the mission of their organization) that are a) free or low-cost, b) commercially supported, c) easy to use, and d) complete[i]. By a “complete” tool, I mean one that:

                           i.          Ingests an SBOM for a particular software product and version, for example version 1.5 of product ABC;

                          ii.          Resolves any component naming issues, meaning it identifies a valid CPE or purl identifier for every component listed in the SBOM. Learning just the common name for a component is close to useless for a user concerned about component vulnerabilities in the software they use. Identifying a valid CPE for a component requires manual searching, fuzzy logic, dumb luck, etc. Identifying a purl for an open source component should be straightforward if the repository or package manager is known, along with the product name and version string registered in that repository. However, these should always be verified by the product supplier before including them in an SBOM);

                         iii.          Looks up each component CPE or purl in a vulnerability database like the NVD or OSS Index and includes every identified component vulnerability in a list of vulnerabilities found in ABC v1.5. Each vulnerability on the list is initially assigned an exploitability status of “under investigation”;

                         iv.          Repeats these lookups at least daily, adding any newly identified component vulnerabilities to the list with the “under investigation” status;  

                          v.          Receives VEX information from a supplier, either in the form of machine-readable documents or using an API that retrieves the information from a VEX server. VEX information consists of a) exploitability status for every vulnerability in the list for ABC v1.5 (“affected”, “not affected”, “fixed” or “under investigation”), b) a status justification for every “not affected” status designation, and c) mitigation information (e.g. patch or upgrade information) for every “affected” status designation;

                         vi.          Continually uses new VEX information to update the vulnerability list for ABC v1.5;

                       vii.          On demand from the user of the tool, provides a list of exploitable component vulnerabilities (i.e., those with “affected” status) in ABC v1.5, as well as mitigation information for each one (which is also retrieved from the VEX server)[ii]. The list can be provided in either a generic format or in a format required by a particular vulnerability or configuration management tool; and

                      viii.          Continues this process for ABC v1.5 until the user upgrades or removes the product from their network. If the user upgrades to ABC v1.6, the process will start over with step 1 above. If the user still has any instances of ABC v1.5 running, the tool will maintain the component vulnerability lists for both v1.5 and v1.6. Of course, the tool will be able to maintain vulnerability lists for many different products/versions from many suppliers.

3.      Despite the SBOM Forum’s recent incremental progress in getting NIST (which runs the NVD) to recognize the importance of addressing the NVD’s problems with CPEs, the naming problem is hardly solved. This means that, unless suppliers take it upon themselves to do the work required to identify a CPE or purl for as many components as possible, SBOMs (especially those created through an automated process) will continue to be mostly useless for the purpose of vulnerability management.

4.     VEX information is essential for the component vulnerability management use case, yet suppliers aren’t producing VEX documents for their customers. I know of only one supplier, Red Hat™, that makes documents called VEX available to customers now. However, much though I admire the great work Red Hat does in the area of vulnerability management and reporting (and the work that Pete Allor, Red Hat’s Director of Product Security, does as a member of the CVE.org board), because Red Hat has such a unique business model, the type of VEX documents they now produce would be of limited usefulness to the customers of any other supplier.[iii] Note that, if the supplier were doing the SBOM analysis themselves, they wouldn’t need to produce VEXes, since the exploitability information could just be passed – in any desired format, or even just as a list in an email - from the department that produces it to the department that uses it.

5.     Most importantly, it makes no sense to require that every customer, in order to learn about exploitable component vulnerabilities, perform exactly the same analysis on their own that the supplier should already be performing for themselves. Isn’t the supplier the one that needs to know first about exploitable component vulnerabilities – so they can patch them as soon as possible? Given that they have this information (or should have it), why can’t they just share it with their customers, rather than requiring each one of them to derive exactly the same information on their own?

Fortunately, I think that software users will start requiring that their suppliers perform this analysis and make the results available to them for free – just like they do for patches (suppliers initially resisted the idea of distributing security patches for free as well. That resistance quickly faded when they realized they would end up with exactly zero customers if they didn’t do it).

The suppliers will provide the analysis, although, unlike with patching, this work can be accomplished much more efficiently by third party service providers. Those providers will utilize tooling they have developed for their own use (and not for end users, which means it doesn’t have to be made foolproof or user-friendly. Given some big issues that need to be addressed, such as the naming problem, this is currently the only way to develop such tooling. My guess is it will be years before there will be any true consumer tools available for tracking software component vulnerability status). They will make the results (lists of exploitable vulnerabilities) available to the supplier’s customers for free, while charging the suppliers for their services.

Will the end users need to perform any component vulnerability analysis on their own? They will need to in cases where:

a.      The supplier simply refuses to pay a third party to perform the analysis, but cannot or will not perform it themselves; or

b.      The organization doesn’t trust the third party service provider to perform the analysis properly and wishes to do it themselves; or

c.      Someone at the user organization simply enjoys performing the analysis on their own (maybe utilizing open source tools they’ve chained together).

Thus, the “professionals” in the software component vulnerability analysis world will be the third parties that specialize in performing these services for suppliers. The organizations that perform the services on their own will be “keeping score at home” (not that there’s anything wrong with that, of course).

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] Steve Springett, the leader of the Dependency-Track project (as well as the CycloneDX project), showed me this week that D-T has all the capabilities required to be a complete tool, but they aren’t explicitly tied together to do that. I will work with him to explain the use case I have in mind, so D-T (which is already used 10 million-plus times per day to look up vulnerabilities for components listed in an SBOM) can truly be the first complete SBOM/VEX analysis tool. 

Steve and the CycloneDX project team are also working on a format-agnostic BOM exchange API called Project Koala. I believe (and hope) that this API will also ingest VEX information retrieved from a VEX server, since I no longer believe that VEX information will ever be shared in any quantity through machine-readable VEX documents, at least for software component vulnerability management purposes.

 

[ii] Of course, the tool will track the status of every component vulnerability listed for the product, not just those with “affected” status. The user will be able to obtain the complete list at any time, including component vulnerabilities with “not affected” status.

 

[iii] They are only producing one VEX document a year for a product, usually around July 1. However, to be truly useful, VEX information has to be updated at least daily, which is why I am pushing the idea of the VEX server.

No comments:

Post a Comment