L’IA trouve les vulnérabilités critiques plus vite que Teams ne peut les corriger

Au cours des 90 derniers jours, nous avons exécuté des pentests autonomes sur divers systèmes de production — et les résultats sont difficiles à ignorer.
Les applications modernes ne sont pas seulement vulnérables. Elles sont continuellement vulnérables.
Le problème ne vient pas du fait que les équipes ne testent pas la sécurité. C’est que les attaquants opèrent désormais à la vitesse des machines, tandis que les tests et les corrections suivent encore un rythme humain.
À mesure que l’IA accélère la découverte des vulnérabilités, le délai entre l’introduction d’un bug et son exploitation se réduit. Si les tests et les correctifs n’avancent pas au même rythme, cet écart devient la surface d’attaque.

Ce que nous observons sur le terrain

Sur 28 entreprises, nos agents ont identifié :

• ~2000 vulnérabilités au total

• 44,6 % critiques ou de gravité élevée (829 résultats)

• 21,6 vulnérabilités par analyse en moyenne (médiane : 15)

• 65,1 % des analyses ont révélé au moins un problème critique

• Pic : 88 vulnérabilités lors d’une seule analyse

Ce ne sont pas des risques théoriques. Chaque résultat est validé par un exploit de preuve de concept fonctionnel.
Près de la moitié des vulnérabilités que nous avons trouvées sont sérieuses, et la plupart des systèmes présentent au moins un problème critique.
Ce qui est encore plus préoccupant, c’est le type de vulnérabilités derrière ces chiffres. Il ne s’agit pas de simples erreurs de configuration ou de dépendances obsolètes. Ce sont des problèmes plus profonds dans la manière dont les applications sont conçues et se comportent.

Ce ne sont pas de simples bugs

Les problèmes les plus courants que nous observons sont des failles de logique.
Une faille de logique signifie que le système se comporte exactement comme il est codé, mais que la conception elle-même est insecure.
Il ne s’agit pas d’erreurs de configuration ou de bibliothèques obsolètes. Ce sont des bugs dans la manière dont l’application fonctionne réellement, dont les données circulent, dont les permissions sont appliquées et dont les systèmes se font confiance.

Voilà à quoi cela ressemble en pratique :

• IDOR (Insecure Direct Object Reference) — 177 résultats
  Les attaquants peuvent accéder aux données d’autres utilisateurs ou les modifier simplement en changeant des identifiants (par ex. des ID utilisateur, des ID de fichier). Cela peut exposer des données sensibles à grande échelle, voire permettre la prise de contrôle d’un compte.

• SSRF (Server-Side Request Forgery) — 122 résultats
  Les attaquants peuvent tromper le serveur et lui faire envoyer des requêtes en leur nom, souvent vers des systèmes internes. Cela peut exposer des API internes, des identifiants cloud ou des infrastructures qui ne devraient jamais être accessibles au public.

• Absence d’authentification — 105 résultats
  Des endpoints ou actions sensibles sont accessibles sans connexion. Cela signifie que n’importe qui sur Internet peut déclencher des fonctionnalités critiques ou accéder à des données protégées.

Ces vulnérabilités sont particulièrement dangereuses car elles exploitent le comportement de l’application, pas seulement sa configuration.
Les scanners traditionnels peinent ici, car ils ne comprennent pas le comportement. Ils cherchent des signatures, pas la logique.

Pourquoi l’IA en trouve davantage

Jusqu’à récemment, trouver et exploiter ce type de vulnérabilités demandait du temps, des compétences et un travail manuel.
Cela a changé.

Les agents d’IA peuvent désormais interagir avec les applications comme le ferait un attaquant humain, mais à une échelle et une vitesse totalement différentes.
Ils ne se contentent pas de scanner les endpoints, ils les explorent.

• Ils testent les cas limites

• Enchaînent plusieurs étapes

• Itèrent rapidement sur des milliers de possibilités

Au lieu de vérifier des problèmes connus, ils sondent activement le comportement d’une application et cherchent des moyens de la faire échouer. Ils ne dorment jamais. Leur journée de travail ne se termine jamais. Ils ont la base de connaissances du monde entier en mémoire.
Ce changement est ce qui alimente les résultats que nous observons : une découverte régulière de problèmes critiques dans la majorité des analyses.

Pourquoi l’open source peut accélérer la découverte des vulnérabilités

L’open source change la manière dont les vulnérabilités sont découvertes.
Imaginez que vous essayez d’ouvrir une serrure. Quand vous connaissez son fonctionnement interne, il est beaucoup plus facile de la crocheter.
Quand les systèmes d’IA ont accès au code source, ils peuvent analyser directement chaque chemin de code au lieu de déduire le comportement de l’extérieur.
Dans des tests de benchmark contrôlés utilisant la XBow validation suite disponible publiquement, l’accès au code source a augmenté la détection des vulnérabilités d’environ 20 % par rapport aux tests en boîte noire.
Nous observons aussi cet écart dans des scénarios réels.
Avec une visibilité complète, les agents d’IA peuvent :

