Au-delà de l'automatisation : pourquoi la montée des vulnérabilités de sécurité liées à l'IA exige une expertise technique humaine

Les futurs historiens et historiennes se souviendront du printemps 2026 comme de l'avènement du signalement des vulnérabilités de sécurité basé sur l'IA. Le 7 avril 2026, Anthropic a annoncé une version préliminaire de son modèle d'IA Claude Mythos, mis à la disposition de certaines entreprises dans le cadre du Project Glasswing. Cette initiative affirmait avoir découvert des milliers de vulnérabilités de gravité élevée et critique dans l'écosystème Open Source. Trois semaines plus tard, l'initiative Xint a annoncé une vulnérabilité d'élévation locale de privilèges dans le noyau Linux, nommée Copy Fail. Quelques jours après, le monde a découvert une autre vulnérabilité nommée Dirty Frag, puis une autre nommée Fragnesia. Ainsi que de nombreuses autres.

Project Glasswing, Copy Fail et Dirty Frag partagent des problèmes de divulgation responsable. Le projet Project Glasswing n'a partagé que peu d'informations exploitables, malgré son lancement en grande pompe. Les chercheurs et chercheuses à l'origine de Copy Fail ont partagé leurs conclusions avec les développeurs et développeuses de kernel.org, mais pas avec les fournisseurs de systèmes. Une personne a divulgué prématurément des détails concernant Dirty Frag, ce qui a obligé le chercheur Hyunwoo Kim à divulguer les détails dans un fil de discussion public avant que quiconque ne puisse développer de correctifs.

Cet article de blog examine la réponse de Red Hat à Copy Fail et explique comment notre service de gestion de compte technique pour la sécurité des produits peut aider les organisations à gérer leur posture de sécurité dans cette nouvelle ère de divulgations rapides et incessantes générées par l'IA.

Historique et contexte de Red Hat Product Security

L'équipe Red Hat Product Security est un acteur majeur de la communauté de la sécurité informatique depuis 2001 et s’est constamment adapté à l’évolution des menaces. 

CVE.org gère le signalement des vulnérabilités logicielles dans tout le secteur informatique à l'aide d'un concept appelé Common Vulnerabilities and Exposures (CVE). Une CVE Numbering Authority (CNA) est une organisation membre qui publie des CVE. CVE.org compte plus de 500 membres CNA dans l'ensemble du secteur informatique. Une CNA-LR constitue une autorité de numérotation CVE de dernier recours. Les organisations membres s'appuient sur elles pour résoudre les litiges relatifs aux CVE. Les organisations Root enseignent aux autres CNA comment soumettre des CVE.

Aujourd'hui, Red Hat constitue la seule entreprise du secteur privé au monde à assumer le rôle de CNA-LR, et l'une des deux seules entreprises du secteur privé à détenir le rôle Root. Cela signifie que Red Hat occupe une position reconnue, responsable et digne de confiance dans tout le secteur. Nous nous trouvons souvent au centre du processus pour traduire un commit du noyau en une solution exploitable, tandis que le reste du monde se concentre sur les gros titres.

Avec la multiplication des signalements de vulnérabilités de sécurité pilotés par l'IA, le paysage des menaces ne se contente pas d'évoluer, il s'accélère. Mozilla a récemment collaboré avec Anthropic pour découvrir 22 bogues sensibles pour la sécurité dans son moteur JavaScript, suivis de 271 vulnérabilités supplémentaires lors d'un passage ultérieur sur l'ensemble du code source du navigateur. Dans l'écosystème logiciel global, à la mi-mai 2026, les outils de découverte pilotés par l'IA, menés en grande partie par Mythos, ont signalé plus de 10 000 problèmes potentiels, soit l'équivalent de près d'un an de découvertes traditionnelles en seulement deux semaines.

Red Hat se trouve au cœur de cette explosion. En 2025, l'équipe Red Hat Product Security a effectué le triage de 7 722 vulnérabilités de sécurité. Au cours des quatre premiers mois de 2026, du 1er janvier au 30 avril, ce nombre s'élevait à 2 826, ce qui porterait le total annuel à 8 596 si ce rythme se maintenait. Du 1er au 15 mai 2026, le nombre de vulnérabilités triées a atteint 712, ce qui représenterait plus de 17 000 pour l'année complète, soit plus du double par rapport à 2025.

Copy Fail : le premier d'une longue série

