Le délai prévu par le SLA pour corriger une vulnérabilité critique liée à une dépendance touche à sa fin, mais vous ne disposez pas de marge dans le sprint actuel pour effectuer les tests manuels nécessaires afin de vous assurer de ne pas perturber l'environnement de production. Le simple fait de ne pas respecter la date limite de correction constituera un constat dans votre prochain rapport SOC 2 ou ISO 27001, mais le risque d'exploitation augmente également avec les progrès des modèles d'IA. Vous n’avez d’autre choix que de faire face à deux mauvaises options : ralentir le développement du produit pour corriger cette vulnérabilité ou expliquer à votre équipe de sécurité et aux autres parties prenantes pourquoi vous n’avez pas respecté un SLA important.
Si ce scénario vous semble familier, vous n’êtes pas le seul. Les entreprises prennent de plus en plus de retard dans la course visant à corriger les vulnérabilités connues et à respecter leurs SLA en matière de sécurité. Une étude réalisée par Verizon, publiée en 2026, montre que l’exploitation des vulnérabilités est la première cause des violations confirmées, dépassant pour la première fois, en près de 20 ans d’existence de ce rapport, le vol d’identifiants.
La correction des failles continue de perdre du terrain en raison de l'explosion du nombre de vulnérabilités identifiées. D'après ce même rapport de Verizon, seules 26 % des vulnérabilités connues ayant fait l'objet d'une exploitation (KEV) ont été entièrement corrigées en 2025, contre 38 % l'année précédente, tandis que le délai médian de correction est passé à 43 jours, contre 32 l'année d'avant. Le rapport de Verizon attribue cette situation au fait que les entreprises ont 50 % de vulnérabilités critiques en plus à corriger.
Pourquoi est-ce que ça n'arrête pas de se produire ?
Il n’est pas absurde de s’attendre à ce que, à mesure que l’importance des vulnérabilités augmente, davantage de ressources soient consacrées à ce problème et que les correctifs suivent le rythme. Mais si vous travaillez dans ce domaine, vous savez que cela n’a tout simplement pas été le cas. Il y a deux raisons principales pour lesquelles ce problème s’aggrave au lieu de s’améliorer :
- Une grande partie des dépendances ne font pratiquement l'objet d'aucune maintenance, mais elles sont trop profondément ancrées dans les systèmes de production pour pouvoir être simplement supprimées ou facilement remplacées par une version majeure plus récente. Pensez à
log4j. - Les politiques SLA et les programmes de conformité ne tiennent pas compte de l'existence ou non d'un responsable de maintenance actif.
Ce que font les équipes aujourd'hui : les étapes du deuil lié à l'apprentissage d'une langue seconde (SLA)
Lorsque le temps vient à manquer, la plupart des équipes d'ingénieurs se retrouvent prises dans un cercle vicieux prévisible de mauvaises décisions. Ce phénomène ressemble beaucoup au modèle classique des cinq étapes du deuil de Kübler-Ross.
Déni : La plupart des équipes commencent par attendre un correctif en amont, mais rien ne garantit que le responsable de maintenance corrige la vulnérabilité, ni même quand il le fera, si tant est qu’il le fasse. Certains responsables corrigent le problème en quelques jours, voire moins, tandis que d’autres ne le font pas. Ce problème est exacerbé pour les paquets largement utilisés, mais qui ne font l’objet d’aucune maintenance et n’ont pratiquement pas de responsable. Attendre ne fait que faire tourner le compteur de votre SLA, sans pour autant corriger la vulnérabilité.
Colère : Supprimez et remplacez la dépendance problématique. Cela ressemble à une véritable solution, et c’en est probablement une pour aujourd’hui. Mais lorsque la nouvelle version du paquet fera l’objet d’un CVE le mois prochain, puis d’un autre le mois d’après, vous vous retrouverez pris dans un cycle de remplacement qui fera perdre à votre équipe un temps précieux dans le développement du produit. Ce n’est généralement pas le remplacement de la version du paquet en lui-même qui vous coûte le plus cher, mais tout le travail connexe : se conformer aux audits de dépendances, vérifier la compatibilité des API et exécuter des tests pour s’assurer de ne pas perturber les fonctions critiques de l’application en production.
Négociation : alors que le délai prévu par le SLA touche à sa fin, vous décidez de demander une dérogation. Cela vous laisse plus de temps pour trouver une solution, mais ne résout pas le problème sous-jacent. Le ticket a disparu de votre tableau de bord pour aujourd’hui, mais vous savez qu’il réapparaîtra. Pire encore, il sera signalé comme anomalie la prochaine fois qu’un auditeur ou l’équipe de sécurité d’un client consultera le journal des mesures correctives. Une seule fois, on peut probablement s’en sortir, mais lorsque les dérogations s’accumulent, cela peut s’avérer plus grave qu’un simple dépassement du délai prévu par le SLA.
Dépression : La dernière option consiste à intégrer vous-même le correctif de sécurité. Cette option constitue une véritable solution si vous pouvez consacrer le temps nécessaire à la compréhension du CVE, à l’isolation du correctif et à son intégration sélective dans la base de code existante. L’inconvénient est que vous devenez alors responsable de ce correctif et de tous les futurs correctifs concernant cette bibliothèque. Cela représente un engagement en termes de ressources qui risque de détourner votre équipe de sa mission principale.
La solution : bibliothèques « Aikido »
Si l'on poussait cette métaphore jusqu'au bout, la dernière étape serait l'acceptation. Soit on baisse les bras et on en subit les conséquences, soit on prend le risque de rompre. Ne l'acceptez pas. « Aikido Libraries » brise ce cercle vicieux.
Aikido Libraries fournit des versions corrigées de vos dépendances vulnérables. Le nom du paquet et l'API publique restent inchangés. La seule modification consiste en un suffixe indiquant la correction et une référence au registre de Aikido.
Chaque correctif part de la correction réalisée par le responsable du projet. Aikido reprend la modification de sécurité apportée en amont et l'applique à la version que vous utilisez. Des ajustements ne sont effectués que lorsque l'ancienne version d'exécution le nécessite. Chaque correctif est testé automatiquement, puis vérifié par une personne, et fourni sous forme de fichier diff que vous pouvez consulter dans son intégralité avant de le merge.
La transparence des correctifs est essentielle pour instaurer la confiance. Vous ne recevez pas le correctif propriétaire d'Aikido pour cette vulnérabilité, mais le correctif du responsable du projet, adapté à votre version, accompagné du diff complet, si vous souhaitez l'examiner.
Prenons un exemple concret. La version de la bibliothèque jsonwebtoken 8.5.1 dispose d'un CVE-2022-23529 classée comme « Élevée ». La version des bibliothèques de l’ Aikido devient jsonwebtoken 8.5.1-aikido.5 et intègre les correctifs de sécurité provenant de jsonwebtoken 9.0.0 sur 8.5.1. Les modifications consistent en des ajouts : de nouveaux fichiers de validation des clés, dont l'un contient une couche de compatibilité pour l'ancienne version d'exécution de Node. La mise à niveau vers 9.0.0 car cette même correction aurait nécessité une version majeure qui aurait supprimé la prise en charge des anciennes versions de Node et modifié la manière dont verify() gère les jetons non signés.
Le catalogue « Aikido Libraries » compte actuellement plus de 9 000 bibliothèques sécurisées couvrant les langages JavaScript, Python, Java, .NET, PHP, Go et Ruby. Nous publions également entre 50 et 100 nouveaux correctifs chaque jour. Pour les dépôts enregistrés, nous fournissons des bibliothèques sécurisées corrigées dans un délai de 48 heures pour les vulnérabilités connues ayant fait l'objet d'exploits, et dans un délai de 7 jours pour les CVE classées « Critiques » et « Élevées ».
Allume-le une fois
Aikido La fonctionnalité « Libraries » fonctionne de deux façons. Pour un paquet individuel, il s’agit d’une option du menu AutoFix existant : elle permet de corriger une vulnérabilité CVE sans mise à jour, une « PR » à la fois. Pour un dépôt, son activation verrouille vos dépendances et génère une « PR » AutoFix quotidienne pour les vulnérabilités CVE divulguées après son activation. Vous pouvez l’activer pour un seul dépôt important ou pour l’ensemble de votre base de code depuis l’interface utilisateur d’ Aikido .
Rien de tout cela ne vous oblige à conserver la version sécurisée. Effectuez la mise à jour dès que vous souhaitez bénéficier des nouvelles API ou fonctionnalités, tout en continuant à bénéficier des correctifs CVE qui l'accompagnent. La résolution des vulnérabilités CVE et le changement de version ne relèvent plus de la même décision.
Respectez systématiquement vos SLA
Pointez Aikido vers un dépôt et vous obtiendrez en quelques minutes votre premier PR compatible avec « merge » correspondant à un véritable CVE. Parcourez le catalogue pour voir quelles sont vos dépendances couvertes, ou protégez un dépôt pour obtenir votre premier correctif.
