Vulnérabilités zero-day découvertes par l'IA : préparez vos pipelines

Le modèle Mythos Preview d'Anthropic a récemment identifié des milliers de vulnérabilités zero-day dans tous les principaux systèmes d'exploitation et navigateurs web, y compris un bogue OpenBSD qui n'a pas été détecté pendant 27 ans. Lors des tests, Mythos a enchaîné de manière autonome quatre vulnérabilités pour créer un exploit de navigateur fonctionnel capable de s'échapper de son environnement sandbox. Anthropic a restreint l'accès à Mythos, mais le responsable de la recherche offensive en cybersécurité de l'entreprise estime que les acteurs malveillants disposeront d'outils comparables d'ici six à douze mois.

Les organisations attaquées ne suivent pas le rythme. Un tiers des vulnérabilités et expositions communes (CVE) exploitées au premier semestre 2025 étaient actives dès le jour du signalement, voire avant, c'est-à-dire avant même que la plupart des équipes ne sachent qu'il y a quelque chose à corriger. L'IA comprime encore davantage cette fenêtre : elle accélère les attaques et inonde les équipes de signalements de chercheurs en sécurité plus vite qu'elles ne peuvent les traiter. Les outils de défense se sont améliorés, mais la majorité des organisations ne parviennent pas à les opérationnaliser assez rapidement pour combler l'écart entre la découverte et l'exploitation.

Lorsque la fenêtre entre le signalement et l'exploitation se mesure en heures, l'équipe de sécurité ne peut pas être le dernier rempart. La sécurité doit intervenir là où le code entre dans le système : dans le pipeline, sur chaque merge request, appliquée par des politiques. Les corrections qui peuvent être automatisées doivent l'être. Celles qui ne le sont pas doivent parvenir au bon interlocuteur plus vite qu'aujourd'hui.

Les vulnérabilités connues dépassent déjà la capacité de correction

Le goulot d'étranglement n'est pas la détection : c'est la capacité à agir à grande échelle sur ce que les équipes savent déjà. Soixante pour cent des atteintes à la sécurité recensées dans le rapport DBIR 2025 de Verizon impliquaient l'exploitation de vulnérabilités connues pour lesquelles un correctif était déjà disponible. Les équipes n'avaient tout simplement pas pu les corriger à temps.

Le backlog était déjà intenable avant Mythos. Les équipes de développement consacrent 11 heures par mois à la correction de vulnérabilités en post-release au lieu de livrer de nouvelles fonctionnalités. Plus de la moitié des organisations présentent au moins une vulnérabilité exposée sur Internet, et le délai médian pour en corriger la moitié est de 361 jours. L'exploitation prend des heures ; la correction prend des mois.

Le développement assisté par l'IA creuse encore l'écart, et les parties prenantes en sont conscientes. En juin 2025, le code généré par l'IA ajoutait plus de 10 000 nouvelles alertes de sécurité par mois dans les dépôts des entreprises Fortune 50, soit une multiplication par dix en six mois. Georgia Tech a identifié 34 CVE attribuables au code généré par l'IA en mars 2026, contre 6 en janvier, et ce chiffre ne reflète que les cas où l'origine de l'IA est clairement identifiable. Les assistants de codage IA hallucinent et inventent des noms de paquets, recourent à des modèles obsolètes et reproduisent des exemples non sécurisés issus de leurs données d'entraînement. Le code, les dépendances et les vulnérabilités par ligne sont générés plus vite que les équipes de sécurité ne peuvent les examiner.

Les organisations attaquées doivent elles aussi exploiter les modèles d'IA de pointe : non pas ajoutés au cycle de développement logiciel en tant qu'outils externes, mais exécutés au sein des mêmes politiques, approbations et pistes d'audit que le reste de l'équipe.

La sécurité au rythme du développement assisté par l'IA

Lorsqu'une CVE critique est publiée, en combien de temps votre équipe peut-elle confirmer les projets concernés ? Combien d'outils une alerte doit-elle traverser avant qu'un développeur puisse soumettre un correctif ?

Les équipes qui tirent le meilleur parti de l'IA disposent déjà de politiques, de mécanismes d'application et de contrôles intégrés à leurs workflows de développement. L'IA amplifie cette base. Elle ne la remplace pas.

Application au point de changement. À mesure que les fenêtres d'exploitation se réduisent, chaque ligne de code entrant dans un dépôt doit passer par un ensemble défini de contrôles. Fini les examens séparés dans un outil distinct par une équipe différente. Les organisations doivent pouvoir appliquer des politiques de sécurité à l'ensemble des groupes et des projets, avec la merge request comme point d'application. Résultat : des politiques définies une seule fois, appliquées partout, avec des exceptions examinées, approuvées et consignées.

Problèmes simples détectés avant la merge request, et non pendant. Les secrets codés en dur, les importations comportant des vulnérabilités connues et les appels à des API obsolètes peuvent être signalés dans l'IDE avant même qu'un développeur n'effectue un commit. Cette détection lors de la rédaction du code réduit le nombre d'alertes bloquant la merge request, de sorte que les cycles de revue se concentrent sur les problèmes qui nécessitent un contexte inter-composants : atteignabilité, exploitabilité et risque architectural.

