Vulnerabilities handling

Overview

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, discovered internally or vulnerabilities for which a fix is still in progress (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.

Risk Assessment

Early on in the processing of a vulnerability, a risk assessment is performed and is continuously revised throughout the lifetime of the vulnerability. This risk assessment is a key factor to help us determine the level of urgency and criticality of a vulnerability.

Although the exact details of this process will not be shared publicly, as part of a security incident (such as a vulnerability) each associated risk will be identified and evaluated on three threats:

• Confidentiality: a risk on the data hosted on the platform, could the vulnerability result in data leaks
• Integrity: a risk for the data itself, could an un-authorized individual modify data (create/edit/delete) or system elements (configuration)
• Availability: a risk for the platform to become unresponsive, DoS (Denial of Service) attacks typically fall in this category

These three threats are not mutually exclusive, for example, a vulnerability introducing a risk on data integrity could result in making a platform unresponsive. 

Finally these threats are evaluated against their likelyhood, all these four components help us give the vulnerability a risk level, and determine the response we will adopt. 

Communication

We will not communicate publicly about a vulnerability until a fix and/or mitigations are available and detailed in a security advisory page.

We always aim provide advance notice to our customers to give them time to take corrective actions, though we reserve the right to accelerate the process depending on the criticality of the vulnerability.

Clarification on Module Checks

Please note that our vulnerability checks are limited to Jahia core and officially supported modules. We do not check for vulnerabilities in:

• Community modules
• Test modules
• Legacy demo modules
• Modules that were previously supported but are no longer supported
• Modules created by our service/support team without product support
• Proof-of-concept modules

Therefore, you must independently verify the security of any modules not explicitly listed as "officially supported."