• Suivre les flux de données de bout en bout

• Identifier les hypothèses défaillantes dans la logique métier

• Explorer les cas limites beaucoup plus efficacement

Cela rend les failles de logique nettement plus faciles à trouver et à exploiter.
À mesure que davantage d’applications sont construites à ciel ouvert et que les systèmes d’IA s’améliorent, la vitesse de découverte des vulnérabilités continue d’augmenter.
Cela dit, le fait d’être en code fermé ne vous met pas à l’abri par défaut.
La sécurité par l’obscurité n’a jamais été une vraie défense. Un attaquant déterminé disposant d’assez de puissance de calcul et d’assez de tokens à brûler peut toujours énumérer, fuzzifier et, à terme, découvrir des chemins exploitables, même sans accès direct au code.
La conclusion n’est donc pas de choisir entre open source et code fermé. Il s’agit d’adapter la manière dont vous testez et sécurisez les systèmes.
Quelle que soit l’architecture, les évaluations ponctuelles traditionnelles passent à côté de l’essentiel. Les bases de code évoluent à la vitesse des machines, et les surfaces d’attaque aussi.

Le vrai problème : plus de vitesse = moins de coût

Il y a quelques années, trouver et exploiter des vulnérabilités demandait du temps, des compétences et de la patience.
Aujourd’hui, ce délai s’est effondré.
Les systèmes d’IA peuvent :

• Lancer des milliers de tests en parallèle

• Explorer en continu de nouveaux chemins de code

• Enchaîner automatiquement des exploits

Cela signifie que les vulnérabilités sont découvertes plus vite que jamais, souvent quelques heures ou quelques jours après leur introduction.
Mais la plupart des organisations ne se sont pas adaptées à ce changement.
Les tests de sécurité sont encore traités comme un événement périodique :

• Une fois par an

• Peut-être une fois par trimestre

Et la correction avance souvent encore plus lentement, en attendant la priorisation, la disponibilité des équipes d’ingénierie et les cycles de publication. Même le temps nécessaire pour déployer du code en production crée des brèches que des systèmes plus rapides peuvent exploiter.
Cela crée un écart qui s’élargit :

• Les vulnérabilités sont découvertes à la vitesse des machines

• Les correctifs sont déployés selon des rythmes humains

Cet écart est la vraie surface d’attaque.
Si une vulnérabilité critique existe pendant des jours ou des semaines avant d’être corrigée, peu importe la manière dont elle a été découverte. Elle est exploitable.
Le modèle traditionnel « tester, signaler, corriger plus tard » ne tient tout simplement plus lorsque les attaquants et les systèmes de découverte fonctionnent en continu.
Ce modèle est déjà dépassé.

Ce qui fonctionne vraiment

Le changement ne concerne pas les outils. Il concerne l’approche.
La sécurité doit passer de :

• Tests ponctuels → tests continus

En pratique, ce n’est pas qu’un changement d’outil.
Cela exige de repenser la place de la sécurité dans le cycle de développement.
Les tests continus combinent généralement :

• Des systèmes automatisés qui exécutent des tests en continu, et non une seule fois par an

• Une sécurité intégrée directement dans les pipelines CI/CD

• Des développeurs qui prennent en charge et corrigent les problèmes dans le cadre des workflows normaux

• Des tests humains périodiques pour des chemins d’attaque plus profonds et plus complexes

Ce n’est pas quelque chose que la plupart des équipes peuvent résoudre avec des effectifs seuls.
Les tests manuels ne passent pas à l’échelle pour suivre le rythme du développement moderne ni celui des attaquants modernes.
C’est pourquoi nous observons un basculement vers l’automatisation et, dans de nombreux cas, vers l’externalisation des tests continus à des systèmes capables d’opérer à la vitesse des machines.
L’urgence ici est bien réelle.

Et maintenant ?

L’IA accélère déjà la découverte des vulnérabilités. Les attaquants n’attendent pas votre prochain pentest planifié.
Si votre application évolue chaque jour, vos tests de sécurité et votre capacité à corriger les problèmes doivent suivre.
Quelle que soit l’architecture, les évaluations ponctuelles traditionnelles passent à côté de l’essentiel. Les bases de code évoluent à la vitesse des machines, et les surfaces d’attaque aussi.
Les systèmes open source doivent reconnaître et assumer l’exposition supplémentaire liée à la visibilité du code. Les systèmes en code fermé, quant à eux, ne peuvent pas compter sur l’obscurité et devront eux aussi améliorer leur posture de sécurité.
L’écart entre la vitesse à laquelle nous construisons des logiciels et celle à laquelle nous les testons se creuse.
L’IA accélère les deux côtés, mais pour l’instant, les attaquants ont l’avantage.
Si vous ne faites pas évoluer activement la sécurité au même rythme que la menace, vos systèmes échoueront.

Le benchmark mentionné ci-dessus (XBow) est disponible publiquement sur GitHub. Nos résultats combinent des tests de benchmark contrôlés avec des données réelles issues de systèmes de production sur l’ensemble de notre plateforme.