Fin de vie d'Apache Struts : assurez la sécurité de vos applications Web Java | TuxCare ELS

Principaux enseignements

• Lorsqu'une version de Struts arrive en fin de vie, l'ensemble de la pile de dépendances (OGNL, FreeMarker, Commons FileUpload, Commons BeanUtils, Log4j2 et autres) ne bénéficie plus de correctifs de sécurité coordonnés avec le framework lui-même.
• La migration de Struts 2.5.x vers 6.x nécessite des mises à niveau de l'environnement d'exécution Java, des modifications de l'API Servlet, la réécriture d'expressions OGNL, le remplacement d'interfaces d'intercepteurs et la suppression des modèles d'accès aux méthodes statiques ; tous ces éléments exigent une planification minutieuse et des tests approfondis, et ne peuvent être réalisés dans des délais serrés.
• TuxCare ELS étend la couverture de sécurité aux versions de Struts arrivées en fin de vie (EOL) et à leurs dépendances, permettant ainsi aux entreprises de garantir la sécurité et la conformité tout en planifiant une migration réfléchie, dotée des ressources nécessaires, selon leur propre calendrier.

Depuis plus de deux décennies, Struts constitue la colonne vertébrale du développement web Java en entreprise. Son architecture MVC (Modèle-Vue-Contrôleur), son écosystème de plugins bien établi et son intégration poussée avec l'ensemble de la pile Java d'entreprise en ont fait le framework de prédilection pour les applications web à grande échelle dans les secteurs des services financiers, de l'administration publique, de la santé et des télécommunications. Mais l'histoire de Struts rend la question de sa fin de vie particulièrement cruciale. Il détient le bilan CVE le plus lourd de tous les frameworks web Java en production, et les organisations utilisant des versions Apache Struts en fin de vie s'exposent à un profil de risque que la violation d'Equifax en 2017 a fait passer de la théorie à la une des journaux.

Cet article explique ce que la fin de vie (EOL) d'Apache Struts implique concrètement pour les équipes chargées des applications Java, où se cachent les véritables failles de sécurité dans l'arborescence des dépendances, pourquoi la migration vers les versions actuelles est plus complexe qu'il n'y paraît, et comment le service Endless Lifecycle Support (ELS) de TuxCare vous permet de maintenir une sécurité et une conformité totales sans imposer à vos équipes une migration pour laquelle elles ne sont pas prêtes.

En quoi consiste le cycle de vie du produit Apache Struts ?

Contrairement à certains autres projets open source, Struts ne suit pas de calendrier de publication formellement documenté et basé sur des délais précis. Le comité de gestion du projet (PMC) de l'Apache Software Foundation publie les avis de fin de vie (EOL) directement sur le site web du projet lorsqu'une branche majeure arrive en fin de vie, en donnant généralement un préavis de six mois avant la fin officielle du support. Les avis EOL ne sont pas liés à un calendrier fixe ; ils reflètent la capacité de la communauté à maintenir une branche donnée et la disponibilité d'une version de remplacement prise en charge.

Par exemple, vous pouvez consulter notre guide sur la fin de vie d'Apache Kafka pour découvrir comment les infrastructures de streaming gèrent ce type de rupture de prise en charge, ou vous renseigner sur la manière dont les frameworks Big Data gèrent une étape clé du cycle de vie liée à la fin de vie d'Apache Spark. Si vous gérez des composants d'entrepôt de données, vous pouvez également en savoir plus sur la fin de vie d'Apache Hive dans notre guide détaillé.

Le projet suit les règles de versionnement sémantique et continue d'assurer la prise en charge de ses branches actives. Les avis de fin de vie (EOL) s'accompagnent généralement d'une période de six mois pendant laquelle la sécurité est assurée après l'annonce initiale, à l'issue de laquelle la branche ne reçoit plus aucun correctif d'aucune sorte. Cela signifie qu'il n'y a pas de délai de grâce pour les failles de sécurité divulguées après la date finale de fin de vie ; tout CVE affectant une branche en fin de vie ne fera pas l'objet d'un correctif officiel de la part de la communauté.

État actuel de la prise en charge des versions de Struts :

