Vulnerabilities handling at Jahia

November 20, 2023

Some context on 3rd party libraries

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 customer’s implementations, for example when the next version of a particular library is introducing 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, ...

Security vulnerabilities

Nevertheless, and disrespecting of Jahia’s roadmap for a particular library, we constantly scan our codebases and their dependencies for known security vulnerabilities. We implemented tooling and processes to handle the discovery of a new vulnerability (we currently use dependencytrack to centralize results).

Every week, our security lead will meet with our delivery managers to discuss new non-critical vulnerabilities made public during the week (critical vulnerabilities are escalated right away).

These vulnerabilities are reviewed, analyzed, and assessed against a risk management framework (scoring elements such as threats to confidentiality, integrity, and availability). From there, a decision is made regarding the handling of that vulnerability:

  • If Jahia is deemed exposed, a specific process is triggered, assembling stakeholders at multiple levels of the company and resulting in a security patch being issued.
  • If Jahia is deemed not exposed, the team will evaluate our ability to upgrade the library to a more recent version and prioritize its upgrade in our roadmap.

These processes are audited every year in the context of Jahia ISO 27001 certification.

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, earlier this year 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, 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.

Long term approach

We are currently working on improving our communication around vulnerable libraries. However, as with any security analysis, we are very cautious not to increase our customer’s exposure by publicly communicating our analysis.

We are also reflecting on providing a precise software bill of materials (SBOM), that would only contain libraries we use at Jahia runtime (less false positives), as well as a VEX report containing our analysis, this is currently in our security roadmap but this is a complex item to implement.

Overall, we are confident that the tooling and processes we currently have in place ensure our team is alerted about public vulnerabilities and that these vulnerabilities get regularly analyzed by our team. But if you have any source of concerns about a particular vulnerability, we encourage you to contact our team and we will be happy to provide more details about its potential impact (or lack thereof) on your environment.