Les agents IA découvrent des zero-days plus vite que les équipes de sécurité ne peuvent les gérer
Une startup de sécurité vient de signaler 21 vulnérabilités inconnues dans FFmpeg, l'une des bibliothèques médias les plus intégrées sur Internet.
Ce qui était dérangeant, ce n’était pas seulement le nombre de bugs.
C’était la manière dont ils ont été découverts.
Un agent de sécurité IA autonome a analysé environ 1,5 million de lignes de code C, produit des entrées de preuve de concept reproductibles, et a mis au jour des zero-days confirmés pour environ 1 000 dollars de calcul. La même semaine, Google a corrigé un record de 429 bugs de sécurité Chrome après avoir modifié son programme de primes pour gérer un afflux de rapports générés par IA.
Ce n’est pas une petite amélioration de productivité. C’est un nouveau rythme opérationnel pour la découverte de vulnérabilités.
Pour les RSSI, la question n’est plus de savoir si l’IA peut aider à trouver des problèmes de sécurité. Elle le peut clairement. La question plus difficile est de savoir si l’organisation dispose d’une gouvernance capable de suivre quand l’IA augmente le volume, la vitesse et l’ambiguïté des découvertes de sécurité.
Le goulot d’étranglement des zero-days évolue
Pendant des années, le goulot d’étranglement dans la gestion des vulnérabilités était la découverte.
Trouver un bug significatif nécessitait une expertise humaine rare, du temps et une connaissance approfondie d'une base de code. Cette contrainte a façonné la manière dont les équipes de sécurité considéraient le risque. Vous pouviez prioriser en fonction des CVE connus, des avis des fournisseurs, de l'activité d'exploitation et de l'exposition des actifs, car le flux de nouvelles découvertes était bruyant mais encore quelque peu limité.
L'IA change cette contrainte.
Si un agent autonome peut analyser rapidement un grand projet open source et produire des dizaines de découvertes plausibles, le facteur limitant passe de la découverte à la validation, la priorisation, la responsabilité, la divulgation et la remédiation.
Cela semble opérationnel. C’est en réalité de la gouvernance.
Qui est autorisé à mener des recherches autonomes de vulnérabilités sur le code interne ? Sur quels systèmes peuvent-ils les appliquer ? Que se passe-t-il lorsque l’agent trouve un bug dans une dépendance tierce, un workflow client ou un système réglementé ? Qui examine la preuve de concept avant qu’elle ne soit stockée, partagée ou escaladée ? Comment empêcher que du code sensible, des secrets ou des détails d’exploitation soient collés dans des outils d’IA non gérés durant le processus ?
La plupart des entreprises n’ont pas encore de réponses claires.
Les découvertes de sécurité générées par l’IA créent un problème de confiance
L’IA ne se contente pas de trouver des problèmes. Elle crée du travail.
Certaines découvertes seront réelles. D’autres seront des doublons. Certaines auront peu d’impact. D’autres seront subtilement erronées. Certaines incluront des artefacts de preuve de concept qui créent un risque en cas de mauvaise gestion. Certaines paraîtront urgentes car l’agent écrit avec assurance, même lorsque l’exploitabilité est incertaine.
Cela crée un nouveau problème de confiance au sein de l’équipe de sécurité.
Si chaque ingénieur, membre de l’équipe rouge, fournisseur et chercheur externe peut utiliser l’IA pour générer des rapports de sécurité à grande échelle, les opérations de sécurité ont besoin d’un moyen pour séparer le signal du bruit automatisé sans épuiser les personnes chargées de la revue.
C’est là que de nombreux programmes de gouvernance de l’IA restent trop limités. Ils se concentrent sur la question de savoir si les employés peuvent utiliser ChatGPT, Claude, Gemini ou Copilot. Cela compte, mais ce n’est pas suffisant.
Le problème majeur est que l’IA devient partie intégrante du workflow de sécurité lui-même. Elle exécute des tests, génère des rapports, écrit du code de preuve de concept, résume des vulnérabilités, suggère des correctifs et touche parfois du code source sensible ou du contexte de production.
Ce workflow nécessite de la visibilité.
L’IA fantôme inclut désormais des outils de sécurité fantômes
Les équipes de sécurité parlent souvent de l’IA fantôme comme d’un problème lié aux utilisateurs métier : les employés collent des données clients dans des outils non approuvés, les équipes marketing utilisent des applications IA, les analystes téléchargent des feuilles de calcul, etc.
Mais le même phénomène émerge au sein des équipes techniques.
Un développeur utilise un agent pour auditer un dépôt. Un analyste sécurité utilise un modèle pour résumer du code suspect. Un membre de l’équipe rouge demande à un outil IA de muter des charges utiles d’exploit. Un ingénieur télécharge des logs pour accélérer l’analyse des causes profondes. Un prestataire utilise son assistant IA préféré pour examiner un problème de dépendance.
Aucun de ces comportements n’est automatiquement malveillant. En fait, beaucoup sont utiles.
Mais s’ils se produisent en dehors des workflows approuvés, ils créent exactement le type de zone d’ombre que la gouvernance de l’IA est censée réduire.
Le risque n’est pas simplement une fuite de données. C’est une autorité non gérée :
- Outils IA recevant du code source, des identifiants, des logs ou des détails d’architecture
- Agents générant du matériel d’exploitation sans règles claires de gestion
- Découvertes entrant dans les files de tickets sans provenance ni score de confiance
- Équipes agissant sur des recommandations générées par IA sans revue
- Contexte sensible de remédiation stocké dans des comptes IA personnels
C’est pourquoi l’exemple FFmpeg est important au-delà de la sécurité open source. Il montre ce qui se passe lorsque la découverte de vulnérabilités devient bon marché et autonome. Le même phénomène apparaîtra dans les environnements d’entreprise, mais avec du code privé, des systèmes internes et des données réglementées associées.
Les politiques ne suivront pas la vitesse des agents
Une politique PDF disant « ne pas télécharger de données sensibles dans des outils IA » ne gérera pas ce problème.
Les équipes de sécurité ont besoin de contrôles qui opèrent là où le travail se fait.
Cela signifie savoir quels outils IA sont utilisés, quelles identités y accèdent, quels types de données y circulent et quels workflows impliquent du code, des logs, des tickets, des vulnérabilités ou du contexte client.
Cela signifie aussi créer des chemins balisés plutôt que des interdictions générales.
Si les employés estiment que les outils approuvés sont plus lents que l’assistant IA qu’ils utilisent déjà, ils contourneront la politique. La solution n’est pas de bloquer chaque expérimentation. C’est de fournir des moyens sûrs et surveillés d’utiliser l’IA pour le travail de sécurité, avec des limites claires sur les données, les actions, la conservation et la revue.
Pour les agents de sécurité autonomes spécifiquement, les entreprises devraient définir :
- Cibles approuvées : quels codebases, systèmes et environnements les agents peuvent tester
- Limites des données : quels codes sources, logs, secrets et données clients peuvent être partagés
- Revue humaine : qui valide les découvertes avant escalade ou remédiation
- Gestion des artefacts : comment sont stockés les codes de preuve de concept et les entrées d’exploitation
- Règles de divulgation : quand les découvertes impliquent des logiciels tiers ou open source
- Traçabilité : quel agent a été exécuté, sous quelle autorité, contre quel actif et avec quel résultat
Sans cette structure, le travail de sécurité alimenté par l’IA devient une autre forme d’IA fantôme.
La question du RSSI change
L’ancienne question était : « Nos équipes utilisent-elles des outils IA ? »
La meilleure question est : « Quels workflows pilotés par l’IA influencent désormais les décisions de sécurité, les modifications de code, la gestion des vulnérabilités ou les risques en production ? »
C’est à ce niveau que la gouvernance doit opérer.
Des agents IA trouvant 21 zero-days dans une bibliothèque majeure, c’est impressionnant. C’est aussi un avertissement. Le système de sécurité d’entreprise autour de l’IA doit mûrir aussi vite que les outils eux-mêmes.
Sinon, le prochain goulot d’étranglement ne sera pas la découverte de vulnérabilités.
Ce sera savoir quelles découvertes générées par l’IA méritent confiance, quels workflows IA ont touché des données sensibles et quels risques votre organisation a créés accidentellement en cherchant à aller plus vite.
Aona aide les équipes à combler cet écart en donnant aux responsables sécurité une visibilité sur l’usage réel de l’IA, la dérive entre politique et comportement, et les workflows où l’IA commence à toucher des données sensibles, du code et des décisions métier.
Si votre programme de gouvernance IA traite encore cela comme un problème d’accès aux outils, il est temps d’élargir la perspective.
