“None of our products is affected by the log4j vulnerabilities” and other fairy stories

The VEX working group is struggling with a document that makes a number of statements about what should be available in a VEX format (“should” isn’t meant in a regulatory sense, although that fact seems to have been lost on some people). In one section, we describe how a product or products can be identified in the format. One of the options that is currently included in the document is the ability to indicate a supplier name (say, ‘Supplier A’), which would be interpreted to mean, “the set of all products or components produced or sold by Supplier A”. Of course, Supplier A is usually the supplier that created the VEX.

The main reason usually cited for including this capability in a VEX format is because suppliers may want to make a statement like, “None of our products is affected by the log4shell vulnerabilities”. Of course, many suppliers said this in human-readable (or human-audible) form at the end of 2021 and the beginning of 2022. I’m sure it was very comforting for customers of these suppliers to hear they didn’t have to spend nights and weekends trying to figure out whether that supplier’s products, which were installed on their network, contained the Log4shell vulnerabilities.

So, isn’t it reasonable to make that same statement in machine-readable form as well? The point of VEX is that it’s a machine-readable document, even though there are few tools now available to read a VEX, and even fewer that can incorporate the information extracted from a VEX into an ongoing vulnerability management toolchain.

However, here’s the SBOM industry’s dirty little secret (well, one of them, anyway): The big problem with machine-readable formats is that they have to be read by…a machine. Unlike humans, machines take everything you feed them literally; common sense is foreign to them (although that’s also true of a lot of people I know). When making any statement in a machine-readable format, you always need to ask, “How will the user’s tooling interpret this statement?” along with its corollary, “Will the user tool arrive at the same interpretation as would an average human reading the document?

After all, just because a statement seems perfectly understandable when written in English, you should never assume it will be “understood” in the same way by a user tool that interprets a VEX document written in JSON.

Upon scanning the VEX statement “None of Supplier A’s products is affected by log4shell”, a user tool that ingests VEX documents will probably:

1.      Set up a rule to scan the supplier name of any product on the user’s network, to determine whether it matches the supplier name listed for the above VEX statement. Of course, it’s important to note there can be a variety of supplier names, even though the person making the above statement has elided that point in their announcement. For example, someone in the NTIA SBOM initiative once counted 27 different names for Microsoft, that were used by Microsoft employees to identify the company they work for.

2.      Apply whatever rule is set out in the VEX statement to each product whose name matches the supplier name in the statement. In this example, assuming the name of the supplier enunciating the VEX rule was “Supplier A”, the VEX statement might be, “No Version of any Product developed or sold by Supplier A is subject to CVE-2021-44228 or CVE-2021-45046”. In practice, the tool that interprets the VEX statement is likely to treat this as meaning that the status of every product/version pair, whose Supplier is Supplier A, is “not affected”.

Sounds simple, right? Yes, it is - to the computer. But think what it means in practice: This condition will apply to every version of every product whose supplier is Supplier A, no matter how long ago the product/version pair was developed. Moreover, it will apply to every version of every product developed by Supplier A that is acquired in the future – until this VEX statement is overruled by a future statement.

Of course, it may be that the supplier that made this statement intended for it to mean exactly that: Every version of every product they have every produced in the past, or will produce in the future, is not subject to the log4shell vulnerabilities.

However, my guess is that if whoever thought this statement is a great idea goes to their legal department and asks if they concur with that assessment, they may hear something different. They’re likely to be asked questions like:

1.      Have you assessed every product we make or have made in the past, and confirmed that it doesn’t contain any of the vulnerable versions of log4j?

2.      Of course, this also assumes that no component on any “level” of the product contains one of those versions…yea, unto the farthest levels. Have you confirmed this for every one of these products and versions, both past and present?

3.      Have you put in place sufficient controls on product development and product acquisition to ensure that no version of any product we develop or acquire in the future will ever contain one of the vulnerable log4j versions?

4.      Similarly, do you have controls in place to ensure that no component of any version of any product we develop or acquire in the future will ever contain one of the vulnerable log4j versions?

Finally, if I were one of these lawyers, I would ask,

1.      Will you personally indemnify the organization if it turns out that any current, past or future product of ours contains a vulnerable version of log4j and we get sued for it, and will you guarantee payment by posting a large bond? If your answer is no,which poses the larger risk to our organization: log4shell or you?

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.