Chaque jour, CVE.org publie des centaines de rapports de vulnérabilités. Le 22 avril 2026, une CNA, kernel.org, a publié 100 vulnérabilités, numérotées de CVE-2026-31431 à CVE-2026-31530. 

CVE-2026-31431 propose cette description.

« Dans le noyau Linux, la vulnérabilité suivante a été résolue : crypto : algif_aead – Retour au fonctionnement hors-place (out-of-place). Cette action annule principalement le commit 72548b093ee3, à l'exception de la copie des données associées. » L'exécution sur place ne présente aucun avantage dans algif_aead car la source et la destination proviennent de mappages différents. Supprimez toute la complexité ajoutée pour l'opération sur place et copiez simplement l'AD directement. »

Rien de notable ne s'est produit jusqu'à une semaine plus tard, le 29 avril, lorsqu'un service nommé Xint.io de l'entreprise Theori a publié une preuve de concept nommée Copy Fail. Derrière cette description obscure se cachait un moyen pour tout utilisateur local non privilégié, que ce soit sur un système bare metal, dans une machine virtuelle (VM) ou à l'intérieur d'un conteneur, d'obtenir un accès root à un système.

Heureusement, cette attaque nécessite l'accès à la machine. Une personne malveillante doit d'abord se connecter. Malheureusement, Red Hat et d'autres distributions Linux ont découvert l'attaque le jour même où le public en a pris connaissance.

Les articles de presse et les fils de discussion en ligne se sont multipliés. La course était lancée.

L'équipe Red Hat Product Security a immédiatement mis à jour le niveau de risque de cette CVE en Important et a actualisé son bulletin de sécurité avec une stratégie d'atténuation et un calendrier de correction. Red Hat a publié le premier de ses nombreux avis de sécurité cinq jours plus tard, le 4 mai 2026. Plusieurs autres ont rapidement suivi.

Mais l'histoire ne s'arrête pas là.

Déploiement auprès de la clientèle