Version	Date de sortie	Date de fin de vie	Statut
Struts 1x	2000-2008	Avril 2013	EOL
Struts 2.3x	2012	Mai 2019	EOL
Struts 2.5x	Mai 2016	Avril 30, 2024	EOL
Struts 6x	Juin 2022	Non annoncé	Actif (dernière version)
Struts 7x	Décembre 2024	Non annoncé	Actif

Struts 2.5.x, la version la plus largement déployée dans les environnements d'entreprise, a connu sa version finale (2.5.33) en décembre 2023 et a officiellement atteint sa fin de vie le 30 avril 2024. Les organisations qui n'ont pas encore achevé leur migration vers Struts 6.x ou 7.x utilisent désormais un framework Apache Struts en fin de vie qui ne bénéficie plus de correctifs de sécurité en amont.

Les conséquences pratiques de ce modèle de cycle de vie sont importantes. Étant donné que le projet ne publie pas, des années à l'avance, de dates fixes de fin de vie, les entreprises constatent souvent que l'annonce de la fin de vie survient avant que la migration n'ait été budgétisée, dotée des ressources nécessaires et planifiée. Le délai de préavis de six mois prévu pour la fin de vie d'Apache Struts n'est pas suffisant pour permettre aux grandes applications d'entreprise, qui intègrent largement Struts, de mener à bien une migration testée et validée.

Que signifie la fin de vie (EOL) d'Apache Struts pour les applications Web Java ?

Pour les organisations qui utilisent Struts comme couche web d'applications Java critiques chargées de traiter les requêtes HTTP destinées au public, de gérer les téléchargements de fichiers, de traiter les soumissions de formulaires et qui se situent en amont des couches de logique métier traitant des dossiers financiers, des données de patients ou des systèmes gouvernementaux, la fin de vie (EOL) d'Apache Struts n'est pas une simple question d'ordre administratif. Il s'agit d'un incident de sécurité ayant des conséquences directes sur la conformité.

Plus aucun correctif de sécurité après la date de fin de vie

Une fois qu'une version de Struts arrive en fin de vie, la communauté Apache cesse de publier des correctifs de sécurité pour celle-ci. Toute vulnérabilité révélée après la date de fin de vie, qu'elle concerne le dispatcher central du framework, son moteur d'évaluation d'expressions OGNL, la gestion du téléchargement de fichiers ou sa pile d'intercepteurs, ne fera pas l'objet d'un correctif officiel. La seule solution proposée par la communauté consiste à migrer vers une version prise en charge.

Pour les équipes qui exploitent de grandes applications web critiques pour la production, où la migration nécessite de réécrire des classes Action, de remplacer des interfaces d'intercepteurs, de mettre à jour des expressions OGNL dans l'ensemble des modèles et de valider le comportement sur des dizaines, voire des centaines de points de terminaison de l'application, cela n'est pas toujours possible dans un délai très court. C'est précisément pendant la période comprise entre le moment où le statut de fin de vie prend effet et celui où une migration peut être raisonnablement achevée et validée que s'accumulent les vulnérabilités non corrigées.

Risques liés à la sécurité et à la conformité après la fin de vie

Les conséquences en matière de conformité liées à l'utilisation d'une version de Struts en fin de vie sont directes. La norme PCI DSS (exigence 6.3.3) impose l'installation des correctifs critiques et à haut niveau de gravité dans un délai d'un mois à compter de leur publication ; or, pour une version de Struts en fin de vie, aucun correctif n'est disponible, ce qui rend impossible toute mise en conformité par les moyens habituels. Les auditeurs SOC 2 signalent les logiciels en fin de vie dans les environnements de production. Les organisations utilisant des déploiements Apache Struts en fin de vie sont confrontées à des lacunes dans la documentation qui apparaissent dans les questionnaires de sécurité, retardent les certifications des fournisseurs et, dans les secteurs réglementés, bloquent les renouvellements de contrats avec les clients.

Pour les organisations dont les applications Struts relèvent du champ d'application de la norme PCI, traitent des données à caractère personnel ou sous-tendent des services soumis à des obligations contractuelles en matière de SLA, le risque de non-conformité lié à cette fin de vie n'est pas hypothétique. Il s'agit d'un constat d'audit qui ne demande qu'à se concrétiser.

Historique des CVE : ce que révèle le registre des vulnérabilités

