Quand Apache Log4j atteindra sa fin de vie, les CVE ne cesseront pas pour autant.
Versions prises en charge : 1.2.x, 2.17.x, 2.18.x
Apache a cessé de publier des correctifs pour Log4j 1.x en 2015 et pour Log4j 2.17–2.18 en 2022. Le service « Never-Ending Support for Apache Log4j » garantit que ces versions que vous utilisez déjà restent sécurisées, conformes et prêtes pour les audits, même après que le développeur en amont a cessé de publier des correctifs. Pas de migration, pas de modification du code, pas de nouvelle version à adopter.
RECONNU PAR LES GRANDES ENTREPRISES

Sécurité, conformité et continuité : des défis à relever ensemble
Grâce à une solution de remplacement fiable et prête à l'emploi pour les versions d'Apache Log4j arrivées en fin de vie, vos outils de scan cesseront définitivement de signaler les vulnérabilités Log4j répertoriées dans la base CVE.
Sécurité
Une nouvelle version est publiée chaque fois qu'une vulnérabilité Log4j (CVE) est détectée, validée et corrigée sur des versions d'Apache pour lesquelles Apache ne fournit plus de correctifs, le tout développé par des ingénieurs possédant une expertise de responsable principal de cette pile logicielle.
La mise à disposition des correctifs dans le cadre du SLA est liée au niveau de gravité
HeroDevs est une autorité de numérotation CVE agréée qui publie les vulnérabilités découvertes.
Conformité
Une fois installés, les scanners cessent de signaler les vulnérabilités Log4j répertoriées dans la base CVE, car la bibliothèque fait l'objet de correctifs réguliers et bénéficie d'un support technique commercial, ce qui permet de transformer les constatations d'audit en suspens en constatations résolues.
SOC 2, PCI DSS, HIPAA, FedRAMP, ISO 27001, NIS2 et bien d'autres encore
Historique documenté des correctifs à l'intention des auditeurs
Continuité des activités
Une véritable solution prête à l'emploi : mêmes coordonnées Maven, même processus de compilation et de CI/CD, aucune modification du code de l'application. Le framework ou la plateforme à l'origine du problème avec Log4j pourra être traité(e) en temps voulu.
Il faudra des mois, voire des années, pour mener à bien cette migration
Une fraction du coût de la migration ou du coût d'une faille de sécurité.
Log4j 1
Apache a annoncé la fin de vie de Log4j 1.x le 5 août 2015. Aucun correctif n'a été publié en amont depuis la version 1.2.17, et les vulnérabilités révélées après cette date ne sont toujours pas corrigées dans la dernière version d'Apache.
Log4j 2
Apache assure la maintenance de Log4j 2 uniquement pour sa branche de versions actuelle. Les branches 2.17 et 2.18 ont atteint leur fin de maintenance en juin et septembre 2022 ; par conséquent, les applications qui y sont verrouillées ne bénéficient d'aucun des correctifs inclus dans les versions actuelles de Log4j 2.
Chaque correctif que nous publions fait l'objet d'une entrée CVE publiée
HeroDevs est une autorité de numérotation CVE (CNA) agréée, habilitée par le programme CVE à identifier et à attribuer des identifiants CVE aux failles de sécurité découvertes par HeroDevs.
Chaque version de NES pour Apache Log4j est fournie avec des instructions VEX de HeroDevs, à raison d’une par CVE, indiquant précisément l’artefact et la version contenant le correctif.
Si vous utilisez actuellement des versions obsolètes d’Apache Log4j, vos applications sont potentiellement exposées. NES for Apache Log4j s’installe en quelques minutes.
Ce que publie NES for Apache Log4j 2
Tous les modules org.apache.logging.log4j en amont publiés pour les versions 2.17.2 et 2.18.0 sont disponibles sous les coordonnées NES.
Cœur de métier
log4j-api
log4j-core
log4j-bom
Mises en page et compatibilité
log4j-modèle-de-mise-en-page-json
log4j-1.2-api
log4j-slf4j-impl
log4j vers slf4j
log4j-jul
log4j-jcl
Intégration
log4j -spring-boot
log4j-spring-cloud-config-client
log4j-web
log4j-jakarta-web
log4j-appserver
log4j-jdbc-dbcp2
Une réponse solide pour chaque norme, cadre ou réglementation.
Les logiciels en fin de vie (EOL) compromettent les attentes en matière de gestion des correctifs dans le cadre des réglementations internationales. NES vous propose une version maintenue et prise en charge par le fournisseur, assortie de contrats de niveau de service (SLA) garantis et d'un historique documenté des correctifs, afin de démontrer votre conformité aux auditeurs et aux autorités de régulation.
PCI DSS
La exigence 6.3.3 impose que les vulnérabilités connues de niveau « critique » et « haute gravité » soient corrigées dans un délai de 30 jours. L'utilisation d'Apache Log4j en fin de vie (EOL) sans correctif en amont vous met en situation de non-conformité. NES rétablit la chaîne de correctifs.
HIPAA
Les infrastructures non prises en charge compliquent la mise en place de mesures de sécurité adéquates pour les systèmes traitant des données de santé électroniques protégées (ePHI). NES assure une maintenance active et une réduction des risques.
SOC 2
Les critères relatifs aux services de confiance exigent une correction rapide des vulnérabilités et une gestion efficace des correctifs. Les dépendances en fin de vie (EOL) donnent lieu à des constatations significatives lors des audits, à moins qu’il n’existe une solution de remplacement. NES constitue cette solution de remplacement.
NIS2
L'article 21 traite de la gestion des correctifs, des vulnérabilités et de la chaîne d'approvisionnement. L'utilisation de logiciels en fin de vie (EOL) sans support technique continu présente un risque que la directive NIS2 attend des opérateurs qu'ils s'efforcent activement d'atténuer.
DORA
DORA considère les logiciels en fin de vie (EOL) comme une faille de résilience pour les actifs informatiques financiers. NES vous propose une version maintenue et un programme documenté de gestion des correctifs.
Loi sur la cyber-résilience
Assure la sécurité tout au long du cycle de vie logiciel des produits comportant des éléments numériques. NES vous fournit une version maintenue et corrigée de votre gamme Apache Log4j en fin de vie (EOL) pendant toute la durée de la couverture.
NIST CSF 2.0
La directive PR.PS-02 impose aux organisations de maintenir activement à jour ou de supprimer les logiciels vulnérables en fonction des risques. NES permet de se conformer à cette directive sans mise à jour forcée.
FedRAMP
La surveillance continue implique la correction des failles selon une fréquence définie. Une version corrigée et prise en charge par le fournisseur fournit à votre responsable de la sécurité des systèmes d'information (ISSO) la procédure de correction documentée nécessaire pour justifier le maintien d'Apache Log4j en fin de vie (EOL) dans le périmètre d'autorisation.
Contrats commerciaux
Les mesures de gestion des vulnérabilités et des configurations impliquent d'identifier les vulnérabilités techniques et de veiller à ce que les logiciels respectent les normes de sécurité. NES rétablit cette conformité pour les logiciels en fin de vie.
Nous nous associons à des contributeurs essentiels
Nous collaborons avec des ingénieurs spécialisés dans l'open source et des contributeurs de l'écosystème afin de garantir que nos produits « Never-Ending Support » offrent la même qualité que celle à laquelle vous êtes habitués avec les versions originales.
En faisant appel à des ingénieurs possédant une expertise approfondie du projet, nous établissons une nouvelle norme en matière de maintenance des logiciels open source afin de garantir que NES pour Log4j soit aussi fiable que la technologie en amont sur laquelle il repose.


