Digital Utility Group
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.
Post
Something else that would have helped with log4j
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 tom@tomalrich.com.
[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.
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.
Sign in to Participate