Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Vous vous souvenez de décembre 2021 ? Cette panique générale qui s'est emparée de tout le monde lorsque la faille Log4Shell a été révélée et que, du jour au lendemain, toutes les équipes d'ingénieurs de la planète se sont précipitées pour vérifier si elles utilisaient Log4j, où il se cachait dans leur infrastructure et à quelle vitesse elles pouvaient l'appliquer ?
La plupart des équipes pensent que cette histoire s'est terminée début 2022. Elles ont corrigé leurs applications, analysé leurs dépendances, peut-être mis à jour quelques bibliothèques, puis sont passées à autre chose. Log4j est devenu l'un de ces incidents dont on se souvient avec le recul : stressant sur le moment, mais désormais résolu.
Sauf que le problème n'est pas réglé. Loin de là.
En réalité, le risque lié à la vulnérabilité Log4j n’a pas disparu après la première vague de mesures correctives Log4Shell. Il est simplement devenu plus discret et plus difficile à détecter. Aujourd’hui, en 2026, des instances Log4j vulnérables se cachent toujours dans les environnements de production, enfouies dans des recoins que les équipes ont cessé d’inspecter il y a des années. Et ce n’est pas parce que les équipes d’ingénieurs sont négligentes : c’est parce que la nature même du fonctionnement des dépendances logicielles fait que l’affirmation « nous l’avons corrigé une fois » donne souvent un faux sentiment de sécurité.
Voyons où se situe réellement le risque lié à Log4j aujourd’hui, pourquoi il ne cesse de refaire surface, et à quoi ressemblent les mesures d’atténuation réellement efficaces lorsqu’on a affaire à des piles logicielles modernes comportant de multiples couches de dépendances cachées.
Le paysage des vulnérabilités Log4j au-delà de Log4Shell
Log4Shell (CVE-2021-44228) a fait la une des journaux, et à juste titre. Une faille permettant l'exécution de code à distance dans une bibliothèque de journalisation utilisée par la moitié de l'écosystème Java est à peu près ce qu'il y a de pire. Mais se concentrer uniquement sur Log4Shell, c'est comme s'inquiéter du requin que l'on voit tout en ignorant ceux qui tournent sous la surface.
Depuis Log4Shell, plusieurs autres vulnérabilités de Log4j ont été découvertes. Les CVE-2021-45046, CVE-2021-45105, CVE-2021-44832 et d’autres ont suivi à un rythme relativement soutenu. Chacune d’entre elles a nécessité une attention particulière, chacune a nécessité des correctifs, et chacune a démontré que Log4j, en tant que composant, présentait des problèmes de sécurité plus profonds que la seule et unique vulnérabilité RCE qui avait fait grand bruit.
Ce qui est particulièrement insidieux, c'est que ces vulnérabilités ultérieures touchent souvent des plages de versions différentes de celles de Log4Shell. Une équipe ayant effectué une mise à niveau de Log4j 2.14.1 vers la version 2.15.0 pour corriger Log4Shell aurait pu être exposée à la vulnérabilité CVE-2021-45046. La mise à niveau vers la version 2.16.0 a résolu ce problème, mais les versions plus anciennes restaient exposées à la vulnérabilité CVE-2021-44832. Ce jeu de cache-cache avec les vulnérabilités a compliqué le suivi des versions « sûres », et de nombreuses organisations ont perdu la trace des systèmes ayant été entièrement corrigés par rapport à ceux ayant reçu un correctif partiel.
Et puis il y a l'éléphant dans la pièce : Log4j 1.x. Alors que la panique générale s'est principalement concentrée sur les vulnérabilités de Log4j 2.x, Log4j 1.x présente ses propres problèmes de sécurité et a atteint sa fin de vie en 2015. Pourtant, il est toujours en circulation, fonctionnant dans des systèmes de production qui n’ont jamais migré vers Log4j 2.x. Ces systèmes sont exposés à des vulnérabilités qui ne feront jamais l’objet de correctifs officiels, car le code source a été abandonné.
Le paysage des vulnérabilités n'est pas non plus immuable. Les chercheurs en sécurité continuent de découvrir des failles dans les bibliothèques de journalisation. L'attention que l'affaire Log4Shell a attirée sur Log4j et les composants similaires signifie que davantage de personnes sont à l'affût de problèmes. Il serait naïf de penser que nous avons découvert la dernière vulnérabilité de Log4j.
Où se cache Log4j dans les piles logicielles modernes
Si le risque lié à Log4j persiste, ce n’est pas parce que les équipes l’ignorent délibérément. C’est simplement parce qu’il est vraiment difficile de repérer toutes les occurrences de Log4j dans une pile d’applications moderne.
Les dépendances transitives constituent la cachette la plus courante. Votre application ne dépend peut-être pas directement de Log4j, mais l'une de vos dépendances en dépend. Ou bien l'une des dépendances de vos dépendances en dépend. Ou encore, vous vous trouvez à plusieurs niveaux de profondeur dans une arborescence de dépendances et, quelque part là-dedans, enfoui trois niveaux plus bas, se trouve Log4j 2.14.0.
Les outils d'analyse des dépendances sont utiles, mais ils ne sont pas parfaits. Ils peuvent vous renseigner sur les dépendances connues figurant dans les fichiers de dépendances déclarés de votre projet, mais ils ne détectent pas toujours tout. Il arrive que certaines bibliothèques masquent des dépendances, en les regroupant en interne d'une manière qui n'apparaît pas lors d'une analyse standard des dépendances. Parfois, la dépendance se trouve dans un artefact binaire que votre outil d'analyse n'examine pas de manière suffisamment approfondie.
Les applications conteneurisées présentent leurs propres défis. Il se peut que vous utilisiez des images de conteneurs créées il y a plusieurs mois, voire plusieurs années, avant que Log4Shell ne soit connu. L'image de base peut contenir des versions vulnérables de Log4j. Les couches applicatives peuvent en ajouter d'autres. À moins que vous ne reconstruisiez et ne réanalysiez régulièrement vos images, ces vulnérabilités persistent même si votre code source actuel est sain.
Les applications tierces et les logiciels commerciaux intègrent souvent leurs propres dépendances, y compris Log4j. Cet outil de surveillance d'entreprise que vous avez déployé en 2020 ? Il est possible qu'il exécute Log4j 2.12.1 en interne, et vous n'en avez aucune visibilité car il s'agit d'une boîte noire du fournisseur. Le fournisseur a peut-être publié une version corrigée, mais si vous ne suivez pas de près ses avis de sécurité ou si les mises à niveau nécessitent des tests importants et des temps d'arrêt, cette instance vulnérable persiste.
Vous pouvez également consulter notre guide technique sur la mise en œuvre d'un correctif pour la vulnérabilité Log4j afin d'identifier les dépendances cachées au sein de piles complexes.
Les outils de compilation et les environnements de développement contiennent parfois des versions vulnérables de Log4j qui ne font pas directement partie de votre application de production, mais qui représentent néanmoins un risque. Les plugins Jenkins, les référentiels Maven, les extensions IDE : tous peuvent contenir Log4j, et ils ne sont pas toujours inclus dans les analyses de vulnérabilité axées sur la production.
Les systèmes hérités et les bases de code figées sont sans doute les plus difficiles à gérer. Cette application Java critique qui fonctionne sans changement depuis cinq ans parce qu’elle est stable et que « personne ne veut y toucher » ? Elle contient probablement une version vulnérable de Log4j. Mais la mettre à niveau implique de la tester avec les versions actuelles du JDK, de valider des intégrations qui n’ont pas été modifiées depuis des années, et de découvrir potentiellement que des dépendances critiques ne sont plus maintenues.
Les composants et appareils embarqués complètent la liste. Les périphériques réseau, les appliances de sécurité, les systèmes IoT et d'autres applications Java embarquées utilisent souvent Log4j en interne. Ce sont généralement les plus difficiles à corriger, car les mises à jour doivent provenir du fournisseur, les cycles de mise à niveau sont lents et, parfois, le fournisseur lui-même a cessé ses activités ou a arrêté de prendre en charge le produit.
Le point commun à tous ces scénarios est l'invisibilité. Ces instances Log4j n'apparaissent pas dans l'arborescence des dépendances de votre application principale. Elles ne sont pas prises en compte par vos processus de mise à jour habituels. Elles se glissent dans les interstices entre ce que vous pensez exécuter et ce qui est réellement déployé.
Pourquoi l'argument « on l'a déjà corrigé » ne tient pas la route
Même les équipes qui ont procédé à une mise à niveau complète fin 2021 et début 2022 constatent souvent que des instances vulnérables de Log4j refont surface dans leurs environnements. Cela n’est pas dû à une annulation des correctifs, mais au fait que les écosystèmes logiciels sont dynamiques.
- Les nouveaux déploiements introduisent d'anciennes vulnérabilités. Un développeur met en place un nouveau microservice à partir d'un modèle de projet datant de 2020. Ce modèle comprend des dépendances plus anciennes. À moins que votre gestion des dépendances ne soit extrêmement rigoureuse, ce nouveau service risque d'être livré avec une version vulnérable de Log4j, même si votre organisation a « corrigé » Log4j il y a deux ans.
- Les mises à jour des dépendances peuvent annuler les correctifs. Vous mettez à jour une bibliothèque sans rapport avec le problème, et celle-ci intègre une version plus ancienne de l'une de ses dépendances, ce qui réintroduit par transitivité une version vulnérable de Log4j. Vos règles de résolution des dépendances ne sont peut-être pas assez strictes pour empêcher cela, ou l'algorithme de résolution des conflits de versions choisit la version vulnérable pour des raisons de compatibilité.
- Les acquisitions et les intégrations s'accompagnent de code externe. Votre entreprise rachète une autre société ou s'intègre au système d'un partenaire. Du jour au lendemain, vous êtes responsable de leur base de code, qui n'a peut-être pas bénéficié de la même attention que la vôtre en matière de correction Log4j.
- L'informatique fantôme et les déploiements non officiels contournent vos processus standard. Une équipe déploie quelque chose à la hâte, en sautant les analyses de sécurité et les processus de validation habituels. Ou bien quelqu’un met en place un service « temporaire » qui finit par devenir permanent. Ces déploiements non autorisés contiennent souvent des vulnérabilités que vous pensiez avoir éliminées.
- Restauration à partir d'une sauvegarde et reprise après sinistre peuvent faire resurgir des versions vulnérables. Vous restaurez un système à partir d'une sauvegarde effectuée avant que Log4Shell ne soit connu. Ou vous reconstruisez un service à partir d'artefacts de déploiement archivés. À moins de vérifier spécifiquement la présence de Log4j dans ces scénarios de reprise, vous risquez de remettre du code vulnérable en production.
Le problème fondamental est que la sécurité logicielle n'est pas un état que l'on atteint, mais un processus qu'il faut entretenir. Le fait d'avoir « appliqué les correctifs » n'est pas un état permanent. Cela exige une vigilance constante, des analyses régulières et une prise de conscience permanente de ce qui est réellement en cours d'exécution par rapport à ce que l'on pense qu'il devrait être.
L'évaluation des risques dans la pratique
Toutes les instances de Log4j ne présentent pas le même niveau de risque. En évaluant correctement votre exposition réelle, vous pouvez hiérarchiser vos mesures correctives de manière judicieuse, plutôt que de traiter chaque cas comme une crise d'une urgence identique.
- C'est l'exposition qui importe le plus. Une instance Log4j vulnérable dans une application web accessible depuis Internet qui traite des données utilisateur non fiables présente un risque élevé. Une instance Log4j vulnérable dans un traitement par lots interne qui ne traite que des données structurées provenant de sources fiables présente un risque moindre. La vulnérabilité est la même, mais son exploitabilité pratique est différente.
- La sensibilité des données aggrave les risques. Les systèmes qui traitent des informations de paiement, des dossiers médicaux personnels ou d'autres données réglementées sont davantage exposés aux vulnérabilités de Log4j. Une violation ne se traduit pas seulement par une faille technique : elle entraîne des infractions à la conformité, une responsabilité juridique et des sanctions réglementaires.
- Le positionnement du réseau influe sur la vulnérabilité. Les vulnérabilités Log4j présentes dans des systèmes accessibles uniquement depuis des réseaux internes sont moins facilement exploitables dans l'immédiat que celles exposées à l'Internet public. Cela ne les rend pas pour autant sûres, mais cela modifie le modèle de menace et l'urgence de la correction.
- La disponibilité des exploits influe sur le calendrier. Dès que des exploits fonctionnels ciblant une vulnérabilité spécifique de Log4j sont rendus publics et activement utilisés par les attaquants, la marge de manœuvre pour une correction en toute sécurité se réduit considérablement. Les vulnérabilités antérieures, pour lesquelles il existe des écosystèmes d'exploits bien établis, sont plus dangereuses que les failles récemment découvertes qui en sont encore au stade de la recherche.
- Les mesures de compensation réduisent le risque réel. Si des instances Log4j vulnérables sont protégées par des pare-feu d'applications web configurés pour bloquer les modèles de recherche JNDI, ou si des outils de protection des applications en exécution surveillent les tentatives d'exploitation, le risque concret est moindre que dans le cas de déploiements totalement dépourvus de protection. Ces mesures ne remplacent pas l'application de correctifs, mais elles ont une incidence sur l'évaluation du risque.
L'objectif de l'évaluation des risques n'est pas de justifier l'inaction. Il s'agit plutôt de vous aider à affecter vos ressources limitées en matière de correction aux domaines où elles auront le plus d'impact sur votre niveau de sécurité réel.
Stratégies pratiques d'atténuation
Vous avez donc identifié des vulnérabilités Log4j dans votre environnement. Certaines sont faciles à corriger, d'autres sont plus complexes. Voici à quoi ressemble une stratégie d'atténuation réellement efficace.
Une analyse approfondie avant tout
On ne peut pas réparer ce qu'on ne trouve pas. Misez sur un diagnostic approfondi avant de vous lancer dans des solutions de fortune.
Utilisez plusieurs méthodes d'analyse : analyse des dépendances du code source, analyse des images de conteneurs, analyse binaire des artefacts déployés et détection en temps réel. Chaque méthode permet de détecter des éléments différents. L'analyse du code source identifie les dépendances déclarées. L'analyse des conteneurs détecte les vulnérabilités des images de base. L'analyse binaire identifie les dépendances masquées. La détection en temps réel identifie ce qui est réellement chargé en production.
Ne vous limitez pas à analyser l'environnement de production. Vérifiez également les environnements de développement, les systèmes de compilation, les environnements de préproduction et tout autre endroit où le code est exécuté. Une vulnérabilité Log4j sur l'ordinateur portable d'un développeur ne représente peut-être pas un risque immédiat pour la production, mais elle constitue une dette technique et une exposition potentielle à l'avenir.
Consignez vos conclusions de manière détaillée : précisez quels systèmes sont concernés, quelles versions de Log4j sont utilisées, quels chemins d'exécution exploitent réellement la fonctionnalité de journalisation, et quelle est l'étendue de la vulnérabilité. Cet inventaire constituera votre feuille de route pour la correction.
Établir des priorités en fonction du risque réel
Commencez par corriger les cas présentant le plus grand risque. Il s'agit notamment des systèmes connectés à Internet, de ceux qui traitent des données sensibles et de tout système pour lequel on connaît des techniques d'exploitation actives.
Pour les systèmes présentant un risque moyen, mettez en place des mesures de contrôle compensatoires tout en planifiant les mesures correctives appropriées. Déployez des règles WAF, activez la surveillance en temps réel, restreignez l'accès au réseau et mettez en place des niveaux d'authentification supplémentaires. Ces mesures d'atténuation vous permettent de gagner du temps pour effectuer les mises à niveau dans les règles de l'art, plutôt que de les réaliser à la hâte.
Pour les systèmes présentant moins de risques, vous pouvez vous permettre des délais plus souples, mais ne laissez pas « moins de risques » devenir « jamais corrigé ». Fixez des échéances précises et respectez-les.
Mettre à niveau dès que possible
La solution appropriée pour remédier aux failles de Log4j consiste à passer à des versions corrigées. Pour Log4j 2.x, cela implique de passer au moins à la version 2.17.1, qui corrige toutes les failles majeures découvertes jusqu'au début de l'année 2022.
Testez minutieusement les mises à jour. Les changements de version de Log4j peuvent entraîner des différences de comportement, notamment en matière de configuration et de performances. Effectuez des tests de validation dans des environnements de préproduction fidèles à l'environnement de production avant le déploiement.
Si la mise à jour directe de Log4j n'est pas possible en raison de contraintes liées aux dépendances de niveau supérieur, essayez de mettre à jour les dépendances qui intègrent Log4j. Il arrive parfois qu'il faille mettre à jour plusieurs niveaux de votre arborescence de dépendances pour obtenir une version propre.
Migrer depuis Log4j 1.x
Si vous utilisez encore Log4j 1.x, vous travaillez avec un code qui n'est plus pris en charge ni mis à jour. La meilleure solution consiste à migrer vers un framework de journalisation moderne, tel que Log4j 2.x, Logback ou toute autre solution bénéficiant d'une maintenance régulière.
C'est souvent une tâche de grande envergure. Les formats de configuration ont changé. Les API ont évolué. Il faudra peut-être mettre à jour certaines dépendances. Mais c'est un travail indispensable qui aurait dû être fait il y a des années et qui ne peut être repoussé indéfiniment.
Planifiez la migration par étapes. Commencez par les systèmes les moins critiques afin de vous familiariser avec les processus et d'identifier les problèmes. Élaborez une documentation interne et des guides de migration. Passez ensuite systématiquement en revue vos systèmes de production.
Gérer les composants des fournisseurs et des tiers
Pour les logiciels commerciaux et les composants fournis par les éditeurs, consultez les avis de sécurité et les calendriers de mise à jour. De nombreux éditeurs ont publié des correctifs pour Log4j, mais ne les déploient pas automatiquement sur les installations de leurs clients.
Si les fournisseurs n'ont pas appliqué les correctifs à leurs logiciels, faites remonter l'information. Créez des tickets d'assistance, faites intervenir vos chargés de compte et indiquez clairement qu'il s'agit d'un obstacle à la poursuite de l'utilisation. Les fournisseurs réagissent à la pression exercée par les clients, surtout lorsqu'elle émane simultanément de plusieurs clients.
Pour les logiciels de fournisseurs critiques qui ne peuvent pas être mis à jour, mettez en place une isolation réseau et des mesures de sécurité supplémentaires. Ce n'est pas parce que vous ne pouvez pas appliquer de correctifs à ces logiciels que vous ne pouvez pas limiter leur exposition aux risques.
Quand la remise en état se heurte à un obstacle
Malgré tous vos efforts, certaines instances de Log4j résistent à la mise à niveau. Vous êtes confronté à des systèmes hérités non pris en charge qui ne peuvent pas être facilement mis à jour, à des logiciels de fournisseurs qui ne recevront plus de correctifs, ou à des applications personnalisées qui nécessiteraient d'importants travaux de refonte pour passer à des versions plus récentes de Log4j.
Dans ces cas de figure, les options de support de sécurité étendu offrent une alternative. Des services tels que ceux de TuxCare Endless Lifecycle Support for Log4j peuvent fournir des correctifs de sécurité pour les anciennes versions de logiciels qui ne sont plus prises en charge, y compris les instances Log4j héritées qui ne recevront plus de mises à jour officielles.
Ce n'est ni une solution à long terme, ni un prétexte pour éviter les mises à niveau nécessaires. Mais c'est une solution de secours pragmatique pour les situations où une correction immédiate n'est pas techniquement possible. Si vous êtes contraint d'utiliser Log4j 1.x dans une application héritée figée dont la migration prendrait dix-huit mois, le support prolongé permet de maintenir cette instance à jour contre les vulnérabilités connues pendant que vous mettez en œuvre votre plan de migration.
Considérez cela comme un moyen de gagner du temps sans pour autant assumer tous les risques liés à l'utilisation de logiciels non mis à jour. Vous devrez tout de même moderniser ces systèmes à terme, mais vous n'êtes pas contraint de procéder à des migrations précipitées qui pourraient entraîner de nouveaux problèmes ou perturber vos activités.
L'essentiel est d'être clair quant à la stratégie à adopter. Une assistance prolongée ne remplace pas une véritable remise en état : c'est un relais qui vous permet de procéder à cette remise en état selon un calendrier raisonnable, plutôt que sous la pression d'une situation de crise.
Mettre en place des pratiques de sécurité durables
La véritable leçon à tirer de l'affaire Log4j ne concerne pas cette bibliothèque en particulier. Elle porte sur la nature même des dépendances logicielles et sur la vigilance constante qu'il faut exercer pour assurer la sécurité des applications modernes.
- La gestion rigoureuse des dépendances doit être une pratique d'ingénierie fondamentale, et non quelque chose auquel on ne pense que lorsqu'une crise survient. Cela implique des audits réguliers des dépendances, des analyses automatisées dans les pipelines CI/CD, des politiques concernant les versions acceptables des dépendances, ainsi que des processus permettant d'évaluer et de mettre à jour les dépendances en continu.
- L'analyse de sécurité ne peut pas se limiter à une opération ponctuelle. Des vulnérabilités sont découvertes en permanence. Votre analyse doit s'exécuter en continu : en développement, en CI/CD, en production et dans tous les environnements intermédiaires. Ce qui était sûr hier peut être vulnérable aujourd'hui.
- La gestion des risques liés aux fournisseurs nécessite une surveillance active. Suivez les logiciels tiers que vous utilisez, surveillez les avis de sécurité des fournisseurs, évaluez leurs pratiques en matière de sécurité avant tout achat et prévoyez des accords de niveau de service (SLA) clairs concernant les mises à jour de sécurité dans les contrats avec les fournisseurs.
- Les procédures de gestion des incidents devraient inclure les vulnérabilités liées aux dépendances parmi les scénarios envisagés. Lorsque la prochaine vulnérabilité de type Log4Shell apparaîtra – et il y en aura une –, dans quel délai pourrez-vous identifier les systèmes affectés ? Comment établirez-vous les priorités en matière de correction ? Qui prendra les décisions concernant le niveau de risque acceptable et les délais ?
- Les choix architecturaux peuvent limiter l'impact des vulnérabilités. Les microservices aux dépendances isolées sont plus faciles à mettre à jour que les applications monolithiques dotées d'arborescences de dépendances massives. Les applications conteneurisées dont les images sont régulièrement reconstruites intègrent les mises à jour de sécurité plus naturellement que les machines virtuelles fonctionnant en continu. Une infrastructure immuable réduit la durée des fenêtres de vulnérabilité.
Votre plan d'action
Si vous lisez ces lignes et que vous vous demandez s'il reste des vulnérabilités Log4j cachées dans votre environnement, voici ce qu'il faut faire :
Effectuez des analyses approfondies dans tous les environnements en utilisant plusieurs méthodes d'analyse. Ne vous contentez pas de vérifier vos applications principales : examinez également les systèmes de compilation, les logiciels tiers, les charges de travail conteneurisées et les systèmes hérités.
Répertoriez vos découvertes avec suffisamment de détails pour évaluer les risques et planifier les mesures correctives. Ne vous contentez pas d'indiquer « Log4j 2.14.1 détecté », mais précisez plutôt « détecté dans un service API accessible aux clients, gérant le traitement des paiements, exposé à Internet ».
Établissez des priorités de manière rigoureuse en fonction du risque réel. Corrigez immédiatement les problèmes dangereux. Prévoyez des mesures correctives mûrement réfléchies pour les cas présentant un risque moyen. Ne négligez pas les cas à faible risque, mais ne les laissez pas entraver les tâches hautement prioritaires.
Mettez en place des mesures de compensation pour tout ce que vous ne pouvez pas corriger immédiatement. Règles WAF, segmentation du réseau, surveillance en temps réel : utilisez tous les outils à votre disposition pour réduire les possibilités d'exploitation.
Dans les situations où l'on se trouve véritablement dans une impasse, envisagez une assistance prolongée comme solution temporaire. Mais soyez honnête quant à ce qu'elle implique et ce qu'elle n'implique pas, et fixez des délais clairs pour une résolution définitive du problème.
La vérité qui dérange
La vulnérabilité Log4j n'est pas un problème que l'on résout une fois pour toutes. Il s'agit d'un risque de sécurité permanent qui nécessite une vigilance constante, des analyses régulières et des mesures correctives soutenues.
Les angles morts ne disparaîtront pas. Les dépendances continueront de dissimuler des versions vulnérables dans des endroits inattendus. Les systèmes hérités continueront de résister aux mises à jour simples. De nouvelles vulnérabilités Log4j pourraient encore être découvertes. Le travail n'est jamais vraiment terminé.
Mais ce n'est pas une raison pour sombrer dans le désespoir ou la paralysie. C'est une raison pour mettre en place des pratiques durables qui permettent de gérer ce type de risque de manière systématique plutôt qu'exceptionnelle. Les équipes qui considèrent la sécurité des dépendances comme un travail continu plutôt que comme une crise ponctuelle gèrent ces situations de manière bien plus efficace.
Il n'est pas nécessaire d'atteindre la perfection. Il faut rester vigilant, gérer les risques de manière intelligente et continuer à progresser. C'est ainsi que se traduit concrètement la sécurité durable.
La panique autour de Log4Shell est depuis longtemps retombée. Mais l'histoire de la faille de sécurité Log4j continue. Veillez à rester vigilant.
Pour bénéficier de mises à jour de sécurité à long terme qui vous protègent bien au-delà de la date de fin de vie, découvrez le support de cycle de vie illimité pour Log4j.