Struts affiche le nombre de vulnérabilités CVE le plus élevé parmi tous les frameworks web Java en production, et cette situation explique clairement pourquoi la mise à jour des versions en fin de vie n'est pas facultative.

CVE-2017-5638 (CVSS 10.0 Critique) est la vulnérabilité qui a exposé les données personnelles et financières de 147 millions de personnes lors de la violation d'Equifax, l'une des violations de données les plus préjudiciables de l'histoire. La faille résidait dans l'analyseur Jakarta Multipart : un attaquant pouvait créer un en-tête HTTP Content-Type malveillant qui déclenchait une gestion incorrecte des exceptions dans l'analyseur, entraînant l'exécution de commandes arbitraires sur le serveur avec les privilèges du processus du serveur web. Aucune authentification n'était requise. Des exploits ont été rendus publics quelques jours après la divulgation, et leur exploitation active a immédiatement commencé. Un correctif a été publié le 7 mars 2017. Le fait qu'Equifax ne l'ait pas appliqué a laissé ses systèmes exposés pendant 144 jours, soit suffisamment longtemps pour que les attaquants puissent exfiltrer des numéros de sécurité sociale, des dates de naissance et des numéros de permis de conduire au cours d'une campagne prolongée. Cette violation a donné lieu à un règlement de 700 millions de dollars, à des témoignages devant le Congrès, et est devenue l'étude de cas définitive sur ce que coûte réellement l'exposition d'un Struts non corrigé. Le correctif était disponible. C'est le délai entre la disponibilité du correctif et son application qui a déterminé l'issue.

CVE-2023-50164 (NVD CVSS 3.1 : 9,8 Critique) a démontré que la vulnérabilité critique de Struts permettant l'exécution de code à distance (RCE) ne s'est pas arrêtée avec la génération de vulnérabilités de 2017. Cette faille résidait dans la logique de téléchargement de fichiers du framework : un attaquant pouvait manipuler les paramètres de téléchargement de fichiers pour permettre le traversement de chemin, puis télécharger un fichier malveillant vers un emplacement accessible au serveur web, permettant ainsi l'exécution de code à distance. Le vecteur CVSS AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H indique qu'aucune authentification n'est requise, qu'aucune interaction de l'utilisateur n'est nécessaire, que l'accès est possible via le réseau et que la confidentialité, l'intégrité et la disponibilité sont entièrement compromises. Des exploits de preuve de concept ont été publiés quelques jours après la divulgation de décembre 2023. Les versions concernées couvraient l'ensemble de l'historique de Struts 2, de la version 2.0.0 à la version 2.5.32 et de la version 6.0.0 à la version 6.3.0. Struts 2.5.33 a reçu un correctif, mais Struts 2.5.33 est la dernière version de Struts 2.5.x, ce qui signifie que la branche est désormais en fin de vie (EOL). À l'avenir, tout CVE divulgué concernant Struts 2.5.33 ne fera pas l'objet d'un correctif communautaire.

CVE-2024-53677 (NVD CVSS 3.1 : 9,8 – Critique) illustre de la manière la plus directe ce que signifie concrètement aujourd'hui le statut EOL (fin de vie) d'Apache Struts. Divulguée en décembre 2024, cette vulnérabilité critique de type « path traversal » dans le mécanisme de téléchargement de fichiers de Struts affecte toutes les versions de Struts de la 2.0.0 à la 6.3.0.2, y compris Struts 2.5.33, la dernière version EOL. Le vecteur d'attaque est identique à celui de CVE-2023-50164 : un attaquant manipule les paramètres de téléchargement de fichiers pour accéder à un chemin d'accès serveur non prévu et télécharger un fichier malveillant, ce qui lui permet d'exécuter du code à distance. La correction nécessite une mise à niveau vers Struts 6.4.0 et la migration vers le nouvel intercepteur Action File Upload. Struts 2.5.33, en tant que branche EOL, n'a reçu aucun correctif. Toute organisation utilisant encore Struts 2.5.x est exposée de manière permanente à cette vulnérabilité RCE critique sans qu'aucune solution officielle ne soit disponible – ce qui correspond exactement au scénario de risque lié à la fin de vie d'Apache Struts abordé dans cet article.

