ELS pour Apache Velocity : assurez la sécurité de votre système après la fin de vie du produit

Principaux enseignements

• Les dépendances multiplient votre surface d'exposition aux risques : Le risque lié à la fin de vie de Velocity peut s'étendre au-delà des fichiers JAR du moteur et des outils pour toucher des dépendances d'exécution vulnérables telles que commons-collections 3.2.1 et, le cas échéant, Log4j 1.x.
• Les migrations précipitées sont coûteuses et risquées : Accélérer la migration de la version 1.7 d'Engine vers la série 2.x sous la pression des délais de mise en conformité revient à troquer un risque de sécurité contre un nouveau risque de régression.
• La fin de vie (EOL) d'Apache Velocity ne signifie pas nécessairement la fin de la sécurité : TuxCare ELS assure la poursuite de la couverture des correctifs de sécurité pour les versions de Velocity en fin de vie, pendant que vous planifiez une migration contrôlée selon votre propre calendrier.

Si Apache Velocity figure quelque part dans le graphe des dépendances de votre application Java – ce qui reste courant dans les anciens environnements Java d'entreprise –, il est utile de prendre connaissance de son statut de fin de vie (EOL) avant qu'un scan de sécurité ou un audit de conformité ne vous oblige à aborder le sujet.

Velocity Engine 1.7, dernière version de la série 1.x, n'a pas fait l'objet d'une nouvelle version en amont depuis novembre 2010. De même, Velocity Tools 2.0 n'a pas connu de nouvelle version depuis mai 2010, tandis que le développement d'Apache s'est poursuivi dans les séries Engine 2.x et Tools 3.x. Les fiches CVE relatives à ces deux anciens composants mettent clairement en évidence la vulnérabilité, et leur utilisation en production sans application des correctifs entraîne de réelles implications en matière de conformité.

Cet article explique ce que signifie concrètement la fin de vie (EOL) d'Apache Velocity, quel est son bilan en matière de sécurité, et comment la solution TuxCare ELS pour Apache Velocity offre à votre entreprise un moyen de préserver sa sécurité sans imposer une migration pour laquelle vos équipes ne sont pas encore prêtes.

Qu'est-ce qu'Apache Velocity, et pourquoi est-il encore si largement utilisé ?

Apache Velocity est un moteur de modèles basé sur Java qui utilise le langage de modèles Velocity (VTL), permettant aux développeurs d'intégrer des directives dynamiques dans des modèles au format texte brut. Lors de l'exécution, le moteur Velocity fusionne les modèles avec des modèles de données Java pour produire le résultat final. La séparation entre la présentation et la logique métier a contribué à faire de Velocity une solution de création de modèles largement adoptée dans les applications Java d'entreprise tout au long des années 2000 et au début des années 2010.

Le projet Apache Velocity comprend deux composants principaux, chacun disposant de lignes de versions et d'historiques de publication distincts :

• Moteur Velocity : Le moteur d'exécution principal des modèles, qui gère l'analyse syntaxique du langage VTL, l'exécution des directives, l'expansion des macros et la résolution des variables de contexte.
• Outils Velocity : Intégrations de frameworks Web basées sur l'Engine, notamment VelocityViewServlet pour les applications basées sur des servlets, ainsi que des boîtes à outils pour le formatage des dates, la génération d'URL et des utilitaires courants pour la couche de présentation.

Velocity était profondément intégré à Apache Struts, aux anciennes configurations Spring MVC, à Apache Turbine et aux plateformes CMS Java, où il s'introduisait souvent dans les applications en tant que dépendance transitive à plusieurs niveaux de profondeur. Il est également devenu un choix courant pour les systèmes de modèles d'e-mails et les générateurs de rapports, qui sont rarement modernisés. Cette fiabilité peut créer un angle mort en matière de fin de vie : Velocity reste souvent intégré dans des applications de longue durée précisément parce qu'il continue de fonctionner, ce qui fait qu'on a tendance à l'ignorer jusqu'à ce qu'un scanner de vulnérabilités l'identifie.

Fin de vie d'Apache Velocity : le cycle de vie des versions

Apache Velocity publie ses correctifs via de nouvelles versions, tandis que les versions plus anciennes sont transférées vers les archives Apache. Il est donc essentiel de bien comprendre le calendrier de développement du composant pour évaluer les risques au sein de votre pile technologique.

