Le délai d'un SLA sur une vulnérabilité de dépendance critique est sur le point d'expirer, mais votre sprint actuel ne vous laisse aucune marge pour effectuer les tests manuels indispensables afin d'éviter toute rupture en production. Manquer l'échéance de remédiation constitue en soi une non-conformité dans votre prochain rapport SOC 2 ou ISO 27001, tandis que le risque d'exploitation s'accroît avec l'évolution des modèles d'IA. Deux mauvaises options s'offrent alors à vous : 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 avez enfreint un SLA important.
Si ce scénario vous semble familier, vous n'êtes pas seul. Les organisations prennent de plus en plus de retard dans la course pour combler les vulnérabilités connues et respecter leurs SLA de sécurité. Une étude de Verizon, publiée en 2026, montre que l'exploitation de vulnérabilités est la cause numéro un des violations avérées, devançant pour la première fois les identifiants volés en près de 20 ans d'histoire du rapport.
La remédiation continue de marquer le pas en raison d'une explosion du nombre de vulnérabilités identifiées. D'après ce même rapport Verizon : seuls 26 % des vulnérabilités connues et exploitées (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 remédiation est passé à 43 jours, contre 32 l'année d'avant. Le rapport de Verizon attribue cette situation au fait que les organisations doivent corriger 50 % de vulnérabilités critiques supplémentaires.
Pourquoi cela continue-t-il de se produire ?
Il serait logique de penser qu'à mesure que l'importance des vulnérabilités grandit, davantage de ressources seraient allouées au problème et les correctifs suivraient le rythme. Pourtant, si vous travaillez dans ce domaine, vous savez que ce n'est pas du tout le cas. Ce problème s'aggrave au lieu de s'améliorer pour deux raisons principales :
- Une part considérable des dépendances ne bénéficie pratiquement d'aucune maintenance, mais se trouve enfouie si profondément dans les systèmes de production qu'il est impossible de les supprimer simplement ou de migrer facilement vers une version majeure plus récente. Pensez à...
log4j. - Les politiques de SLA et les programmes de conformité se fichent de savoir s'il existe un mainteneur actif.
Ce que font les équipes aujourd'hui : les étapes du deuil d'un SLA
Quand le temps est écoulé, la plupart des équipes d'ingénierie traversent une série prévisible de mauvaises options. Cela ressemble fortement au modèle classique du deuil de Kübler-Ross.
Déni : La plupart des équipes commencent par attendre un correctif en amont, mais rien ne garantit quand, ni même si, le mainteneur corrigera la vulnérabilité. Certains mainteneurs réagissent en quelques jours ou moins, tandis que d'autres ne le font pas. Ce problème est exacerbé pour les packages largement utilisés, mais effectivement non maintenus, sans véritable propriétaire. Attendre ne fait que consommer le délai de votre SLA, sans pour autant résoudre la vulnérabilité.
Colère : Supprimer et remplacer la dépendance problématique. Cela ressemble à une vraie correction, et c'est probablement le cas pour aujourd'hui. Mais lorsque la nouvelle version du package écopera d'une CVE le mois prochain, puis d'une autre le mois suivant, vous vous retrouverez piégé dans un cycle de remplacement qui coûte à votre équipe un temps précieux sur le développement du produit. Ce n'est généralement pas l'acte de remplacer la version du package en soi qui coûte cher, mais tout le travail connexe pour se conformer aux audits de dépendances, vérifier la compatibilité des API et exécuter des tests pour s'assurer de ne pas casser les fonctionnalités critiques de l'application en production.
Marchandage : À mesure que le délai du SLA s'approche, vous décidez de demander une dérogation. Cela vous donne plus de temps pour trouver une solution, mais ne résout pas le problème sous-jacent. Le ticket disparaît de votre tableau de bord pour aujourd'hui, mais vous savez qu'il finira par revenir. Pire encore, il resurgira sous forme de constat lors du prochain audit ou de l'examen du journal de remédiation par l'équipe de sécurité d'un client. On s'en sort sans doute la première fois, mais accumuler les dérogations peut s'avérer pire que de dépasser un seul délai de SLA.
Dépression : La dernière option consiste à rétroporter (backporter) vous-même le correctif de sécurité. C'est une véritable solution, à condition de pouvoir consacrer le temps nécessaire pour comprendre la CVE, isoler le correctif et l'intégrer (cherry-pick) dans la base de code existante. L'inconvénient est que vous devenez responsable de ce correctif et de tous les futurs correctifs de cette bibliothèque par la suite. C'est un engagement en ressources qui risque de détourner votre équipe de sa mission principale.
La solution : Aikido Libraries
Si l'on poussait la métaphore jusqu'au bout, la dernière étape serait l'acceptation : abandonner et subir l'impact sur la conformité, ou risquer une panne. Ne l'acceptez pas. Aikido Libraries brise ce cycle.
Aikido Libraries fournit des versions corrigées de vos dépendances vulnérables. Le nom du package et l'API publique restent inchangés. La seule modification est un suffixe marquant le correctif et un ancrage (pin) vers le registre d'Aikido.
Chaque correctif part de la correction du mainteneur lui-même. Aikido récupère le correctif de sécurité amont et l'applique à la version que vous utilisez. Des ajustements ne sont apportés que si le runtime plus ancien l'exige. Chacun d'eux est testé automatiquement, puis examiné par un humain, et publié sous forme de diff que vous pouvez lire intégralement avant de le merge.
La transparence des correctifs est essentielle pour la confiance. Vous n'obtenez pas le correctif propriétaire d'Aikido pour la vulnérabilité, mais bien celui du mainteneur adapté à votre version, avec le diff complet si vous souhaitez l'inspecter.
Prenons un exemple concret. La version de la bibliothèque jsonwebtoken 8.5.1 dispose d'un CVE-2022-23529 évaluée comme High devient avec Aikido Libraries jsonwebtoken 8.5.1-aikido.5 et rétroporte les correctifs de sécurité de jsonwebtoken 9.0.0 sur 8.5.1. Le changement consiste en des ajouts : de nouveaux fichiers de validation de clés, dont un contenant un correctif de compatibilité (shim) pour l'ancien runtime Node. Mettre à niveau vers 9.0.0 pour obtenir le même correctif aurait signifié une version majeure abandonnant la prise en charge des anciennes versions de Node et modifiant la manière dont verify() gère les jetons non signés.
Le catalogue Aikido Libraries propose actuellement plus de 9 000 bibliothèques sécurisées pour JavaScript, Python, Java, .NET, PHP, Go et Ruby. Nous déployons également entre 50 et 100 nouveaux correctifs chaque jour. Pour les dépôts enregistrés, nous livrons des bibliothèques sécurisées et corrigées dans les 48 heures pour les vulnérabilités activement exploitées et dans les 7 jours pour les CVE Critical et High.
Activez-le une seule fois
Aikido Libraries fonctionne de deux manières. Pour un package unique, il s'agit d'une option disponible dans le menu AutoFix : fermez une CVE sans effectuer de mise à niveau, une PR à la fois. Pour un dépôt, l'activation épingle vos dépendances et génère quotidiennement une PR AutoFix pour les CVE publié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 d'Aikido.
Rien de tout cela ne vous enferme dans la version sécurisée. Mettez à niveau quand vous le souhaitez pour bénéficier de la nouvelle API ou des fonctionnalités récentes, tout en conservant les correctifs de CVE inclus. Fermer la CVE et changer de version ne constituent plus la même décision.
Respectez vos SLA à chaque fois
Pointez Aikido vers un dépôt et il génère votre première PR prête pour le merge contre une vraie CVE en quelques minutes. Explorez le catalogue pour voir quelles dépendances sont couvertes, ou protégez un dépôt pour obtenir votre premier patch.