C'est précisément ce type de vulnérabilité – une faille RCE accessible depuis le réseau sans authentification au sein de l'infrastructure des applications web en production – qui devient une faille de sécurité persistante et irrémédiable sur les versions en fin de vie. L'affaire Equifax a démontré qu'il ne s'agit pas d'un risque que les organisations peuvent gérer uniquement par la surveillance ou la détection. La seule solution durable consiste à déployer une version corrigée.

Le risque caché : l'arborescence des dépendances de Struts

La surface d'exposition d'un déploiement Struts ne se limite pas au binaire du framework lui-même. Struts s'accompagne d'un ensemble considérable de dépendances qui présentent leurs propres risques de sécurité ; or, lorsque Struts arrive en fin de vie, la mise à jour coordonnée de ces dépendances dans le cadre de cette version de Struts prend également fin.

Le module struts2-core intègre OGNL (la bibliothèque Object-Graph Navigation Language) en tant que dépendance directe d'exécution – et OGNL possède son propre historique de vulnérabilités CVE, lié à son rôle de moteur principal d'évaluation d'expressions, qui a été exploité dans de nombreuses failles de Struts. FreeMarker est inclus pour le rendu des modèles. Apache Commons FileUpload gère les données de formulaire multipart et a été directement impliqué dans la vulnérabilité CVE-2017-5638. Apache Commons BeanUtils, Commons Collections, Commons IO et Commons Lang sont toutes des dépendances d'exécution. Log4j2 est inclus pour la journalisation – une bibliothèque dont l'historique de vulnérabilités critiques (Log4Shell, CVE-2021-44228) a généré sa propre vague de correctifs d'urgence à travers l'écosystème Java. Jackson Databind gère le traitement JSON dans les plugins. L'intégration du framework Spring intègre spring-core, spring-beans, spring-context, spring-web et Spring AOP lorsque le plugin Spring est utilisé. Hibernate Validator est intégré pour la validation des beans.

Chacune de ces dépendances dispose de son propre flux CVE en amont. Lorsqu’une branche de Struts arrive en fin de vie (EOL), la communauté cesse de publier des mises à jour coordonnées pour l’ensemble de ces dépendances dans le cadre de cette version de Struts. Les scanners de vulnérabilité utilisés sur des déploiements Struts en fin de vie généreront des résultats à travers l’arborescence des dépendances pour lesquels aucun correctif officiel n’est disponible pour cette version, laissant les équipes de sécurité face à une liste croissante de résultats d’analyse impossibles à résoudre.

L'arborescence des dépendances de Struts2-core compte plus de 20 dépendances directes et transitives lorsque l'on inclut les plugins courants. Chacune d'entre elles comporte sa propre arborescence transitive. La surface de correction effective d'un déploiement Struts 2.5.x en production, avec un ensemble de plugins classique, est nettement plus vaste que le binaire du framework seul, et tous les composants de cette arborescence cessent de bénéficier d'une prise en charge coordonnée lorsque la branche Struts parente arrive en fin de vie (EOL).

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

Les organisations qui utilisent des versions d'Apache Struts arrivées en fin de vie (EOL) ont trois options. Deux d'entre elles impliquent un effort technique considérable, des risques opérationnels et des délais prolongés. La troisième – le service « Endless Lifecycle Support » de TuxCare – comble immédiatement les failles de sécurité pendant que vos équipes planifient la migration en bonne et due forme.

Option 1 : Migrer vers une version récente de Struts

La solution à long terme consiste à migrer l'application vers une version de Struts actuellement prise en charge. Les versions bénéficiant d'un support actif sont Struts 6.x et Struts 7.x, la version 7.1.1 étant la dernière en date en octobre 2025.

