Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Le correctif a été déployé. Le ticket a été clôturé. Le rapport d'analyse rétrospective a été rédigé. Et pourtant, plus de quatre ans plus tard, les scanners continuent de le signaler. Il s'agit ici du fossé entre « corrigé » et « sécurité avérée » – et de ce que Log4j a réellement révélé au sujet des systèmes sous-jacents.
Il existe un sentiment d’épuisement particulier qui suit un incident de sécurité majeur. La course effrénée pour appliquer les correctifs, les réunions générales, l’inventaire frénétique des systèmes affectés, puis, enfin, le moment où quelqu’un clôt le ticket de suivi et inscrit « résolu » dans le champ « statut ». Ce sentiment d’aboutissement est bien réel. Il est aussi, dans de nombreux cas, légèrement prématuré.
Log4Shell – cette vulnérabilité critique permettant l'exécution de code à distance, révélée en décembre 2021 dans la bibliothèque Apache Log4j – reste l'exemple le plus frappant de ces dernières années illustrant ce qui se passe lorsqu'un composant profondément ancré dans l'écosystème Java s'avère être omniprésent et extrêmement dangereux. La réaction a été massive. Des milliers d'organisations ont appliqué des correctifs en l'espace de quelques jours. Les agences gouvernementales ont publié des directives d'urgence. Les équipes de sécurité ont travaillé sans relâche, même pendant le week-end.
Et pourtant, le problème de sécurité Java mis en évidence par Log4j n'a pas disparu. Pas le CVE en lui-même, mais les conditions qui l'ont rendu possible, ainsi que l'incertitude résiduelle qui persiste même après l'application des correctifs. C'est cette incertitude qu'il faut comprendre : c'est là la véritable leçon à retenir, et elle s'applique bien au-delà d'une simple bibliothèque.
Que signifie réellement « patché » ?
Lorsqu'une organisation annonce avoir corrigé Log4j, cette déclaration repose sur une hypothèse implicite : celle selon laquelle toutes les instances de la bibliothèque vulnérable ont été identifiées et mises à jour. Dans la pratique, cette hypothèse est extrêmement difficile à vérifier dans des environnements Java complexes.
Les applications Java sont fournies sous forme d’artefacts packagés : fichiers JAR, fichiers WAR, « fat JAR » assemblés à l’aide d’outils tels que Maven Shade ou le système de packaging intégré de Spring Boot. Ces paquets regroupent leurs dépendances au moment de la compilation. Une version vulnérable de Log4j n’apparaît pas simplement dans votre manifeste de dépendances ; elle peut être physiquement intégrée à l’intérieur d’un autre fichier JAR, lui-même contenu dans un fichier WAR, qui est déployé sur un serveur d’applications dont votre équipe de sécurité ignorait qu’il exécutait Java.
Pour savoir comment identifier et résoudre de manière systématique ces dépendances profondément ancrées, consultez notre guide complet sur l'application d'un correctif pour la vulnérabilité Log4j.
Il ne s’agit pas d’un cas isolé. Lors de la réponse à la faille Log4Shell, des chercheurs en sécurité ont découvert des instances vulnérables de Log4j imbriquées à quatre et cinq niveaux de profondeur au sein de logiciels d’entreprise provenant de fournisseurs qui, eux-mêmes, n’avaient pas réalisé que cette bibliothèque était présente. Les recommandations de la CISA à l’époque mettaient l’accent sur l’identification de chaque ressource affectée et avertissaient qu’un simple balayage initial ne suffisait pas à confirmer un inventaire complet. Le problème était structurel.
L'écart entre ce qui est déclaré dans un manifeste de dépendances et ce qui s'exécute réellement lors de l'exécution n'est pas une simple divergence. Il s'agit d'un problème fondamental de visibilité dans la gestion des dépendances Java, et Log4Shell l'a rendu impossible à ignorer.
Les répercussions à long terme d'un incident majeur
Les incidents de sécurité de l'ampleur de celui de Log4j ne se résolvent pas complètement. Ils ont des répercussions à long terme : des périodes prolongées durant lesquelles l'application des correctifs est techniquement terminée dans les systèmes que l'on a pensé vérifier, tandis que des instances vulnérables persistent dans les systèmes dont personne ne s'est souvenu.
Les répercussions à long terme de la faille Log4j se sont avérées exceptionnellement tenaces. Cela s’explique en partie par le fait que Java est un environnement d’exécution particulièrement « tenace ». Les applications Java sont déployées dans des environnements qui n’ont pas été conçus pour des mises à jour fréquentes : systèmes industriels embarqués, plateformes financières héritées, logiciels de dispositifs médicaux, applications d’entreprise fournies par des éditeurs où le client ne contrôle pas la version. Il ne s’agit pas là de contextes marginaux. Ils représentent une part importante de la base installée de Java.
DÉCEMBRE 2021
La vulnérabilité CVE-2021-44228 a été révélée. Le déploiement de correctifs d'urgence commence à l'échelle mondiale. Log4j 2.15.0 est publié – il s'est avéré par la suite que ce correctif était incomplet dans certaines configurations.
DÉCEMBRE 2021 – JANVIER 2022
Voici trois autres CVE, toutes rendues publiques en décembre 2021 : CVE-2021-45046, CVE-2021-45105 et CVE-2021-44832. Les équipes qui avaient déjà appliqué le correctif 2.15.0 doivent le faire à nouveau. Les exercices d'inventaire révèlent la présence d'instances inattendues dans les logiciels des fournisseurs et les systèmes embarqués.
2022
La CISA a ajouté Log4Shell à son catalogue des vulnérabilités connues exploitées, et les acteurs malveillants ont continué à l'intégrer dans leurs boîtes à outils standard, aux côtés de nouvelles vulnérabilités (CVE). L'exploitation des systèmes hérités non mis à jour s'est poursuivie.
2023 – AUJOURD'HUI
Des activités de scan et d'exploitation liées à Log4Shell continuent d'apparaître plusieurs années après la divulgation de la faille ; une étude longitudinale menée en 2026 a observé que le trafic associé se poursuivait encore en octobre 2025. Les applications Java embarquées et fournies par les éditeurs constituent toujours une faille persistante. L'incident est considéré comme « résolu » dans les systèmes de suivi officiels de la plupart des organisations, mais pas dans la réalité.
Cette chronologie met en évidence un point important : les vulnérabilités majeures ne disparaissent pas avec la clôture des tickets d'incident. Elles persistent dans les parties de l'infrastructure qui ont reçu le moins d'attention lors de l'intervention initiale : le système hérité que le service informatique avait oublié, l'appareil d'un fournisseur dont le fabricant a mis six mois à publier un correctif, et le service conteneurisé qui a été reconstruit à partir d'une ancienne image de base.
En quoi l'affaire Log4j a bouleversé les débats sur la sécurité interne
Si Log4Shell a eu un impact durable sur les entreprises, au-delà des correctifs, c'est bien celui-ci : il a contraint la plupart des équipes d'ingénieurs à prendre conscience du peu de connaissances qu'elles avaient en réalité sur leurs propres logiciels.
La question « Utilisons-nous Log4j ? » s’est avérée bien plus difficile à trancher que quiconque ne l’avait imaginé, et cette difficulté s’est révélée embarrassante, mais d’une manière constructive. Les architectes en sécurité ont souvent tendance à faire part de cette même prise de conscience a posteriori. Ils pensaient disposer d’un inventaire fiable parce qu’ils avaient un manifeste – mais un manifeste est une liste de ce que l’on pense avoir installé, et non une liste de ce qui est réellement en cours d’exécution.
Avant Log4Shell, les nomenclatures logicielles (SBOM) relevaient d’un domaine de niche : elles faisaient l’objet de discussions au sein des équipes chargées de la conformité, mais ne constituaient pas une priorité pour les équipes d’ingénierie. Après Log4Shell, le débat autour des SBOM s’est généralisé et s’est inscrit dans les pratiques de sécurité courantes. Le décret présidentiel américain sur la sécurité logicielle, signé en mai 2021, plusieurs mois avant la divulgation de la faille Log4j, avait déjà fait des SBOM une exigence de base. Log4Shell a démontré pourquoi cette exigence était justifiée.
La discussion a également porté sur la question de la responsabilité. Dans les grandes organisations, la question « À qui incombent les dépendances de cette application ? » n’a souvent pas de réponse claire. L’équipe d’ingénieurs qui a développé l’application a peut-être changé de poste. L’équipe chargée de la plateforme gère l’infrastructure. L’équipe de sécurité peut signaler la vulnérabilité, mais ne peut pas intégrer le correctif. Log4j a créé des situations où trois équipes différentes attendaient chacune que les autres agissent, tandis que le temps passait.
La confiance et le problème des fournisseurs
Log4Shell a également porté atteinte à un élément plus difficile à quantifier : la confiance dans les logiciels fournis par les éditeurs. De nombreuses organisations ont découvert que les applications et les appliances commerciales qu’elles avaient achetées, et pour lesquelles elles payaient des contrats de support, contenaient des instances Log4j vulnérables que l’éditeur n’avait pas signalées et qu’il ne pouvait pas corriger dans un délai raisonnable. Ces organisations n’avaient aucune visibilité sur le contenu de ces produits et ne disposaient d’aucun moyen de pression pour accélérer la réponse de l’éditeur.
C'est là que le problème de dépendance vis-à-vis des fournisseurs se manifeste le plus clairement. Lorsque vous déployez une application tierce, vous héritez de l'intégralité de son graphe de dépendances, y compris des composants que vous ne pouvez ni voir, ni mettre à jour, ni remplacer. Pour les équipes de sécurité, cela signifie que votre surface d'attaque s'étend au-delà du code écrit par vos ingénieurs pour englober celui écrit par vos fournisseurs, puis celui écrit par leurs fournisseurs, et ainsi de suite.
LE PROBLÈME DE LA VISIBILITÉ, EN TERMES SIMPLES
La plupart des entreprises ne savent pas exactement ce qui s'exécute dans leurs environnements. Elles savent ce qu'elles ont déployé, mais elles ne savent pas toujours ce que contenaient ces déploiements. Log4j a rendu cette lacune particulièrement grave, au point qu'il est désormais difficile d'y remédier.
La leçon à en tirer : l'affaire Log4j n'était pas un cas isolé
Il serait tentant de considérer Log4j comme une anomalie – une catastrophe qui ne survient qu’une fois tous les dix ans, provoquée par une fonctionnalité exceptionnellement dangereuse dans une bibliothèque exceptionnellement répandue. Ce point de vue est exact dans son ampleur, mais trompeur dans son essence. Les conditions qui ont rendu Log4Shell si destructeur existent largement dans l’écosystème Java et donneront lieu à l’avenir à des incidents de même nature.
L'écosystème Java comporte un immense patrimoine de code. Des bibliothèques écrites il y a quinze ans, à une époque où les pratiques de sécurité étaient différentes et où les modèles de menace étaient plus restreints, sont encore utilisées aujourd'hui en production. Certaines constituent des dépendances directes d'applications qui n'ont pas été modifiées depuis des années. D'autres sont des dépendances transitives de frameworks qui les ont intégrées il y a longtemps et n'ont pas trouvé de raison de les supprimer.
Contrairement aux écosystèmes de gestion de paquets plus modernes, les outils de compilation de Java permettent de regrouper facilement tous les éléments dans un seul artefact déployable, ce qui signifie que l'ancien code, vulnérable, coexiste avec le nouveau code, de manière invisible, jusqu'à ce qu'un scanner ou un incident le mette en évidence. La force de cet écosystème (rétrocompatibilité, stabilité, large disponibilité des bibliothèques) constitue également son point faible en matière de sécurité.
Les candidats potentiels à un prochain incident de l'ampleur de celui de Log4j ne manquent pas. Le classe StringSubstitutor (CVE-2022-42889, divulguée en octobre 2022) a suscité une inquiétude comparable, car elle pouvait permettre l’exécution de code à distance via une interpolation de variables non sécurisée, même si son exploitabilité en conditions réelles s’est avérée bien plus limitée que celle de Log4Shell. L’écosystème plus large d’Apache Commons, les diverses bibliothèques d’analyse XML, les utilitaires liés à JNDI et RMI : voilà le type de composants qui sont présents depuis longtemps dans les applications Java, qui font l’objet d’une attention moindre en matière de sécurité que les bibliothèques plus récentes, et qui pourraient très bien contenir la prochaine faille CVE critique.
Comment les équipes s'adaptent
La réaction face à l'incertitude mise en évidence par Log4j a donné lieu à un ensemble de pratiques qui s'imposent progressivement comme la norme au sein des organisations qui prennent au sérieux les risques liés aux dépendances. Aucune d'entre elles ne résout entièrement le problème. Ensemble, elles permettent toutefois de réduire considérablement cette incertitude.
01 Nomenclatures logicielles (SBOM)
Les équipes génèrent des SBOM lisibles par machine dans le cadre du processus de compilation. L’utilisation d’outils tels que Syft, CycloneDX ou le plugin SBOM de Maven permet de créer un enregistrement vérifiable de chaque composant d’un artefact de déploiement, y compris les dépendances transitives. Les SBOM n’empêchent pas l’apparition de vulnérabilités, mais elles permettent de dresser un inventaire. Lorsque la prochaine faille de type Log4j se présentera, les organisations disposant de SBOM à jour pourront déterminer si elles sont concernées en quelques heures plutôt qu’en plusieurs jours.
02 Analyse continue des dépendances dans le cadre du CI/CD
Ils font également évoluer l’analyse des vulnérabilités, passant d’audits périodiques à des contrôles en intégration continue. L’utilisation d’outils tels que Grype, OWASP Dependency-Check ou Snyk permet de passer d’une approche réactive à une approche préventive. Les nouvelles vulnérabilités présentes dans les dépendances existantes sont détectées immédiatement, plutôt qu’à l’occasion de la prochaine revue trimestrielle. Le défi consiste à gérer la « fatigue des alertes » : toutes les vulnérabilités CVE signalées ne sont pas nécessairement exploitables dans le contexte donné, et les résultats indifférenciés des scanners finissent rapidement par être ignorés.
03 Surveillance de l'exécution et détection des comportements
L'analyse statique détecte les vulnérabilités connues dans les composants connus. Elle ne détecte pas les tentatives d'exploitation visant des vulnérabilités qui n'étaient pas encore connues au moment de l'analyse. Sur les déploiements hérités fonctionnant encore sous les versions JDK 17 à 23, le Java Security Manager peut offrir des contrôles limités, mais il a été déprécié en vue de sa suppression dans Java 17 et définitivement désactivé dans le JDK 24. La protection moderne en temps d'exécution repose donc désormais sur des agents RASP et une surveillance au niveau du réseau des modèles de recherche JNDI suspects – une couche de détection qui opère en temps d'exécution plutôt qu'au moment de la compilation.Cela s’avère particulièrement utile pour les systèmes hérités où l’analyse statique est difficile à mettre en place a posteriori.
04 Responsabilité explicite et accords de niveau de service (SLA) relatifs aux mesures correctives
Les flous en matière de responsabilité qui ont ralenti la réaction face à Log4j dans de nombreuses organisations n’étaient pas des problèmes techniques, mais des problèmes de processus. Définir clairement les responsabilités pour chaque application déployée, y compris les services hérités, et établir des accords de niveau de service (SLA) explicites pour la correction des vulnérabilités critiques (avec des procédures d’escalade en cas d’ambiguïté quant à la responsabilité) permet de transformer la question « Qui doit corriger cela ? », qui constituait auparavant un obstacle récurrent, en un processus bien encadré.
05 Couverture de sécurité étendue pour les bibliothèques, au-delà de l'assistance standard
Pour les applications Java utilisant d’anciennes versions de bibliothèques qui ne font plus l’objet d’une maintenance active, la réponse habituelle est « mettre à niveau ». Lorsque les mises à niveau ne sont pas envisageables en raison de contraintes imposées par les éditeurs, de gels réglementaires ou de systèmes hérités fragiles, les équipes ont besoin d’un moyen de recevoir des correctifs de sécurité sans passer à une nouvelle version majeure. Des services tels que Endless Lifecycle Support (ELS) for Libraries de TuxCare fournissent des correctifs de sécurité rétroportés pour les versions de bibliothèques couvertes, aidant ainsi les équipes à maintenir une configuration stable et connue, protégée contre les vulnérabilités actuelles, tout en planifiant une migration à plus long terme. Il s’agit d’une solution intermédiaire, et non d’une solution définitive, mais elle revêt une importance particulière lorsque l’alternative consiste à continuer d’utiliser un logiciel non corrigé, car la mise à niveau n’est prévue que dans plusieurs mois.
Accepter l'incertitude résiduelle
Il existe une version de cette conversation qui se termine par une liste de mesures à prendre : mettre en place des SBOM, déployer des outils d'analyse, définir les responsabilités, gérer les créneaux de support. Il suffit de suivre ces étapes pour résoudre le problème. Cette version est plus simple que la réalité.
En toute honnêteté, il faut reconnaître que les systèmes logiciels complexes comportent une incertitude résiduelle qui ne peut être totalement éliminée, mais seulement gérée. Vous ne parviendrez pas à avoir une visibilité totale sur toutes les dépendances de votre environnement. Vous ne pourrez pas corriger toutes les bibliothèques vulnérables avant la publication du prochain CVE critique. Les logiciels fournis par les éditeurs continueront de contenir des composants que vous ne pouvez ni voir ni contrôler.
Ce que vous pouvez faire, c'est prendre des décisions mûrement réfléchies quant aux domaines dans lesquels vous souhaitez investir pour réduire cette incertitude, plutôt que de la laisser s'accumuler de manière invisible jusqu'à ce qu'un incident vienne forcer le débat. Log4j a notamment joué le rôle d'un catalyseur, marquant le moment où le coût du risque lié aux dépendances invisibles est devenu indéniable.
Les équipes qui sont sorties renforcées de la crise Log4Shell ne sont pas celles qui ont appliqué les correctifs le plus rapidement. Ce sont celles qui ont considéré cet incident comme une source d’informations sur leurs propres systèmes : ce qu’elles ignoraient, les failles dans leurs processus, les parties de leur infrastructure dont la responsabilité n’était pas clairement attribuée. Elles ont profité de cette perturbation pour mettre en place une solution plus durable qu’un simple fichier JAR corrigé.
Cette question devrait être au cœur de chaque audit de sécurité mené après la faille Log4j. La question n’est jamais simplement de savoir si vous avez appliqué le correctif, mais dans quelle mesure vous êtes sûr de cette réponse – et quelles mesures vous prenez pour combler cette faille.
Découvrez le service « Endless Lifecycle Support » (ELS) de TuxCare dédié aux bibliothèques →
