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. 


Something else that would have helped with log4j

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
  • 427 items added with 154,788 views
  • Dec 27, 2021

There have been a number of good email discussions on log4j in the mailing lists of the NTIA Software Component Transparency Initiative (these will be replaced by another list under CISA’s auspices soon). Last week, the discussion in one list veered into how the National Vulnerability Database (NVD) doesn’t provide a lot of help on the log4j problem, because the vulnerability was just located in one component module of Log4j, called log4j-core.

There are potentially lots of components in log4j[i] (here is a list of them all), but they’re never all installed at once. What’s installed will vary according to the version of log4j, as well as the needs of the software developer that included log4j in the product they were developing. To quote Steve Springett of OWASP, co-leader of the CycloneDX SBOM format project, and leader of the Dependency-Track project:

Not all modules will be vulnerable. Take a common scenario that occurred over the last week. Many organizations that rely solely on the log4j-api module needlessly upgraded even though they were not affected. Only log4j-core was impacted. Log4j-core has a dependency on log4-api, but not the other way around. So if you’re only using the API and not the core logging functionality, there was no reason to upgrade.

In other words, if it had been possible to learn from the NVD that only the log4j-core module of log4j was affected, that would have saved a lot of people a lot of time (and heartburn) searching for and patching log4j in products that didn’t include log4j-core at all. How would it have been possible to learn this? To simplify things greatly, if the NVD could ingest SBOMs and associate the components of a software product with the product itself, then vulnerabilities that apply to a component of a product could be seen as applying to the product itself.[ii]

However, the logistics of implementing this capability would be formidable, in no small part because the number of entries in the NVD would increase at least 20-50-fold, and the possible relationships among entries would increase exponentially. So don’t look for this to happen very soon[iii]. Until it does, you’ll have to rely on the supplier that developed the software product you run, to tell you whether or not that product is affected by a vulnerability, no matter what “tier” of components it’s on.

And if the supplier tells you they just don’t know this and you’ll have to figure it out for yourself, well…you might want to look for a different supplier. This isn’t an acceptable answer (more on this topic coming soon to a blog near 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. Nor are they shared by the CISA’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. If you would like to comment on what you have read here, I would love to hear from you. Please email me at

[i] And remember, log4j is itself a component of other products, so these are components (also called dependencies) of a component, which are sometimes referred to (not completely accurately) as “second-level” components. As a frequent abuser of this term, I can only defend myself by saying it does help you visualize the idea of “nested” components, at some loss of accuracy. However, Steve Spingett’s comment provides an example of where the idea that components are all nestled in neat little levels breaks down, since he mentions that log4j-api can sometimes be a component of log4j-core, but not the other way around. This means that log4j-api can appear at different levels in different SBOMs – and this applies to every other component as well. In fact, a single component could appear at different levels in a single product, although in general that would be due to a poor development practice.

[ii] Of course, it would be misleading to associate every component vulnerability with the product that contains the component, since a large percentage – certainly more than 50% of component vulnerabilities - aren’t exploitable in the product itself. It would be up to the supplier of each product to provide notifications to the NVD whenever a component vulnerability isn’t exploitable in the product. The NTIA (now CISA) Initiative is working on a format for these notifications called VEX, but it’s possible there will be other formats as well. And I think that there might someday be another framework for vulnerability notifications, in which non-exploitable component vulnerabilities would never appear in the first place.

[iii] Steve also pointed out that the PURL specification does permit components of a product to be associated with the product – he pointed to the Sonatype open source software vulnerability database, which is based on PURL (instead of CPE); he also provided the URLs for log4j-api and log4j-core. Note that I don’t know whether the Sonatype database lets a product “inherit” vulnerabilities from its components, meaning that you can see all of the vulnerabilities that apply to any component of a product, when you view the product itself. I doubt it does that.

Richard Brooks's picture
Richard Brooks on Dec 27, 2021

Tom, this article provides further proof that an automated, programmatic SBOM based vulnerability disclosure reporting standard is needed that works in conjunction with Vendor supplied SBOM's. An open source, free to use SBOM Vulnerability Disclosure Report in XML schema format is available online for all to use and extend as needed.

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 »