En réalité, notamment pour les applications de grande envergure développées avec Struts 2.5.x, il ne s'agit pas simplement d'un changement de version. Il s'agit d'une migration impliquant des modifications coordonnées au niveau du code source de l'application, de la configuration et de l'environnement d'exécution. Struts 6.0 nécessite au minimum Java 8 et l'API Servlet 3.1 ; les organisations utilisant des environnements Java plus anciens doivent mettre à niveau leur environnement d'exécution avant de pouvoir procéder à la migration du framework. Toutes les constantes de configuration de Struts 2.3 ont été supprimées dans la version 6.0 ; toute application utilisant des constantes obsolètes doit les remplacer par leurs équivalents. L'espace de noms du package XWork a été réorganisé, ce qui nécessite des mises à jour des importations dans toutes les classes Action. L'accès aux méthodes statiques via des expressions OGNL, un modèle utilisé dans de nombreuses applications Struts 2.x, a été entièrement supprimé dans la version 6.0 et doit être remplacé par des wrappers de méthodes d'instance Action. La longueur des expressions OGNL est limitée à 256 caractères par défaut, ce qui rend inutilisables les expressions plus longues pouvant être réparties entre les modèles FreeMarker et les JSP.

 

La migration vers Struts 7.x s'accompagne d'exigences nettement plus nombreuses, dont deux nécessitent à elles seules un travail colossal avant même de toucher à une seule ligne de code Struts. Tout d'abord, Struts 7.x requiert Java 17 comme version minimale du runtime. Pour les organisations qui utilisent encore Java 8 ou Java 11, ce qui est courant dans les déploiements Struts des grandes entreprises, cela implique de planifier et d'exécuter une mise à niveau complète de la JVM dans tous les environnements : développement, CI, préproduction et production. Deuxièmement, Struts 7.x nécessite Jakarta EE, ce qui signifie que chaque importation `javax.*` dans l'ensemble du code source doit être mise à jour vers son équivalent `jakarta.*` correspondant. Cette migration de l'espace de noms javax vers jakarta concerne `javax.servlet.*`, `javax.annotation.*`, `javax.persistence.*` et tous les autres paquets `javax.*` partout où ils apparaissent dans les classes Action, les fichiers de configuration, les intercepteurs personnalisés, les JSP et toutes les bibliothèques tierces de l'arborescence des dépendances qui n'ont pas encore publié de versions compatibles avec Jakarta EE. Dans les bases de code d'entreprise de grande envergure, cette migration d'espace de noms peut à elle seule couvrir des milliers d'instructions d'importation réparties sur des centaines de fichiers et nécessite une validation de bout en bout à chaque couche de la pile d'application. Ce n'est qu'une fois ces deux conditions préalables remplies que le travail de migration spécifique à Struts peut commencer : chaque setter de classe Action acceptant des paramètres de requête doit être explicitement annoté avec `@StrutsParameter`, une modification qui peut affecter des centaines de setters dans une application mature. Les valeurs par défaut du mappage des espaces de noms ont été modifiées pour exiger des correspondances exactes, ce qui peut rompre les liens dans les modèles existants. L'ancien intercepteur de téléchargement de fichiers a été entièrement supprimé et remplacé par l'intercepteur de téléchargement de fichiers Action, ce qui nécessite des modifications de configuration et de code dans les applications qui gèrent les téléchargements de fichiers. Pour les applications ayant investi massivement dans Struts, c'est-à-dire la plupart des applications pour lesquelles la question de la migration est pertinente, une migration vers Struts 7.x correctement planifiée et testée se mesure en mois, et non en semaines.

Option 2 : Migrer vers un autre framework web

Certaines organisations voient dans la fin de vie d'Apache Struts l'occasion d'évaluer d'autres frameworks web Java : Spring MVC, Jakarta EE avec Faces, Micronaut, Quarkus ou d'autres encore. Cet argument architectural est pertinent dans certains contextes, notamment lorsque des architectures modernes axées sur REST répondraient mieux aux besoins actuels de l'application, ou lorsque les modèles de déploiement natifs du cloud tireraient profit d'un framework plus léger.

Une migration complète du framework coûte bien plus cher qu'une mise à niveau de la version de Struts. Les classes d'action, les modèles JSP, les vues FreeMarker, les mises en page Tiles, les configurations de validation, les piles d'intercepteurs et les mappages struts.xml doivent tous être remplacés ou faire l'objet d'une refonte importante. Le modèle de programmation est différent, le modèle de déploiement est différent, et les versions Struts en fin de vie continuent de fonctionner en production tout au long du processus d'évaluation, de planification et de migration. Il s'agit d'une décision stratégique en matière d'infrastructure qui mérite son propre calendrier soigneusement planifié, et non d'une décision imposée par une date de fin de vie qui arrive plus tôt que prévu.

