Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Commons Lang est présent dans l'ensemble des piles Java d'entreprise ; ainsi, une seule instance non corrigée peut se transformer en un problème à l'échelle de tout le parc.
- Apache propose des correctifs dans ses versions ultérieures plutôt que via des branches de rétroportage ; par conséquent, les anciennes versions 3.x ne bénéficient plus de ces correctifs.
- Les mises à niveau précipitées tournent mal parce que
commons-lang3se manifeste généralement de manière transitive, et les problèmes de médiation apparaissent lors de l'exécution. - L'ELS de TuxCare publie des versions corrigées d'anciennes versions de Commons Lang, ce qui vous permet de rester à jour pendant que vous planifiez votre projet.
Commons Lang, c'est cette bibliothèque dont personne ne prend jamais le temps de discuter. Elle vous fournit les utilitaires que le JDK n'a jamais inclus, StringUtils et ClassUtils et NumberUtils et les classes de construction, puis passe inaperçu dans l'arrière-plan de tous les services que vous possédez. Il n'importe rien lors de l'exécution, ne plante presque jamais, et fonctionne ainsi discrètement depuis la sortie de Commons Lang 1.0 en 2002. MvnRepository la place actuellement en tête de la catégorie « Core Utilities », avec environ 50 000 artefacts répertoriés comme l'utilisant, ce qui est une façon polie de dire qu'elle se trouve presque certainement quelque part dans votre fichier de build.
C'est précisément ce qui rend une copie obsolète agaçante. Une vulnérabilité CVE dans une bibliothèque à laquelle seul votre service de facturation a accès n'affecte qu'un seul service. Une vulnérabilité CVE dans commons-lang3 il s'exécute partout où votre code l'appelle, et dans de nombreux environnements Java d'entreprise, cela représente une longue liste d'endroits dont personne ne dispose d'un inventaire précis.
Voici le point qui prend souvent les équipes au dépourvu. Apache ne publie pas de date de fin de vie pour les différentes versions de Commons Lang. Il n'y a ni avis de fin de vie, ni notification vous indiquant que la branche sur laquelle vous vous trouvez n'est plus mise à jour. De plus, vous ne bénéficiez pas d'une branche maintenue pour votre ancienne version ; ainsi, dès qu'un correctif est intégré dans une version plus récente, il n'existe généralement pas de filière de maintenance permettant de le répercuter sur la vôtre.
Comment Apache Commons Lang gère concrètement ses versions
Il vaut mieux le savoir avant de se retrouver à se disputer avec un scanner à ce sujet.
Commençons par la scission. Apache a publié Commons Lang 3.0 en 2011, avec une rupture délibérée de l'espace de noms des paquets. La branche 2.x se trouve à l'adresse org.apache.commons.lang et la version 3.x se trouve à l'adresse org.apache.commons.lang3. C'était voulu, afin que les deux puissent coexister dans le même classpath sans entrer en conflit, ce qui explique également pourquoi de nombreuses bases de code volumineuses continuent d'utiliser les deux. En termes de cycle de vie, la version 2.x est terminée à tous les égards qui comptent. La dernière version publiée était la 2.6 en 2011 ; le développement s'est orienté vers la branche 3.x, et rien n'a été publié depuis. Quiconque utilise encore la version 2.x fonctionne sans les correctifs de l'amont depuis 2011.
La série 3.x fonctionne différemment de ce que la plupart des gens imaginent. Apache ne gère pas de branches parallèles de support à long terme comme le fait le JDK. Les corrections sont intégrées à la version suivante, et l'historique des versions publié ne fait apparaître ni branche de maintenance 3.12.x, ni branche de rétroportage 3.17.x. Ainsi, bien qu'Apache n'ait jamais officiellement déclaré la fin de vie d'une version 3.x, le résultat pratique est le même. Si un correctif est intégré à une version plus récente, il ne sera pas disponible pour la vôtre.
Il est important de bien faire cette distinction lorsque vous rédigez un rapport destiné à un auditeur. La formulation « Aucune version de backport en amont pour cette version » est exacte et défendable. En revanche, l’affirmation « Fin de vie officielle à compter d’une date précise » ne l’est pas, car Apache n’en a jamais publié.
En septembre 2026, la dernière version disponible est la 3.20.0, publiée le 12 novembre 2025. Il est également utile de connaître la version minimale requise de Java. À partir de la version 3.9, la bibliothèque nécessite Java 8 ; ainsi, toutes les versions à partir de la 3.9 requièrent Java 8 ou une version ultérieure, et l'intégration continue (CI) du projet s'exécute actuellement sur les versions LTS prises en charge, à savoir les versions 8, 11, 17, 21 et 25.
| Ligne de version | Espace de noms du paquet | État d'avancement | Dernière version |
|---|---|---|---|
| Commons Lang 2.x | org.apache.commons.lang |
Le développement est terminé, aucune correction n'a été apportée depuis 2011 | 2.6 (2011) |
| Commons Lang 3.x, versions antérieures | org.apache.commons.lang3 |
Toujours en production, mais pas de branche de rétroportage | n/a, remplacé |
| Commons Lang 3.x, version actuelle | org.apache.commons.lang3 |
Où les correctifs sont-ils réellement appliqués ? | 3.20.0 (novembre 2025) |
Ce que signifie concrètement la fin de vie d'un langage Commons Lang
Vous ne recevez plus les correctifs
La vulnérabilité CVE-2025-48924, révélée en juillet 2025, en est une bonne illustration, précisément parce qu’elle n’a rien de spectaculaire. ClassUtils.getClass() les noms de classes imbriquées étaient résolus de manière récursive ; ainsi, une entrée suffisamment longue pouvait épuiser la pile et provoquer une StackOverflowError. Comme il s'agit d'une erreur et non d'une exception, les applications ne la gèrent généralement pas, et cette défaillance peut entraîner l'arrêt de l'application. Apache lui a attribué une note faible, l'ADP de la CISA lui a attribué une note de 5,3, et c'est OSS-Fuzz qui l'a découverte. Elle n'allait de toute façon pas faire la une des journaux.
C'est sa forme qui est intéressante. L'avis porte sur les versions 2.0 à 2.6 de commons-lang et sur toutes les commons-lang3 versions comprises entre la 3.0 et la 3.18.0 (exclue), qui intègrent le correctif fourni par l'amont. Il n'existe pas de version 3.17.0 corrigée par l'amont. Si un framework vous oblige à rester à cette version, si un gel des modifications vous y contraint, ou si personne ne dispose du budget nécessaire pour effectuer des tests de régression sur une bibliothèque d'utilitaires couvrant quarante services, ce problème restera indéfiniment dans les résultats de votre scanner.
Il est important de garder à l'esprit, lors du triage, qu'une vulnérabilité CVE récemment divulguée pour Commons Lang n'affecte pas automatiquement la version que vous utilisez. La plupart ne l'affecteront pas. Ce que la fin de vie (EOL) entraîne, c'est l'impossibilité de corriger celles qui posent problème sans changer de version.
Quand la conformité devient délicate
L'exigence 6.3.3 de la norme PCI DSS v4.0.1 stipule que les correctifs destinés à corriger les vulnérabilités critiques, classées selon votre propre processus défini à l'exigence 6.3.1, doivent être déployés dans un délai d'un mois à compter de la publication du correctif. Tout le reste s'inscrit dans un délai que vous déterminez en fonction de votre propre évaluation du niveau de gravité du risque pour votre environnement. La norme PCI DSS v4.0 appliquait également ce délai d'un mois aux correctifs critiques ou liés à la sécurité, mais la version v4.0.1 l'a restreint aux seules vulnérabilités critiques.
D’autres cadres réglementaires sont moins contraignants, et les présenter de manière exagérée est le meilleur moyen de perdre l’attention d’un lecteur technique. FedRAMP fixe des délais de correction en fonction du niveau de gravité. La règle de sécurité de l’HIPAA vous oblige à réaliser une analyse des risques et à gérer les vulnérabilités connues sans préciser de nombre de jours. SOC 2 repose sur des critères ; votre auditeur s’assurera donc que le processus de correction que vous avez documenté est bien celui que vous suivez réellement. Aucun de ces cadres ne permet de défendre facilement un composant pour lequel il n’existe pas de voie de correction.
Le problème spécifique lié aux bibliothèques d'utilitaires concerne la portée. Un serveur d'applications vulnérable se trouve à un seul endroit et génère un seul résultat. Un serveur d'applications vulnérable commons-lang3 apparaît une fois par artefact qui le regroupe, ce qui transforme une simple version non corrigée en un exercice de remédiation impliquant des équipes qui n’ont jamais échangé entre elles. Les contrôles compensatoires peuvent permettre de gagner du temps et constituent souvent la bonne décision, mais déterminer s’ils sont suffisants relève d’un échange avec votre évaluateur plutôt que d’une case à cocher.
Vos options après la fin de vie d'Apache Commons Lang
Passer à la version actuelle
Pour les équipes qui en ont la possibilité, passer à la version actuelle constitue la bonne solution à long terme. Apache assure une compatibilité raisonnablement stricte au sein de la branche 3.x, l'espace de noms « lang3 » est resté stable sur l'ensemble de la gamme, et le projet publie des rapports de compatibilité binaire pour ses versions. Chaque version déprécie toutefois certains éléments et modifie certains comportements ; il convient donc de la considérer comme une mise à niveau plutôt que comme une simple formalité.
Le problème, c'est que cela se résume rarement à une simple modification d'une ligne. commons-lang3 se trouve généralement dans votre arborescence parce qu’un autre élément l’y a placé, qu’il s’agisse d’une couche de persistance, d’un framework ou d’un autre composant Apache Commons, et la version que vous obtenez finalement est celle choisie par le mécanisme de médiation de Maven. Une déclaration directe avec sa propre version dans votre pom.xml remporte ce choix. Si vous ne spécifiez pas de version et que vous laissez un POM parent ou une nomenclature importée la fournir, c’est alors la version gérée qui prendra la décision. Une copie grisée intégrée à l’artefact d’un tiers se situe entièrement en dehors du processus de médiation et ne sera pas affectée par celui-ci. C’est pourquoi mvn dependency:tree -Dverbose c'est la première commande à exécuter, et non la dernière.
Remplacer par une autre bibliothèque d'utilitaires
Certaines équipes profitent de l'occasion pour remettre entièrement en question cette dépendance. Guava couvre en grande partie les mêmes fonctionnalités, Spring fournit ses propres classes utilitaires, et les API de base de Java 8 et versions ultérieures ont intégré une bonne partie de ce que Commons Lang était initialement censé fournir.
C'est un choix architectural légitime, mais il faut être honnête quant aux compromis que cela implique. Guava est également une dépendance tierce qui possède son propre historique de vulnérabilités CVE, et qui adopte une approche plus souple qu'Apache Commons en matière de rotation des versions, puisque tout élément marqué @Beta peuvent changer ou disparaître à chaque nouvelle version. Vous remplacez une interface de la chaîne logistique par une autre, plutôt que d’en supprimer une. La migration implique également de passer au crible chaque point d’appel, de les réécrire et de valider leur comportement dans le cadre du remplacement. Il s’agit là d’un projet de migration, et non d’un sprint, ce qui en fait une solution peu adaptée à une échéance de mise en conformité fixée au mois prochain.
Conservez votre version et appliquez quand même le correctif
La troisième option consiste à conserver la version actuelle et à obtenir les correctifs de sécurité ailleurs qu’auprès du développeur d’origine. C’est ce que propose le service « Endless Lifecycle Support » de TuxCare, et c’est la seule des trois options qui dissocie l’état de vos correctifs de votre calendrier de mise à niveau.
Pourquoi précipiter la mise à niveau de Commons Lang peut se retourner contre nous
Lorsque la pression se fait sentir — et cela se manifeste généralement sous la forme d'un problème détecté par un scanner plutôt que d'une décision —, le réflexe est d'augmenter le numéro de version et de publier la version. Or, plusieurs problèmes risquent alors de survenir.
La médiation des versions est la première étape. Dès que plusieurs dépendances déclarent des versions différentes commons-lang3 versions, Maven retient la déclaration la plus proche dans le graphe plutôt que celle sur laquelle votre code a été testé, l'ordre des déclarations servant à départager les cas à profondeur égale. La compilation peut rester « verte » alors qu'un NoSuchMethodError, un NoClassDefFoundError ou qu’un autre problème de compatibilité apparaisse plus tard, dans une branche du code qui n’aurait pas été détectée lors des tests.
La réaction habituelle peut aggraver la situation. Les équipes ont tendance à <exclusions> dans Maven ou via des contraintes de dépendances dans Gradle pour imposer la version souhaitée, ce qui résout certes l'erreur immédiate, mais laisse derrière soi un graphe de dépendances que personne ne voudra toucher lors de la prochaine mise à jour. Faites cela sur plusieurs services sous la pression du temps, et vous aurez troqué un problème de correctif contre un problème de maintenance.
La dérive comportementale est un risque plus insidieux. Les fonctions d'aide de Commons Lang pour les chaînes de caractères, les réflexions et les valeurs numériques ont été affinées au fil de nombreuses versions, et un code qui repose sur un cas limite, comme la gestion des valeurs nulles dans un contexte particulier, StringUtils Une méthode, par exemple, peut modifier son comportement sans changer de signature. Il n'y a aucun problème lors de la compilation. Elle renvoie simplement une valeur légèrement différente en production.
Rien de tout cela n'est inévitable. C'est ce qui se produit lorsque le travail est condensé dans un délai dicté par un calendrier de conformité plutôt que par le graphe des dépendances. Les équipes qui parviennent à mener à bien ces transitions sans heurts appliquent systématiquement les trois mêmes principes : elles effectuent un audit rigoureux de l'arborescence, elles testent les comportements sur lesquels leur code repose réellement, et elles maintiennent une posture de sécurité constante tout au long de ces deux étapes.
Ce que vous offre ELS pour Apache Commons Lang
TuxCare corrige des logiciels open source depuis quinze ans et a publié plus de 420 000 correctifs pour l'ensemble de son portefeuille. Le service Commons Lang met en évidence les versions sur lesquelles les utilisateurs sont encore bloqués. La documentation mentionne actuellement Commons Lang 2.4 et 2.6 dans l'ancien espace de noms, ainsi que commons-lang3 3.4, 3.8.1, 3.10, 3.11, 3.12.0, 3.14.0, 3.15.0 et 3.17.0.
D'un point de vue technique, cela n'a rien d'exceptionnel, et c'est justement le but recherché. Vos identifiants sont renseignés dans le fichier Maven settings.xml, le dépôt TuxCare se trouve dans votre pom.xml, ou leurs équivalents Gradle, et vous indiquez comme dépendance la version maintenue ; ainsi, la version 2.6 devient 2.6-tuxcare.1. Vos sites d'appel restent inchangés, vos outils de compilation restent inchangés, et l'intégration continue (CI) continue de récupérer les artefacts comme elle l'a toujours fait. Si vous préférez que vos compilations ne s'adressent pas directement à un fournisseur, vous pouvez faire passer l'ensemble par votre propre gestionnaire de référentiels.
En ce qui concerne les délais, TuxCare vise 14 jours à compter de la divulgation publique pour les vulnérabilités « élevées » et « critiques » selon le score CVSS 7.0 ou supérieur, 60 jours pour les vulnérabilités « moyennes » et 90 jours pour les vulnérabilités « faibles ». Ces délais commencent à courir à partir de la divulgation. La norme PCI DSS commence à compter à partir de la publication du correctif ; l’objectif de 14 jours est donc fixé de manière à vous laisser une marge de manœuvre au sein du délai d’un mois prévu par l’exigence 6.3.3, qui s’applique aux vulnérabilités critiques.
Une remarque sur la couverture des dépendances, car on a tendance à en faire trop. commons-lang3 Il ne comporte, de par sa conception, aucune dépendance d'exécution ; il n'y a donc pas d'arborescence cachée en arrière-plan. C'est l'inverse qui se produit. commons-lang3 Il s'agit généralement d'une dépendance transitive présente dans l'arborescence d'un autre composant, ce qui explique précisément pourquoi elle passe inaperçue. ELS for Libraries couvre les dépendances directes et transitives des composants pris en charge sans frais supplémentaires, ce qui revêt une importance capitale pour des composants tels que Struts ou Tomcat. En ce qui concerne plus particulièrement Commons Lang, l'intérêt réside dans le fait que la bibliothèque dont tout le reste dépend bénéficie enfin d'une version maintenue.
Pour le reste, tout est conçu comme vous le souhaiteriez. Les paquets comportent des signatures OpenPGP indépendantes et proviennent d’un registre géré par TuxCare ; l’authenticité et l’intégrité sont donc vérifiables et non pas simplement supposées. Il existe un flux VEX CycloneDX pour les bibliothèques Java, y compris Commons Lang, qui indique à vos outils d’analyse et à vos auditeurs quelles vulnérabilités CVE s’appliquent réellement à une version donnée, plutôt que celles qui se contentent de mentionner le paquet. Les SBOM sont fournies aux formats SPDX et CycloneDX, le flux Java étant publié sur Nexus parallèlement aux paquets. L’assistance est disponible 24 h/24, 7 j/7 et 365 j/an via le portail d’assistance TuxCare pour le triage, les demandes de correctifs et les éventuels problèmes liés au système de compilation.
Pour consulter la liste actualisée des versions prises en charge d'Apache Commons Lang, consultez la documentation de TuxCare. Pour savoir quelles vulnérabilités CVE d'Apache Commons Lang ont déjà été corrigées, consultez le suivi en temps réel des CVE.
Ne laissez pas la fin de vie de Commons Lang mettre vos applications en danger
La perte du support en amont n'entraîne pas en soi de dysfonctionnement. C'est là le véritable problème, et c'est pourquoi cette question reste en dehors de la feuille de route jusqu'à ce qu'un scanner ou un auditeur la mette à l'ordre du jour. Vos applications continuent de fonctionner, vos tests continuent d'être validés, et la seule chose qui a changé, c'est que les correctifs en amont pour votre version ne sont plus fournis.
La mise à niveau vers la version actuelle reste la bonne solution. Pour y parvenir correctement, il faut définir la portée de l'audit des dépendances, tester les comportements sur lesquels votre code repose réellement et intégrer ce travail dans un calendrier de publication sur lequel d'autres personnes ont également des attentes. C'est un plan, et les plans prennent du temps, temps dont vous ne disposez pas lorsque la date limite est fixée par quelqu'un d'autre.
C'est le support étendu qui vous fait gagner ce temps. Il ne remplace pas la mise à niveau, et personne ne devrait prétendre le contraire. Il permet de maintenir à jour les versions de Commons Lang qu'il prend en charge, vous offre un argument solide à présenter à un auditeur et permet à vos ingénieurs de consacrer leur trimestre à la feuille de route plutôt qu'à une migration d'urgence des bibliothèques.
Si la fin de vie (EOL) d'Apache Commons Lang retient actuellement votre attention, découvrez l'offre ELS de TuxCare pour Apache Commons Lang, qui propose une assistance prolongée pour certaines versions de Commons Lang et commons-lang3 dont le support a pris fin.
