3rd party libraries

Context

As with the vast majority of modern software projects (if not all), Jahia depends on 3rd party libraries for its operation. The choice to integrate a 3rd party library is never taken lightly, the product team always ensures that a candidate library can demonstrate a certain degree of community adoption, is meeting basic Open-Source project criteria, and shows signs of maintainability in the long term.

Throughout its lifetime, a 3rd party library is likely to go through various stages of development, with multiple releases, discovered vulnerabilities, and sometimes, end-of-project maintenance. Once a 3rd party library is integrated into Jahia, the product team will, based on various triggers (such as the need for a new feature or a bugfix, security vulnerability, addressing technical debt, …), upgrade 3rd party libraries to more recent versions.

Upgrading a 3rd party library version is not necessarily easy and the need for such a change is always weighted against our customers' needs and the overall product roadmap.

Changing the version of a third-party library can have a significant impact on our customers' implementations, for example when the next version of a particular library introduces breaking changes. There are also situations in which updating to a newer version of a library is not necessarily relevant for the product; for example, if the library is integrated into part of the codebase due to be refactored, if the timing is not appropriate (requiring a new major Jahia version soon after the previous one), if the team is considering moving to an alternative library, ...

False positives in 3rd party libraries

A vulnerability in a 3rd party library is always a source for concern, but such a vulnerability does not always translate into the product using that library being itself vulnerable. In some instances, there are safeguards in place or documented best practices to prevent that vulnerability from spreading to the parent project.

For example, in 2023, we reviewed a high score CVE-2023-39017 impacting Quartz < 2.3.2. This vulnerability is only impacting Quartz JMS, a feature of Quartz that Jahia itself does not use, yet the whole library is marked vulnerable. Yes, Jahia uses this version of Quartz but Jahia is not impacted since the JMS feature is not used.

There are other situations when a 3rd party library is needed for building the product, but is not used at runtime. For example, we use a particular solr-core utility function for our faceting search, at the time of writing, that version of solr-core has 13 vulnerabilities, but a Solr server is not started nor are other solr libs deployed. After investigation, it was confirmed that Jahia was not exposed to these particular vulnerabilities.

Finally, and especially with Javascript libraries, false positives are sometimes detected in transitive dependencies (a dependency of a dependency), with situations where the vulnerable dependency is declared into the “yarn.lock” but does not even make it to our built artifacts (and neither to Jahia runtime).

When dealing with false positives, it’s always in our best interest to upgrade libraries to more recent versions (without vulnerabilities), but this is weighted against other items in our roadmap considering that in this particular situation, the main benefit (aside from addressing technical debt) is for not having these show up in external vulnerability reports.