Option 3 : Assistance TuxCare pour un cycle de vie prolongé : la solution recommandée

C'est la solution qui résout le problème immédiat sans en créer de nouveaux. Le support à vie de TuxCare pour Struts vous permet de continuer à utiliser votre version actuelle de Struts en production tout en bénéficiant d'une couverture continue des correctifs de sécurité pour le framework et son arbre de dépendances, fournis via votre chaîne d'outils Maven ou Gradle existante, sans aucune migration obligatoire.

La faille de sécurité est immédiatement comblée. Votre conformité est préservée. Vos équipes sont libres de planifier la migration de manière appropriée selon un calendrier adapté aux réalités opérationnelles – y compris le délai supplémentaire nécessaire pour annoter les classes Action afin de remédier à l'injection de paramètres dans Struts 7.x, mettre à jour les modèles d'expressions OGNL dans l'ensemble des modèles, et valider le comportement sur l'ensemble des points de terminaison de l'application. Pas de migration forcée sous la pression d'un délai, pas de situation d'urgence en matière de conformité, pas de régressions de comportement dans les applications web en production qui desservent des utilisateurs actifs.

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

Lorsqu'un statut « fin de vie » apparaît sur un tableau de bord de sécurité et que l'équipe chargée de la conformité commence à poser des questions, la pression pour agir immédiatement est bien réelle. Il est tout aussi important de comprendre ce qu'implique réellement une migration précipitée de Struts que de saisir l'ampleur de la vulnérabilité elle-même.

En quoi consiste réellement une migration vers Struts ?

Une migration Struts effectuée dans les règles de l'art – en particulier de la version 2.5.x vers la version 6.x ou 7.x – est un projet applicatif en plusieurs phases, et non une simple mise à jour de la version des dépendances. Elle nécessite de passer au crible l'intégralité du code à la recherche d'API obsolètes et de fonctionnalités supprimées, de mettre à jour le runtime Java si la version actuelle est inférieure à la version minimale requise par Struts 6.x, de mettre à jour les références à l'API Servlet et les configurations des descripteurs de déploiement, de remplacer les constantes de configuration obsolètes dans l'ensemble du fichier struts.xml, de mettre à jour toutes les importations de classes Action affectées par la réorganisation du package XWork, et de réécrire les expressions OGNL qui reposent sur l'accès à des méthodes statiques ou qui dépassent la nouvelle limite de 256 caractères.

Adaptation du code : Chaque accesseur de classe Action qui accepte des paramètres de formulaire ou de requête doit être annoté avec @StrutsParameter dans Struts 7.x. Dans une application de grande envergure comportant des dizaines ou des centaines de classes Action, il s'agit d'une modification systématique du code qui nécessite un examen minutieux afin d'éviter d'omettre par inadvertance des points d'injection, ce qui entraînerait des échecs silencieux dans le traitement de la soumission des formulaires.

Vérification de la compatibilité : Chaque fichier JSP, modèle FreeMarker et modèle Velocity de l'application doit être examiné afin de détecter les expressions OGNL qui utilisent l'accès aux méthodes statiques, dépassent les limites de longueur ou font référence à des bibliothèques de balises obsolètes. Les modifications du comportement de rendu des modèles – y compris les paramètres par défaut d'échappement automatique de FreeMarker – peuvent introduire de subtiles différences de sortie qui apparaissent lors des tests de bout en bout.

Adaptation de la chaîne d'outils : Les configurations de build, les pipelines CI/CD et les descripteurs de déploiement qui font référence à des plugins spécifiques à Struts, à des déclarations DTD et à des constantes de configuration doivent être revus et mis à jour. Le plugin Tiles a subi des modifications d'une version à l'autre ; la prise en charge de Velocity a été transférée dans un plugin dédié. Toute dépendance de plugin qui a été supprimée dans la version cible doit être remplacée ou retirée du build.

Charge de travail liée aux tests : Les tests complets de bout en bout sur l'ensemble de l'application – couvrant les soumissions de formulaires, les téléchargements de fichiers, les flux de validation, le comportement des intercepteurs et le rendu des résultats – ne peuvent être ignorés. Les modifications comportementales du modèle d'injection de paramètres, les valeurs par défaut du mappage des espaces de noms et la sémantique d'évaluation OGNL doivent toutes être validées dans le cadre de modèles de requêtes réalistes avant le déploiement en production.