Nous contribuons à l'open source
Les responsables de projets open source accomplissent un travail essentiel, mais sont rarement rémunérés pour cela.
HeroDevs investit 20 millions de dollars pour changer la donne : l'organisation finance les créateurs et les projets qui assurent le bon fonctionnement de l'écosystème, grâce à des subventions allant de 2 500 à 250 000 dollars.
Nous avons écrit des correctifs pour des bases de code non maintenues, identifié des vulnérabilités que personne d’autre n’avait repérées et assuré le fonctionnement sécurisé de systèmes critiques sans avoir à les réécrire à la hâte. Ce fonds s’appuie sur ce travail afin que les mainteneurs puissent continuer à faire ce qu’ils font le mieux.
Questions fréquemment posées
Versions maintenues de Log4j 1.2.x, Log4j 2.17.x et Log4j 2.18.x proposées par HeroDevs. Les correctifs de sécurité sont intégrés dans des branches dérivées des dernières versions en amont (1.2.17, 2.17.2 et 2.18.0) et publiées sous les mêmes coordonnées Maven avec une chaîne de version NES ; ainsi, il suffit de modifier une seule version, sans rien changer d’autre.
Oui. Apache a annoncé la fin de vie de Log4j 1.x le 5 août 2015, et les vulnérabilités révélées après la version 1.2.17 ne sont toujours pas corrigées dans la dernière version publiée par Apache. NES for Apache Log4j les corrige sous les mêmes coordonnées log4j:log4j.
Trois versions réparties sur deux générations : Log4j 1.2.x (groupId log4j), ainsi que Log4j 2.17.x et 2.18.x (groupId org.apache.logging.log4j). Toutes nécessitent Java 8 ou une version ultérieure. Les versions actuelles de Log4j 2 publiées par Apache ne sont pas des versions NES et n'en ont pas besoin.
Apache a corrigé la faille Log4Shell (CVE-2021-44228) et ses suites dans les versions 2.15 à 2.17.1 de Log4j. Les versions dérivées de NES, à savoir 2.17.2 et 2.18.0, intègrent déjà ces correctifs ; par conséquent, NES n’applique pas de correctif pour Log4Shell et ne prétend pas le faire. NES corrige les vulnérabilités divulguées après ces versions, qu’Apache ne corrige que dans la version actuelle de Log4j 2. Log4j 1.x n’est pas concerné par la faille CVE-2021-44228 ; son JMSAppender présente toutefois une faille connexe, CVE-2021-4104, que NES corrige.
Les identifiants de groupe et d'artefact ne changent pas. Pour Log4j 1, vous devez définir `log4j:log4j` sur la version NES. Pour Log4j 2, vous devez définir la propriété `log4j2.version` de l'Spring Boot ou importer `log4j-bom` à la version NES, ajouter le registre HeroDevs, puis recompiler. La configuration de la journalisation et le code de l'application restent inchangés.
De nombreux environnements le peuvent et le devraient. Ceux qui ne le peuvent pas sont limités par d’autres facteurs : une liste de composants (BOM) de l’ Spring , du serveur d’applications, un SDK fournisseur, un POM parent partagé ou une certification couvrant précisément l’ensemble des dépendances. Pour Log4j 1, l’écart est encore plus important, car Log4j 2 utilise une API et un format de configuration différents. NES assure la continuité de votre environnement en attendant que ce travail soit réalisé.
Les versions NES pour Apache Log4j 1.2.x, 2.17.x et 2.18.x sont incluses dans le pack « NES pour Spring Boot 2.7 Managed Dependencies ». Cette page s'adresse aux équipes qui utilisent Log4j en dehors de ce pack.
Chaque correctif est fourni avec une déclaration VEX de HeroDevs et une chaîne de version NES reconnaissable par les scanners, ce qui constitue la preuve exigée par les auditeurs dans le cadre des normes PCI DSS, SOC 2, HIPAA, NIS2, DORA et de la CRA de l'UE. HeroDevs est une autorité de numérotation CVE.
NES assure la maintenance des versions 1.2, 2.17 et 2.18 tant qu'elles sont en production. Une migration, lorsqu'elle a lieu, part d'une base de référence sécurisée plutôt que d'un incident.
Nous contacter
Vous avez des questions sur l'assistance permanente pour votre bibliothèque open-source ? Nous sommes là pour vous aider !
Découvrez comment les produits NES de HeroDevs peuvent assurer la sécurité et la conformité de vos systèmes.
Découvrez comment nos solutions peuvent apporter de la valeur à votre organisation.
Obtenez des informations détaillées sur les prix, adaptées à vos besoins.
Ressources
Voir tous les articles