Classement automatisé par défaut, et non par exception. Intégrer la sécurité dans chaque merge request crée un problème de volume : davantage de scans, davantage d'alertes, davantage de faux positifs parvenant à des équipes de développement qui ne sont pas formées pour distinguer une vulnérabilité critique accessible d'une vulnérabilité théorique. L'IA doit traiter la détection des faux positifs, l'atteignabilité, le contexte d'exploitabilité et l'évaluation de la gravité avant qu'un développeur ne voie le signalement, afin que les alertes qu'il reçoit méritent réellement son attention.

Correction gouvernée comme tout autre changement. La correction assistée par l'IA comprime les délais de résolution des vulnérabilités, mais chaque correctif généré doit suivre le même processus de gouvernance qu'un changement créé par un humain : les politiques appliquent les scans, les réviseurs appropriés les approuvent, et les preuves sont enregistrées. La fonctionnalité de correction automatisée de GitLab propose chaque correctif dans une merge request accompagnée d'un score de confiance. La merge request consigne la politique appliquée, les scans exécutés, leurs résultats et l'approbateur. Le code humain et le code généré par l'IA suivent le même processus, avec la même piste d'audit.

À quoi ressemble un pipeline opérationnel

Voici comment ces éléments fonctionnent ensemble lorsqu'une vulnérabilité de gravité élevée est découverte et que le compte à rebours est lancé.

Un exploit de type étude de faisabilité pour une vulnérabilité dans un paquet open source populaire apparaît sur une liste de diffusion de sécurité. Il n'y a ni CVE, ni entrée dans la National Vulnerability Database (NVD), ni signature de scanner. L'équipe de sécurité découvre la vulnérabilité sur Slack, comme c'est souvent le cas.

Un ingénieur en sécurité interroge l'agent de sécurité pour savoir si le paquet est utilisé, quels projets comportent des versions concernées et si des chemins d'appel vulnérables sont accessibles en production. L'agent vérifie le graphe de dépendances de chaque projet, identifie les versions et les points d'entrée concernés et renvoie une liste hiérarchisée des projets exposés avec des détails sur l'atteignabilité. Inutile d'inspecter manuellement les dépôts ou d'attendre une mise à jour du scanner. En quelques minutes, l'organisation sait si elle est exposée.

L'ingénieur lance une série de corrections pour chaque projet exposé. L'agent de correction suggère des correctifs : des mises à jour de version lorsqu'une release corrigée est disponible, et des correctifs ciblés sur les chemins d'appel lorsque ce n'est pas le cas. Les politiques d'exécution des scans sont déjà en place pour les projets avec le label SOC 2. L'ingénieur durcit les règles pour bloquer les merges sur toute merge request qui introduit ou conserve la dépendance concernée, et une politique d'approbation exige désormais la validation de l'équipe de sécurité sur chaque correctif. Le premier correctif proposé par l'agent échoue dans le pipeline lorsqu'un test d'intégration détecte une régression. L'agent ajuste le correctif en fonction de l'échec du test, et la deuxième tentative réussit. Les équipes de développement examinent les modifications, l'équipe de sécurité les valide conformément à la politique renforcée, et les merges se poursuivent.

Lors de la prochaine revue d'audit, l'équipe de sécurité présente un rapport qui explique comment les politiques ont été appliquées et les risques ont été réduits pendant la série de corrections. Ce rapport inclut les résultats des scans, les politiques appliquées, les approbateurs et les horodatages de merge pour chaque merge request de chaque projet concerné. Les preuves ont été générées automatiquement en temps réel, et non reconstituées après coup.

Combler les lacunes dès maintenant

Mythos existe aujourd'hui, et des modèles comparables seront entre les mains des attaquants d'ici un an. Chaque mois d'ici là est une occasion de renforcer votre chaîne d'approvisionnement logicielle.

Posez-vous les questions suivantes à propos de vos pipelines :

• Comment garantissez-vous que les scans de sécurité s'exécutent sur chaque merge request, et pas uniquement dans les projets où les équipes les ont configurés ?
• Si un paquet compromis entrait dans votre arbre de dépendances aujourd'hui, votre pipeline le détecterait-il avant le build ?
• Lorsqu'un scanner signale une alerte critique, combien de frontières entre les outils doit-elle franchir avant qu'un développeur ne commence la correction ?
• Si un agent d'IA proposait un correctif de code pour une vulnérabilité, quel processus ce correctif suivrait-il avant d'atteindre la production, et ce processus est-il auditable ?
• Lorsque les auditeurs demandent la preuve qu'une politique spécifique a été appliquée à un changement spécifique, combien de temps faut-il pour la présenter ?

Si vos réponses à ces questions révèlent des lacunes, corrigez-les dès maintenant. Échangez avec un architecte de solutions GitLab sur le rôle de la gouvernance de la sécurité dans votre cycle de développement.