Velocity Engine 1.7 a été la dernière version de la série 1.x et est devenue la version par défaut de Velocity intégrée à toute une génération de frameworks Java. La série Engine 2.x a introduit des changements d'API incompatibles avec la version 1.x, et de nombreux frameworks en amont n'ont pas mis à jour leur dépendance Velocity figée pendant des années, ce qui a permis à la version 1.7 de rester largement utilisée jusque dans les années 2020. Velocity Tools 2.0 n'a pas non plus connu de nouvelle version depuis 2010 ; ces deux composants ont été remplacés par des versions majeures plus récentes et ne font plus l'objet de nouvelles versions dans leurs séries respectives.

Apache oriente les utilisateurs vers ses versions actuelles et archive les anciennes versions, sans publier de programme de maintenance de sécurité ni de rétroportage de correctifs pour les gammes Engine 1.x et Tools 2.x. Les organisations qui utilisent ces versions se retrouvent ainsi sans source en amont documentée pour les nouveaux correctifs de sécurité – c'est précisément cette lacune que TuxCare ELS pour Apache Velocity a pour objectif de combler.

L'historique des vulnérabilités CVE qui détermine le risque lié à la fin de vie (EOL) d'Apache Velocity

La fin de vie (EOL) d’Apache Velocity ne signifie pas que l’on cesse de découvrir des vulnérabilités dans les versions en fin de vie ; cela signifie simplement que ces versions ne bénéficient plus de correctifs en amont. Les moteurs de modèles peuvent constituer des cibles de choix, car ils traitent souvent des modèles ou des données influencés par les utilisateurs dans le contexte d’exécution d’une application. Dans des configurations vulnérables, des failles au niveau de la frontière entre la logique du modèle et le runtime de l’application peuvent entraîner des conséquences aussi graves que l’exécution de code à distance – et le statut de fin de vie supprime le filet de sécurité que constituent les correctifs en amont contre ce type précis d’attaque.

CVE-2020-13936 : contournement du bac à sable et exécution de code à distance

La vulnérabilité CVE-2020-13936 (NVD CVSS 3.1 : 8,8 – Risque élevé) affecte les versions de Velocity Engine jusqu'à la version 2.2 incluse, ce qui place l'ensemble de la branche 1.x dans le champ d'application de cette vulnérabilité. Un attaquant capable de modifier les modèles Velocity pourrait être en mesure d'exécuter du code Java arbitraire ou des commandes système avec les privilèges du compte exécutant le conteneur de servlets. Cette vulnérabilité d'injection de modèle côté serveur a été signalée par GitHub Security Lab sous la référence GHSL-2020-048, puis traitée dans des avis de sécurité publiés par plusieurs fournisseurs et distributions en aval.

La vulnérabilité CVE-2020-13936 a été corrigée dans Velocity Engine 2.3, publié en février 2021 – plus d’une décennie après la sortie de la dernière version 1.x en novembre 2010. Au moment où cette vulnérabilité a été rendue publique en mars 2021, Engine 1.7 n'avait pas connu de nouvelle version en amont depuis plus de dix ans, et aucun correctif n'avait jamais été publié pour la branche 1.x.

Pour les organisations utilisant la version 1.7 d'Engine, qui a atteint sa fin de vie, les solutions les plus directes consistent à passer à une version corrigée et prise en charge, ou à appliquer un correctif rétroporté fourni par un prestataire tel que TuxCare. Limiter les utilisateurs autorisés à publier ou à modifier des modèles Velocity peut réduire l'exposition au risque, mais ces contrôles ne remplacent pas l'application de correctifs lorsque la fonctionnalité vulnérable reste accessible.

Le risque caché : l'empreinte de dépendance de Velocity

Velocity Engine 1.7 dépend de commons-collections 3.2.1 et de commons-lang 2.4 pour ses fonctionnalités générales d'exécution ; Jakarta ORO 2.0.8 n'est requis que pour certaines fonctionnalités, telles que l'échappement automatique des références. Log4j 1.x est un backend de journalisation facultatif utilisé uniquement lorsque les applications configurent Velocity pour enregistrer les journaux via Log4j. Deux composants de cet écosystème comportent des CVE critiques (CVSS 9,8) :

commons-collections 3.2.1 : CVE-2015-7501 (CVSS 9,8 – Critique). Cette version peut être impliquée dans des chaînes d’exploits de désérialisation Java lorsqu’une application désérialise des données non fiables via un chemin de code vulnérable – il s’agit du même type d’exploit qui avait touché WebSphere, JBoss, WebLogic et Jenkins lors de sa divulgation en 2015. Velocity Engine 1.7 utilise la version concernée, bien que la possibilité réelle d’exploitation dépende de la manière dont l’application environnante gère les objets sérialisés.

