The mission of this group is to bring together utility professionals in the power industry who are in the thick of the digital utility transformation. 


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

Tom Alrich's picture
Supply chain Cyber Risk management - emphasis on SBOMs and VEX documents, Tom Alrich LLC

I provide consulting services in supply chain cybersecurity risk management and am now primarily focused on software bills of materials (SBOMs) and VEX (Vulnerability Exploitability eXchange). I...

  • Member since 2018
  • 387 items added with 129,274 views
  • Feb 6, 2023


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?
  2. If you answer yes to the above question, is this to indicate you have a good sense of humor?

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

Paul Korzeniowski's picture
Paul Korzeniowski on Feb 27, 2023

Good points. My sense is part of the disconnect stems from the fact that most folks do not understand how computers function. Regardless of how complex their processing seems to be, somewhere, someone wrote software to perform a certain task. They used their own perceptions and prejudices. Consequently, under no circumstances does the output become perfect. Energy companies have to understand that as they put technological advances into effect in their organizations. 

Tom Alrich's picture
Tom Alrich on Feb 27, 2023

Yes, what surpises me most is people who are supposedly technical heaviweights seem to believe that computers are more or less human beings that will do what you tell them to do, no matter how ambiguous you make it.

Tom Alrich's picture
Thank Tom for the Post!
Energy Central contributors share their experience and insights for the benefit of other Members (like you). Please show them your appreciation by leaving a comment, 'liking' this post, or following this Member.
More posts from this member

Get Published - Build a Following

The Energy Central Power Industry Network® is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.

If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.

                 Learn more about posting on Energy Central »