La correction des vulnérabilités désigne le processus consistant à corriger les failles de sécurité, qu’elles se trouvent dans le code écrit par votre équipe, dans les bibliothèques open source dont vous dépendez, dans les conteneurs que vous déployez ou dans les comptes « cloud » que vous utilisez. Les vulnérabilités sont désormais le moyen le plus courant utilisé par les attaquants pour s’introduire dans les systèmes. Le rapport 2026 de Verizon sur les enquêtes relatives aux violations de données a révélé que l’exploitation des vulnérabilités avait, pour la première fois, dépassé le vol d’identifiants en tant que principal vecteur d’accès initial, représentant 31 % des violations, contre 20 % l’année précédente.
La plupart des équipes ont déjà connaissance d’un nombre de vulnérabilités dans leur code supérieur à celui qu’elles sont en mesure de corriger. Ce même rapport a révélé que seules 26 % des vulnérabilités répertoriées dans le catalogue « Known Exploited Vuln » (KEV) de la CISA avaient été entièrement corrigées en 2025, et que le délai médian nécessaire à l’application d’un correctif s’élevait à 43 jours.
Ce guide présente étape par étape le processus de correction des vulnérabilités, explique comment hiérarchiser les corrections à effectuer en priorité et décrit comment corriger chaque type de vulnérabilité, tout en indiquant la marche à suivre lorsque la mise à jour d'une dépendance n'est pas possible. Si vous recherchez des outils permettant d'effectuer ce travail, consultez notre sélection d'outils de correction des vulnérabilités.
{{cta}}
Où se trouvent les failles ?
Votre propre code
Les vulnérabilités présentes dans le code écrit par votre équipe se répartissent en deux catégories, qui relèvent de deux segments distincts de la pile de sécurité. Les failles de type « pattern » sont celles que l’ SAST , de manière déterministe, détecte à chaque commit.
SAST Il s'agit d'un moteur déterministe, basé sur des règles, qui fonctionne par correspondance de motifs. Il est efficace pour détecter les failles présentant une structure reconnaissable, comme « si une entrée utilisateur est transmise à cette fonction sans passer par un filtre de validation, signaler une injection SQL ». Les failles logiques ne présentent pas une telle structure. Il n’existe aucun modèle pour un point de terminaison censé vérifier si l’utilisateur est propriétaire d’une ressource alors qu’il ne l’est pas; pour détecter ces failles, il faut donc raisonner sur ce que le code est censé faire. C’est le rôle de l’IA code review, qui lit le code en gardant cette intention à l’esprit, et de pentest IA, qui analyse l’application en cours d’exécution pour vérifier si une faille peut réellement être exploitée.
Ces deux types de correction de vulnérabilités nécessitent des modifications du code par la personne qui en est responsable. Les corrections basées sur des modèles suivent des procédures bien établies, comme la paramétrisation d’une requête ou l’encodage de la sortie. Les failles logiques dépendent de ce que le code était censé faire ; leur correction nécessite donc la même compréhension de l’application que celle requise pour les détecter. Lorsqu’un outil d’IA a déjà identifié comment une vérification d’autorisation manquante peut être exploitée, il peut proposer une correction fondée sur cette analyse, et le réviseur reçoit une explication accompagnant la modification.
Dépendances open source
La majeure partie du code d'une application moderne provient de bibliothèques open source, et la plupart d'entre elles sont des dépendances transitives intégrées par les bibliothèques que vous avez choisies. Ainsi, la plupart des vulnérabilités présentes ici se trouvent dans du code que personne au sein de votre équipe n'a écrit, ni même sélectionné.
analyse de la composition logicielle (SCA) lit vos fichiers de verrouillage pour construire l'arborescence complète des dépendances, puis compare la version de chaque paquet à une source de données sur les vulnérabilités. C'est cette source qui détermine ce qu'elle détecte. Les outils qui s'appuient uniquement sur les bases de données CVE publiques passent à côté des failles open source corrigées dans une version sans qu'un identifiant CVE ne leur ait jamais été attribué. C'est pourquoi certains outils d'SCA , dont celui de Aikido, s'appuient sur des fluxrenseignement sur les menaces tels que Aikido Intel.
Une vulnérabilité détectée ne vous permet pas de savoir si elle vous concerne. Un CVE présent dans une fonction que votre code n'appelle jamais n'est pas accessible et ne présente guère de risque réel, tandis que le même CVE dans une fonction que vous utilisez partout justifie de mettre d'autres tâches de côté. Un score CVSS ne permet pas de faire la distinction entre les deux, car il évalue la faille de manière abstraite, et non le degré d'exposition de votre application.
SCA Les vérifications doivent se poursuivre après l'exécution de la commande « merge ». Les versions des paquets indiquées dans votre fichier de verrouillage restent figées alors que de nouvelles vulnérabilités continuent d'être révélées à leur sujet ; ainsi, un arbre de dépendances qui avait passé les tests le mois dernier peut échouer aujourd'hui sans que personne n'y ait touché. Lorsqu'une faille est signalée, la solution standard consiste à passer à une version qui la corrige, et la section suivante explique pourquoi cette mise à jour se révèle souvent plus complexe qu'il n'y paraît.
Images de conteneurs
La plupart des vulnérabilités présentes dans une image de conteneur proviennent de l’image de base sur laquelle elle est construite. Une image de base type intègre des dizaines de bibliothèques et d’outils système, tels qu’un shell et un gestionnaire de paquets, et c’est l’ analyse d’images de conteneurs qui vérifie ces paquets au niveau du système d’exploitation. Les images évoluent également d’une manière qui passe facilement inaperçue. Un conteneur en cours d’exécution conserve les paquets avec lesquels il a été construit jusqu’à ce que quelqu’un le reconstruise et le redéploie ; ainsi, un conteneur fonctionnant en production peut ne pas bénéficier pendant des mois d’un correctif disponible en amont.
La correction d'une image dépend de l'ampleur des modifications que vous êtes prêt à apporter à cette base. La suppression des paquets que votre environnement d'exécution n'utilise jamais permet de réduire l'ampleur du problème. Pour tout ce qui reste, la mise à niveau vers une version de base plus récente ou la migration vers une distribution sécurisée d'un autre fournisseur impliquent toutes deux de tester votre application sur une base différente, tandis qu'une version corrigée de la même version de base comble les failles CVE tout en conservant le reste tel quel.
Infrastructure as Code (IaC)
L'IaC ( cloud ) permet de centraliser la configuration de l'cloud dans des fichiers tels que les modèles Terraform et CloudFormation, les charts Helm et les manifestes Kubernetes, ce qui permet de réviser la majeure partie de votre configuration d' comme n'importe quel autre code. Parmi les vulnérabilités courantes, on peut citer :
- Un compartiment de stockage accessible depuis Internet
- Un groupe de sécurité qui accepte le trafic provenant de n'importe où
- Un conteneur s'exécutant en tant que root
- Une instance EC2 utilisant encore IMDSv1, l'ancienne version du service de métadonnées d'AWS sur laquelle s'appuient les attaques SSRF pour voler des identifiants
L'IaC est le moyen le plus simple de corriger une erreur de configuration d'cloud , car rien n'a encore été déployé. Les vérifications IaC s'exécutent dans votre pipeline CI/CD et signalent ces erreurs dans la pull request ; la correction consiste en un modèle modifié, souvent une modification d'une seule ligne, qui n'atteint jamais l'environnement de production. Le hic, c'est que les vérifications IaC ne voient que ce qui est écrit dans vos modèles.
Cloud configuration
Dans une organisation d'ingénierie bien rodée, la majeure partie de l'infrastructure d'cloud s est définie via l' en tant que code (IaC) ; ainsi, bon nombre des résultats d'cloud sont en réalité des résultats issus de l'IaC qui ont été mis en œuvre. Le reste provient de modifications que personne n'a consignées par écrit. Quelqu'un clique dans la console pour ouvrir un port ou élargir un rôle, sans qu'aucun modèle ni aucune pull request n'en garde trace.
Cloud La gestion de la posture de sécurité (CSPM) interroge directement le compte en production ; elle détecte ainsi ces modifications, ainsi que tout élément qui aurait échappé à la révision. La correction consiste en une modification de la configuration ou un renforcement de la politique, et doit être réintégrée dans l’IaC. Si la ressource est déjà gérée par un modèle, une correction effectuée uniquement via la console sera annulée lors du prochain déploiement. Si elle a été créée manuellement, son intégration dans l’IaC garantit que toute modification ultérieure fera l’objet d’une révision.
Certaines des vulnérabilités les plus graves touchent plusieurs couches, comme le montre la faille SSRF de MLflow (CVE-2026-64849). Quelques heures seulement après l’attribution d’un identifiant CVE en août 2026, des pirates l’exploitaient déjà pour amener les serveurs MLflow à demander leurs propres identifiants au service de métadonnées du fournisseur d’ cloud . Sur AWS, IMDSv1 les transmet en réponse à une simple requête. IMDSv2 exige au préalable un jeton de session, une étape supplémentaire que la plupart des failles SSRF ne peuvent pas franchir ; sa mise en œuvre aurait donc probablement empêché ce vol.
Quels que soient les identifiants dont les attaquants ont pu se procurer, leur portée était limitée à celle du rôle IAM associé au serveur ; or, comme ces rôles sont généralement définis dans Terraform ou CloudFormation, les contrôles IaC permettent de détecter une politique trop large avant même son déploiement. Ces deux mesures de sécurité figurent dans les mêmes modèles que ceux déjà analysés par les contrôles IaC, ce qui fait de l'IaC le moyen le plus économique de contrer une attaque de ce type.
Détection de secrets
Les secrets se retrouvent souvent dans le code par accident. Une clé API peut être codée en dur dans un test, ou un mot de passe de base de données peut se glisser dans un fichier de configuration qui est ensuite validé avec le reste du code. Le code généré par l’IA est particulièrement sujet à ce problème. détection de secrets vérifie les nouvelles validations et l’historique Git complet à la recherche de ces éléments, et un hook « pre-commit » peut bloquer une validation avant même qu’elle ne soit effectuée. Les images de conteneurs nécessitent la même vérification, car un secret copié dans une couche reste dans l’image même si une couche ultérieure le supprime.
Supprimer le secret du code ne résout pas le problème, car il figure toujours dans l'historique Git. La solution consiste à renouveler l'identifiant, puis à vérifier les journaux d'accès pour voir si quelqu'un a utilisé l'ancien identifiant avant son renouvellement. Si les journaux indiquent qu'une autre personne l'a utilisé, vous devez déterminer à quoi l'attaquant a eu accès et si les données concernées déclenchent des obligations de notification en cas de violation. Une fois que l'ancien identifiant n'est plus valide, le supprimer de l'historique relève d'une bonne pratique d'administration, mais n'est plus urgent. Pour éviter que cela ne se reproduise, transférez le secret dans un gestionnaire de secrets ou dans une variable d’environnement que le code lit lors de l’exécution.
Lorsqu'il n'est pas possible de mettre à jour une dépendance
La plupart des outils d’ SCA s et des avis de sécurité donnent le même conseil lorsqu’un paquet est vulnérable : passer à la version corrigée. Pour une simple mise à jour de niveau de correctif, cela suffit généralement. Les problèmes commencent lorsque le correctif n’est pas mis à disposition aussi simplement, ce qui est souvent le cas dans la pratique.
Les problèmes commencent lorsque le correctif n’existe que dans une nouvelle version majeure comportant des changements d’API incompatibles, ou lorsque le paquet vulnérable est transitif et que votre mise à jour dépend d’un responsable situé trois niveaux plus haut dans l’arborescence. Les paquets abandonnés et les versions en fin de vie ne bénéficient jamais d’une version corrigée, et c’est en effectuant des mises à jour par réflexe que les versions piratées de « chalk » et « debug » ont pu s’introduire dans les pipelines en quelques minutes. Les équipes reportent donc la mise à jour, et le CVE est ajouté à une liste d’ignorés qui ne cesse de s’allonger.
La vulnérabilité CVE-2026-48937 dans Node.js illustre bien ce phénomène. Le correctif a été fourni dans le cadre d’une mise à jour majeure (selon la convention SemVer) de nghttp2, qui a supprimé complètement la signalisation de priorité HTTP/2, car le comportement vulnérable et la fonctionnalité supprimée provenaient du même code sous-jacent. Pour une équipe exploitant un service HTTP/2, une simple mise à jour de version d’une ligne s’est transformée en une chasse à tous les appels à setPriority et .priority(), tant dans son propre code que dans toute dépendance s’appuyant sur les mêmes API, tandis que le CVE restait ouvert.
Le « backporting » est la solution la plus directe : il s'agit d'appliquer le correctif à la version que vous utilisez déjà. Vous pouvez créer une branche dérivée du paquet et le faire vous-même, mais vous deviendrez alors propriétaire de cette branche, ou utiliser une version corrigée fournie par un fournisseur qui gère les backports, comme le propose Aikido Security pour les paquets open source et les images de conteneurs. Vous pouvez alors clôturer le CVE et effectuer la mise à jour lorsque votre équipe aura le temps de la tester correctement.
Meilleures pratiques en matière de correction des vulnérabilités
Définir les SLA en fonction du risque
Une fois que vous avez classé les résultats en fonction de leur exploitabilité et de leur exposition, attribuez à chaque niveau de risque un délai que votre équipe est en mesure de respecter. Un accord de niveau de service (SLA), exprimé en jours pour une vulnérabilité répertoriée dans la liste KEV sur un service accessible depuis Internet, et en semaines pour un vecteur d’attaque accessible dans un outil interne, permet d’organiser la file d’attente. Suivez également les manquements par rapport à ces SLA, car une tendance récurrente de manquements au sein d’une équipe ou d’une couche indique généralement un problème de processus qu’il convient de résoudre.
Intégrez les corrections là où les développeurs travaillent déjà
Une anomalie signalée dans un tableau de bord de sécurité se retrouve en concurrence avec toutes les autres tâches qui accaparent un développeur, et c'est généralement elle qui passe à la trappe. Le fait de la faire apparaître dans l’IDE pendant l’écriture du code, ou dans la pull request avant sa fusion, permet au développeur de la voir alors que la modification est encore fraîche dans son esprit. C’est à ce moment-là qu’il dispose du plus de contexte sur le fonctionnement prévu du code, et que la correction coûte le moins cher, avant la mise en production. Cela règle également la question de la responsabilité, car la personne qui a ouvert la pull request est naturellement celle qui doit la corriger.
Automatiser les corrections qui ne modifient pas le comportement
Les correctifs rétroportés et les mises à niveau de version qui passent vos tests peuvent être merge après une révision sommaire, car ils corrigent une vulnérabilité CVE sans modifier le comportement de votre code. Les corrections de failles logiques, comme une faille IDOR ou un contrôle d’autorisation manquant, modifient en revanche le comportement ; elles sont donc particulièrement utiles lorsqu’elles s’accompagnent d’une justification expliquant comment la faille pourrait être exploitée et ce que la correction met en place, ce qui accélère la révision. C’est lors des mises à niveau impliquant un changement de version majeure que l’automatisation est la moins utile ; la section ci-dessus consacrée aux « pièges de mise à niveau » présente de meilleures options pour ces cas-là.
Effectuer un nouveau test avant la fermeture
Relancez l'outil qui a détecté la vulnérabilité sur la version corrigée, et ne clôturez le rapport que lorsqu'elle n'apparaît plus. Pour les rapports concernant une application en cours d'exécution, cela implique de refaire des tests dans l'environnement de production, car un correctif qui fonctionne dans une branche peut tout de même échouer derrière un proxy mal configuré ou une ancienne version qui n'a jamais été redéployée.
Comment le service de sécurité d'Aikido . gère la correction des vulnérabilités
Aikido La sécurité couvre le processus de correction, depuis les premiers signes d'une vulnérabilité jusqu'à la pull request qui la corrige. Elle s'appuie sur «Aikido Intel », qui recense les vulnérabilités dans les paquets open source avant même qu'un identifiant CVE ne leur soit attribué, y compris de nombreuses vulnérabilités qui n'en recevront jamais ; cela permet ainsi d'entamer la correction avant même que les bases de données publiques ne les répertorient.
Chaque résultat passe ensuite par deux étapes de tri. analyse d’accessibilité vérifie si votre code comporte un chemin d'exécution menant à la fonction vulnérable, ce qui permet d'éliminer les CVE présents dans les paquets que vous importez mais que vous n'utilisez jamais. Les résultats restants sont transmis à CVE analyse de l’exploitabilité, un agent qui analyse la manière dont votre code utilise réellement le paquet, puis traite chaque résultat : il augmente le niveau de gravité lorsqu’un CVE s’avère plus dangereux dans votre configuration que ne le suggère son score de base, le diminue lorsque c’est le cas contraire, met les résultats en attente pour les réexaminer ultérieurement, ou ignore ceux qui ne sont absolument pas exploitables. Ensemble, ces deux outils réduisent le bruit de fond jusqu’à 95 %.
Les correctifs sont fournis sous forme de pull requests AutoFix. Pour les problèmes liés au code et à l’infrastructure en tant que code (IaC), AutoFix rédige lui-même la modification. Pour les dépendances et les conteneurs, le correctif prend la forme d’un backport. Aikido Libraries génère des versions corrigées des paquets que vous utilisez déjà via npm, PyPI, Maven et Go, ce qui permet de résoudre le CVE sans augmentation de version ni modification de l’API, même lorsqu’aucune version corrigée n’existe en amont. Aikido Images fait de même au niveau des conteneurs, avec plus de 2 000 images de remplacement prêtes à l’emploi qui corrigent les CVE de niveau élevé et critique selon un SLA défini, sur la version du système d’exploitation et la distribution que vous utilisez déjà.
Ces deux outils génèrent quotidiennement des pull requests AutoFix dans le workflow que votre équipe utilise déjà. Une pull request doit encore être testée et déployée avant que la vulnérabilité ne soit réellement éliminée, et c’est cette étape qu’AutoShip prend en charge. Ajoutez une étiquette à une pull request AutoFix et AutoShip la fait passer de l’environnement CI à l’environnement de préproduction, puis à la production, en effectuant des tests de fumée et en surveillant les régressions tout au long du processus, afin que le correctif parvienne en production sans que les développeurs aient à s’interrompre dans leur travail.
Aikido fournit également gratuitement à la communauté open source des correctifs rétroportés pour les vulnérabilités répertoriées par le KEV, de sorte que les failles activement exploitées par les pirates soient corrigées pour tous, qu'il s'agisse de clients ou non. Et comme chaque correctif passe par la même plateforme, chacun d'entre eux est enregistré comme preuve de conformité aux normes SOC 2 et aux normes ISO prises en charge par l'Aikido , notamment les normes ISO 27001 et ISO 42001.
{{walkthrough}}