Le 12 mai à midi (heure d'été du Centre des États-Unis), Copy Fail avait généré 1 132 dossiers d'assistance de la part de clients utilisant Red Hat Enterprise Linux (RHEL), Red Hat OpenShift et Red Hat OpenStack. Plus tard en mai, ce nombre s'élevait à plus de 1 300 dossiers. Plusieurs de ces dossiers d'assistance comprenaient des questions détaillées ou des problèmes complexes impossibles à intégrer dans une simple FAQ. Par exemple :

• Certaines organisations dépendent d'applications dont le support est limité ou inexistant, qui ont tendance à présenter des défaillances lors des mises à niveau et des correctifs du système d'exploitation. À l'ère de la multiplication rapide des correctifs et des mises à niveau, ces applications représentent un risque encore plus élevé.
• Des questions reviennent systématiquement sur l'utilisation des scores CVSS (Common Vulnerability Scoring System) pour évaluer les risques. La réponse dépend du contexte. Les scores CVSS attribuent des niveaux de gravité de manière isolée. L'évaluation des risques dépend des caractéristiques spécifiques des entreprises et requiert un jugement humain.
• Comment suivre le flux ininterrompu de problèmes signalés par l'IA ? Le modèle consistant à « tout corriger » ne fonctionne plus. Au lieu de subir des interruptions constantes pour l'application de correctifs, concevez votre architecture informatique de façon à atténuer les vulnérabilités par une défense en profondeur. Utilisez le jugement humain pour identifier les vulnérabilités qui représentent réellement une menace pour votre environnement spécifique, puis corrigez-les.
• Au moins une organisation souhaitait savoir comment appliquer un correctif à OpenStack 17.1, qui dépend de RHEL 9.2. La solution consistait à utiliser le flux de version SAP de RHEL 9.2.
• Une autre organisation souhaitait connaître les conséquences de l'utilisation de noyaux plus récents et corrigés avec d'anciens systèmes RHEL 8. 
• Certaines organisations utilisaient d'anciennes versions d'OpenShift et nécessitaient une stratégie de correctifs.
• De nombreuses équipes ont eu besoin d'aide pour coordonner le déploiement des correctifs avec les services chargés des applications qui exigent une disponibilité totale.
• D'autres organisations se préoccupaient des performances.
• Plusieurs d'entre elles nécessitaient de l'aide pour analyser les risques liés à diverses initiatives de conformité.
• Dans de nombreux cas, les clients ont demandé des déclarations d'assurance officielles de Red Hat pour la direction.

Ces points ne constituent que quelques exemples. Les alertes de sécurité s'avèrent toujours stressantes. Nous avons constaté qu'il est utile de collaborer directement avec les entreprises pour les aider à distinguer la spéculation de la réalité, en particulier lorsque l'actualité s'enflamme pour le bogue Linux le plus alarmant de la décennie. 

La nécessité de faire appel à un partenaire commercial pour combler le fossé entre l'innovation communautaire et les protections de sécurité de niveau entreprise n'a jamais été aussi évidente.

Red Hat Technical Account Management Service for Product Security

Pour aider à gérer de telles situations de sécurité, Red Hat propose désormais le Red Hat Technical Account Management Service for Product SecurityPage affichée en Anglais (Français non disponible). Les Technical Account Managers (TAM) assurent le lien entre les clients et les groupes produit et ingénierie au sein de Red Hat et de la communauté Open Source. Alors que la plupart des TAM se concentrent sur un produit ou une technologie spécifique, les TAM sécurité de Red Hat se concentrent de manière globale sur l'empreinte sécuritaire de l'ensemble du portefeuille de produits Red Hat. Ces TAM aident à :

• Le partage d'informations pédagogiques ad hoc sur diverses tactiques d'attaque
• L'accompagnement des clients dans l'utilisation des outils de sécurité et de conformité Red Hat
• La suggestion de configurations et de déploiements renforcés, le cas échéant
• L'explication de la manière dont Red Hat aide à réduire les risques et à atténuer les vulnérabilités
• La fourniture d'analyses de vulnérabilités plus précises pour les produits Red Hat
• L'aide au tri des rapports d'analyse de vulnérabilités
• La facilitation de la communication avec les clients, les équipes Red Hat, les partenaires, les autres fournisseurs et la communauté Open Source, dans la mesure du possible
• L'influence sur la gestion des produits Red Hat, les équipes de sécurité des produits, les partenaires, les autres fournisseurs et la communauté Open Source en représentant les points de vue des clients
• Sensibilisation à la chaîne de valeur logicielle et aux attaques contre la chaîne d'approvisionnement
• Conseils sur les mesures d'atténuation potentielles face aux incidents de sécurité majeurs
• L'aide à l'élaboration d'évaluations post-mortem d'incidents de sécurité

Une communication continue s'avère toujours essentielle, en particulier en cas de crise, et d'autant plus que l'IA augmente la rapidité et la gravité des rapports de vulnérabilité de sécurité. Les TAM (Technical Account Managers) sécurité de Red Hat sont particulièrement bien placés pour aider les entreprises à distinguer la réalité du bruit médiatique et à répondre aux autres préoccupations. 

Sérénité

À l'ère des rapports de vulnérabilité basés sur l'IA, la plus grande menace ne réside pas seulement dans le volume de bogues, mais dans une dépendance excessive à l'égard de l'automatisation. L'IA peut détecter des vulnérabilités, mais elle ne peut pas fournir de stratégie de sécurité basée sur les risques ni garantir l'intégrité requise pour soutenir votre organisation en cas de crise. Le jugement humain constitue le seul élément sur lequel les équipes peuvent véritablement compter. Les défaillances dans les processus de divulgation responsable constituent une autre menace, car dès qu'une personne divulgue une nouvelle vulnérabilité avant que le personnel de développement ne puisse publier une mesure d'atténuation ou un correctif, elle permet aux attaquants de surprendre les clients.

Personne ne peut garantir une immunité totale contre les attaques, mais les TAM sécurité de Red Hat peuvent aider les équipes en assurant une coordination étroite avec l'équipe Red Hat Product Security et la communauté afin de fournir les conseils stratégiques et le soutien technique que l'IA ne peut offrir. 

La capacité à distinguer la réalité de l'emballement médiatique, ou à obtenir une alerte précoce quelques heures avant une attaque imminente, peut faire la différence entre l'application d'une mesure d'atténuation juste à temps et une catastrophe. N'attendez pas la prochaine divulgation majeure pour protéger votre infrastructure. Découvrez comment un TAM sécurité de Red Hat fournit la planification proactive et le soutien technique dont votre organisation a besoinPage affichée en Anglais (Français non disponible).

Contactez votre équipe de compte Red Hat pour en savoir plus, ou contactez Red Hat.
 

Trouvez ces chiffres en accédant à la base de données CVE de Red Hat lisible par l'humain, en sélectionnant une plage de dates appropriée et en consultant le décompte en bas de page.