Que se passe-t-il lorsqu'une migration est précipitée ?

Lorsque les équipes doivent réaliser ce travail dans l'urgence pour respecter les délais, les conséquences sont prévisibles et suivent un schéma récurrent.

Augmentation de la charge de support : Les lacunes dans les annotations des classes Action, les mises à jour manquées des expressions OGNL et les modifications non vérifiées du rendu des modèles se traduisent en production par des échecs de soumission de formulaires, des flux de validation interrompus et un comportement inattendu lors du rendu des pages. Cela génère une vague d'incidents que les équipes d'ingénierie et d'exploitation doivent gérer en plus de leur charge de travail habituelle.

Instabilité du système : Les applications Struts sous-tendent souvent des flux de travail destinés aux clients, tels que les demandes de prêt, les portails patients et les demandes de services administratifs, où les régressions comportementales affectent immédiatement les utilisateurs réels. Des changements subtils dans la liaison des paramètres, dans l'ordre d'exécution des intercepteurs ou dans le rendu des résultats peuvent provoquer des défaillances intermittentes difficiles à reproduire, qui se manifestent sous des volumes de requêtes en production que les tests de préproduction atteignent rarement.

Accumulation de la dette technique : Les solutions de contournement mises en place sous la pression du temps deviennent permanentes. Les classes d'action annotées en masse sans révision introduisent des points d'injection de paramètres involontaires. Les expressions OGNL ont été refactorisées rapidement sans que l'on comprenne les implications en matière de sécurité du nouveau modèle de liste blanche, créant ainsi des vulnérabilités qui n'existaient pas avant la migration. Le problème lié à la fin de vie (EOL) d'Apache Struts est reporté, mais pas résolu.

Coûts imprévus : les heures d'intervention d'urgence des ingénieurs, les retards dans la mise en place de nouvelles fonctionnalités, les frais généraux liés à la gestion des incidents, ainsi que le coût d'opportunité lié au fait que des ingénieurs seniors doivent déboguer les défaillances des applications web en production au lieu de développer de nouvelles fonctionnalités, tout cela s'accumule rapidement et de manière difficile à prévoir à l'avance.

La solution simple : TuxCare ELS pour Apache Struts (fin de vie)

TuxCare propose une assistance technique à vie pour les versions de Struts arrivées en fin de vie. Plutôt que d'imposer une migration pour laquelle vos équipes ne sont pas encore prêtes, vous continuez à exploiter votre déploiement Struts actuel tout en bénéficiant d'une couverture continue des correctifs de sécurité, fournie via votre chaîne d'outils de build Maven ou Gradle existante.

TuxCare s'y emploie depuis plus de dix ans, en fournissant des correctifs de sécurité pour les systèmes d'exploitation, les environnements d'exécution, les bibliothèques et les frameworks d'applications arrivés en fin de vie. L'entreprise a distribué plus de 220 000 correctifs de sécurité à travers l'écosystème open source. Quand elle affirme savoir comment assurer la sécurité des logiciels en fin de vie à l'échelle de l'entreprise, ce ne sont pas là de simples promesses marketing. Elle l'a fait à grande échelle, de manière constante.

Couverture complète de l'arborescence des dépendances : L'ELS pour Struts de TuxCare couvre le framework et ses dépendances directes et transitives, notamment OGNL, FreeMarker, Commons FileUpload, Commons BeanUtils, Commons Collections, Log4j2 et d'autres bibliothèques présentant leurs propres vulnérabilités CVE, sans frais supplémentaires. Les scanners de vulnérabilité ne tiennent pas compte des limites des paquets, et la couverture de TuxCare non plus. L'ensemble de la surface de correction est pris en compte, et pas seulement l'artefact Struts de niveau supérieur.

Processus de correction optimisé et automatisé : TuxCare surveille le NVD, les avis de sécurité des fournisseurs, la liste CVE propre à Apache et les flux de sécurité GitHub, soit tous les canaux par lesquels les vulnérabilités de Struts et de ses dépendances sont divulguées. Lorsqu’un CVE est identifié, des outils algorithmiques et une automatisation assistée par l’IA se chargent de rétroporter les correctifs de sécurité vers la version prise en charge, et des experts en sécurité valident chaque correctif avant sa publication. Chaque mise à jour est soumise à des tests d’intégrité, de fonctionnalité et de régression avant d’atteindre vos référentiels. Pour plus de détails techniques, consultez le livre blanc technique de TuxCare sur son processus de correction open source.

