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.
No comments:
Post a Comment