Log4j 1.x : CVE-2019-17571 (CVSS 9,8 – Critique). Log4j 1.x a atteint sa fin de vie en août 2015, et l'ensemble de la branche 1.x ne bénéficie d'aucun correctif pour les CVE divulgués par la suite. Les applications qui utilisent Log4j 1.x avec Velocity peuvent être exposées à la vulnérabilité CVE-2019-17571, une vulnérabilité d'exécution de code à distance, si elles activent et exposent le composant SocketServer vulnérable.

Les scanners de vulnérabilités identifient, dans cet arbre de dépendances, des vulnérabilités pour lesquelles il n'existe aucun correctif officiel en amont. La solution TuxCare ELS pour Apache Velocity étend la couverture au-delà des artefacts Velocity de premier niveau pour inclure les composants pris en charge dans l'arbre de dépendances transitives.

Conformité et exposition aux réglementations

Conformément à la norme PCI DSS v4.0, l'exigence 6.3.3 stipule que les correctifs et mises à jour concernant les vulnérabilités classées comme critiques dans l'environnement d'une organisation doivent être installés dans un délai d'un mois à compter de leur publication ; les autres mises à jour de sécurité applicables doivent être installées dans les délais fixés par l'évaluation des risques de l'organisation (conformément à l'exigence 6.3.1).

Étant donné que la norme PCI DSS ne classe pas automatiquement comme « critique » toute vulnérabilité ayant un score CVSS 7.0 ou supérieur, l’impact de la vulnérabilité CVE-2020-13936 – rendue publique depuis mars 2021 – sur la conformité dépend de la hiérarchisation des risques, de l’exposition et des contrôles documentés par l’organisation. D'autres référentiels et programmes d'assurance, notamment HIPAA, SOC 2 Type II et FedRAMP, peuvent également exiger des organisations qu'elles identifient, évaluent et corrigent les vulnérabilités concernées, bien que leurs exigences doivent être évaluées séparément.

ELS pour Apache Velocity aide les entreprises à remédier aux vulnérabilités concernées selon un calendrier prévisible, sans les contraindre à une migration immédiate.

Les risques liés à une migration précipitée vers Apache Velocity

La pression pour réagir aux résultats liés à la fin de vie (EOL) d'Apache Velocity est bien réelle. Les outils SCA génèrent des résultats, les auditeurs posent des questions précises et les délais de mise en conformité ne sont pas repoussés en raison des contraintes de capacité technique. Les équipes qui gèrent efficacement la fin de vie d'Apache Velocity considèrent la migration comme un projet technique planifié, comprenant un inventaire complet des modèles, des tests de régression et un plan de retour en arrière bien défini.

Que se passe-t-il quand on se précipite ?

Lorsque les équipes concentrent la migration sur un calendrier irréaliste, les choses tournent mal, comme on pouvait s'y attendre :

• Augmentation de la charge de support : Les bogues non détectés lors des tests condensés apparaissent immédiatement en production. Les équipes d’assistance sont submergées de tickets concernant des problèmes de rendu des modèles et des changements de comportement dans les pipelines d’e-mails ou de rapports, la plupart étant imputables à des différences au niveau du VTL ou de l’API entre les versions 1.x et 2.x du moteur, qui n’ont jamais été entièrement validées en raison d’un calendrier trop serré.
• Instabilité du système : Certaines modifications apportées aux API de dépendances ne se manifestent qu’en conditions de charge de production. Les échecs intermittents de rendu des modèles, les différences de mise en forme des résultats provenant des boîtes à outils Tools mises à jour, ainsi que le changement de comportement de gestion des erreurs de VelocityViewServlet génèrent tous des défaillances difficiles à reproduire et coûteuses à diagnostiquer.
• Accumulation de la dette technique : Les différences de configuration sont intégrées dans le code d'initialisation de l'application au lieu d'être corrigées au niveau de la bibliothèque. Les changements de comportement de VTL entre les versions 1.x et 2.x sont contournés localement par des moyens non documentés. Le problème de fin de vie (EOL) est reporté, mais pas résolu, et la dette accumulée rendra la migration ultérieure plus coûteuse.
• Coûts imprévus : les heures d’intervention d’urgence des ingénieurs, les retards dans la mise en production des nouvelles fonctionnalités et le coût d’opportunité lié au fait que vos meilleurs ingénieurs passent leur temps à résoudre des problèmes de compatibilité entre les dépendances au lieu de développer de nouvelles fonctionnalités dépassent généralement ce qu’aurait coûté un support à cycle de vie prolongé pour l’ensemble de la période de planification de la migration.

Solutions pour garantir la sécurité et la conformité

Les organisations utilisant des versions d'Apache Velocity en fin de cycle de vie ont trois options à leur disposition. Les deux premières nécessitent un travail d'ingénierie important et des délais prolongés. La troisième permet de combler rapidement la faille de sécurité pendant que vos équipes planifient la migration en bonne et due forme.

Option 1 : Migrer vers Velocity Engine 2.4.1 et Tools 3.1

La solution à long terme consiste à migrer vers les versions en amont actuelles, à savoir Velocity Engine 2.4.1 et Velocity Tools 3.1 à la date de rédaction du présent document. Cela permet d'éliminer tout risque lié à la fin de vie (EOL) en adoptant des logiciels faisant l'objet d'une maintenance active.

Cette migration a une portée réelle : toutes les versions d’Engine depuis la 2.1 (mars 2019) requièrent au minimum Java 8 comme environnement d’exécution, y compris la version 2.4.1 ; les organisations utilisant Velocity 1.7 sur des environnements JVM plus anciens devront donc peut-être procéder à une mise à niveau de Java avant de migrer vers une version 2.x moderne. Les modifications apportées à l’API entre Engine 1.7 et 2.x – suppression de classes, révision de la configuration de ResourceLoader et modification des interfaces d’introspection et de journalisation – peuvent nécessiter des modifications du code dans les applications qui étendent ou configurent Velocity via ses API Java. La version 3.1 de Tools élargit encore le champ d’application avec une restructuration des paquets et une intégration révisée des servlets.

Pour les applications d'entreprise comportant plusieurs points d'intégration Velocity, la migration peut nécessiter plusieurs mois de travail d'inventaire, de modifications du code et de tests de régression.

Option 2 : Remplacer Velocity par un autre moteur de modèles

Certaines organisations se basent sur la date de fin de vie (EOL) d’Apache Velocity pour évaluer des alternatives : Thymeleaf, FreeMarker, Pebble et Mustache font tous l’objet d’une maintenance active. Le remplacement d’un moteur de modèles est plus perturbant qu’une mise à niveau au sein d’une même version ; les modèles doivent généralement être réécrits ou adaptés à la syntaxe du nouveau moteur, et chaque chemin de sortie concerné doit être testé à nouveau. Il s’agit d’un objectif viable à long terme, et non d’une solution pour remédier immédiatement à un problème de conformité lié à la fin de vie d’Apache Velocity.

Option 3 : Bénéficier d'une assistance tout au long du cycle de vie pendant la migration

Le service « Endless Lifecycle Support » (ELS) de TuxCare pour Apache Velocity vous permet de garantir la sécurité de votre système sans avoir à procéder à une migration pour laquelle votre équipe n’est pas encore prête. Vous continuez à utiliser votre version actuelle de Velocity tout en bénéficiant d’une couverture continue des correctifs de sécurité. C’est précisément pour combler cette lacune que l’ELS pour Apache Velocity a été conçu : la période comprise entre la fin du support officiel et le moment où votre organisation aura véritablement achevé une migration planifiée et maîtrisée.

La solution simple : TuxCare ELS pour Apache Velocity

TuxCare propose une assistance tout au long du cycle de vie pour les versions d'Apache Velocity en fin de vie, garantissant ainsi la protection de votre déploiement actuel grâce à des correctifs de sécurité fournis sous forme de fichiers JAR prêts à l'emploi, via votre chaîne d'outils Maven ou Gradle existante. TuxCare a distribué plus de 220 000 correctifs de sécurité dans l'écosystème open source.

Couverture complète de l'arbre des dépendances

TuxCare ELS pour Apache Velocity ne se limite pas aux fichiers JAR « Engine » et « Tools », mais s'étend aux composants pris en charge dans l'empreinte des dépendances transitives, notamment commons-collections 3.2.1 (CVE-2015-7501, CVSS 9,8 – Critique) et, pour les applications qui l'utilisent, Log4j 1.x (CVE-2019-17571, CVSS 9,8 – critique).

Processus de mise à jour optimisé et automatisé

TuxCare surveille en permanence le NVD, les avis de sécurité Apache, les flux de sécurité GitHub et les canaux de communication des éditeurs. Lorsqu’un CVE pertinent est identifié, TuxCare applique le correctif aux versions prises en charge à l’aide d’un processus automatisé basé sur des algorithmes et l’intelligence artificielle, chaque correctif étant validé par des experts en sécurité avant sa publication. Chaque mise à jour est soumise à des tests d’intégrité, de fonctionnalité et de régression avant d’être déployée dans vos dépôts. Pour plus de détails techniques, consultez le livre blanc de TuxCare intitulé « Open Source Patching Process ».

Intégration transparente

Que vous utilisiez Velocity via Maven Central ou un miroir de référentiel privé, vous pouvez basculer votre source de mise à jour vers le référentiel sécurisé de TuxCare en apportant seulement quelques modifications à la configuration de votre référentiel. Les fichiers JAR corrigés sont conçus pour remplacer directement les fichiers existants tout en conservant l’API et la configuration actuelles et en intégrant des correctifs de sécurité rétroportés. Ainsi, la plupart des équipes peuvent les utiliser dans le cadre de leurs workflows Maven ou Gradle existants et de leurs pipelines CI/CD.

Intervention rapide soutenue par la SLA

Lorsque de nouvelles vulnérabilités affectant des versions de Velocity en fin de vie prises en charge sont révélées – que ce soit dans le moteur, dans les outils ou dans les dépendances couvertes –, TuxCare fournit des correctifs couverts par des accords de niveau de service, l’objectif étant de corriger les vulnérabilités de gravité élevée et critique (CVSS 7.0 et plus) dans les 14 jours suivant leur divulgation publique.

Une continuité de la sécurité à moindre coût

Le coût de TuxCare ELS ne représente qu'une fraction de celui d'une migration d'urgence effectuée sous la pression d'une échéance de mise en conformité. Vous planifiez une migration réfléchie vers Velocity Engine 2.4.1 et Tools 3.1 lorsque cela correspond aux capacités de votre équipe, en prévoyant notamment le temps nécessaire pour évaluer l'impact complet des dépendances transitives et valider chaque chemin de sortie des modèles. Vous pouvez également utiliser ELS pour maintenir la couverture des correctifs de sécurité et soutenir vos efforts de mise en conformité, tout en prenant ces décisions selon votre propre calendrier.

Ne laissez pas la fin de vie d'Apache Velocity mettre vos applications Java en danger

La fin de vie (EOL) d'Apache Velocity ne signifie pas que votre application est immédiatement compromise. Cela signifie toutefois que des composants dont la vulnérabilité est connue peuvent subsister dans l'arborescence de vos dépendances en production – notamment une vulnérabilité de Velocity notée « Élevée » (CVSS 8,8) et des vulnérabilités de dépendances pouvant atteindre le niveau « Critique » (CVSS 9,8) – et que le projet en amont ne les corrigera pas.

La possibilité d'exploiter chaque vulnérabilité dépend de la configuration de votre application, des flux de données et des contrôles de sécurité, mais chaque mois qui s'écoule après la publication d'un CVE concernant une version arrivée en fin de vie est un mois pendant lequel la fenêtre d'exposition reste ouverte.

La réponse appropriée à la fin de vie d'Apache Velocity dépend du calendrier et des capacités techniques de votre organisation. Si vous pouvez migrer dès maintenant vers Engine 2.4.1 et Tools 3.1, c'est la solution à privilégier. Si la complexité de votre intégration Velocity rend une mise à niveau immédiate impossible, le service TuxCare ELS pour Apache Velocity vous garantit la poursuite de la couverture des correctifs de sécurité pendant que vous planifiez et menez à bien la migration en toute sécurité.

Si la fin de vie d'Apache Velocity figure actuellement parmi vos priorités en matière de sécurité, rendez-vous sur la page « Endless Lifecycle Support for Open Source Software » de TuxCare pour découvrir comment un support prolongé peut protéger l'ensemble de votre pile open source.

Résumé

Nom de l'article

ELS pour Apache Velocity : assurez la sécurité de votre système après la fin de vie du produit

Description

Vous utilisez Apache Velocity en fin de cycle de vie (EOL) ? La solution TuxCare ELS pour Apache Velocity garantit la mise à jour et la conformité de vos applications Java sans vous obliger à effectuer une migration précipitée.

Auteur

Muzzammil Hasann

Nom de l'éditeur

de TuxCare

Logo de l'éditeur