Intégration transparente : Que vous utilisiez actuellement Struts via Maven ou Gradle, vous pouvez basculer votre source de mise à jour vers le référentiel sécurisé de TuxCare avec un minimum de modifications de votre workflow existant. Aucun changement n'est nécessaire au niveau de votre pipeline de build, de vos workflows CI/CD, ni de la manière dont vos équipes travaillent. Les mises à jour de sécurité sont automatiquement intégrées à votre chaîne d'outils existante.

Réponse rapide garantie par un accord de niveau de service (SLA) : Lorsque de nouvelles vulnérabilités sont révélées dans les versions EOL d'Apache Struts, que ce soit dans le framework lui-même ou dans son arbre de dépendances, TuxCare fournit des correctifs dans des délais garantis, soutenus par des accords de niveau de service. Les vulnérabilités de gravité élevée et critique (CVSS 7+) sont traitées dans les 14 jours suivant leur divulgation publique. Vous n'avez pas à attendre un backport de la communauté qui ne viendra jamais pour une version Struts en fin de vie. Vous bénéficiez de correctifs prêts à l'emploi selon un calendrier prévisible, avec une assistance d'experts 24 h/24 et 7 j/7 pour le triage des vulnérabilités et le dépannage.

Une continuité de la sécurité à moindre coût : Le coût de TuxCare ELS ne représente qu'une fraction de ce que coûte une migration d'infrastructure en urgence, imposée par une échéance de conformité, en termes de temps d'ingénierie, de risque opérationnel, de réponse aux incidents et de retard dans la feuille de route. Une couverture de sécurité prévisible, un calendrier de migration maîtrisé et l'absence d'urgences liées à la conformité font du support étendu la stratégie d'entreprise idéale.

Pour savoir précisément quelles vulnérabilités ont été corrigées dans les versions de Struts arrivées en fin de vie, TuxCare met à disposition un suivi CVE en temps réel pour Struts.

Ne laissez pas la fin de vie d'Apache Struts mettre vos applications Web en danger

La fin de vie (EOL) d'Apache Struts ne signifie pas que votre application est immédiatement compromise, ni que vous devez procéder à une migration d'urgence pour laquelle vos équipes ne sont pas préparées. Cependant, cette fin de vie d'Apache Struts signifie bien que la protection de sécurité sur laquelle reposait l'infrastructure de votre application web n'est plus assurée, et la violation de données chez Equifax a clairement montré quelles peuvent être les conséquences à grande échelle d'une exposition à Struts non corrigé.

Les organisations qui gèrent bien cette situation sont celles qui considèrent ce statut de fin de vie (EOL) comme un problème de sécurité à gérer, et non comme une échéance à laquelle il faut réagir sous la pression. Vous pouvez planifier une migration réfléchie vers Struts 6.x ou 7.x lorsque cela correspond réellement aux capacités de votre équipe, en tenant compte du temps supplémentaire nécessaire pour annoter correctement les classes Action, mettre à jour les modèles d’expressions OGNL dans l’ensemble de votre couche de modèles et valider le comportement sur l’ensemble de vos points de terminaison. Vous pouvez évaluer si une migration plus large du framework répond à un véritable objectif architectural. Ou vous pouvez utiliser TuxCare ELS pour maintenir une sécurité et une conformité totales tout en prenant ces décisions selon votre propre calendrier, et non celui d'un auditeur de conformité.

Le support prolongé n'est pas une solution de fortune. C'est la solution qui garantit la sécurité de vos applications Struts, préserve votre conformité et permet à vos équipes d'ingénieurs de se concentrer sur le développement, et non sur la gestion des urgences. Si la fin de vie d'Apache Struts figure actuellement parmi vos priorités en matière de sécurité, rendez-vous sur le support à cycle de vie illimité de TuxCare pour les logiciels open source pour découvrir comment le support étendu peut protéger votre infrastructure d'applications web aussi longtemps que vous en avez besoin.