L’IA détecte des vulnérabilités critiques plus rapidement que les équipes ne peuvent les corriger

Au cours des 90 derniers jours, nous avons mené des pentests autonomes contre 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 n’est pas 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 remédiations suivent encore des calendriers humains.
À mesure que l’IA accélère la découverte des vulnérabilités, la fenêtre entre l’introduction d’un bug et son exploitation se rétrécit. 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 découvertes)

• 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 découverte est validée par un exploit de preuve de concept fonctionnel.
Près de la moitié de toutes les 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 logiques.
Une faille logique signifie que le système se comporte exactement comme le code le prévoit, mais que la conception elle-même est non sécurisée.
Ce ne sont pas des erreurs de configuration ni des bibliothèques obsolètes. Ce sont des bugs dans le fonctionnement réel de l’application, dans la façon dont les données circulent, dont les permissions sont appliquées et dont les systèmes se font confiance mutuellement.

Voici à quoi cela ressemble en pratique :

• IDOR (référence directe non sécurisée à un objet) — 177 découvertes
  Les attaquants peuvent accéder aux données d’autres utilisateurs ou les modifier simplement en changeant des identifiants (par exemple, des ID utilisateur ou des ID de fichier). Cela peut exposer des données sensibles à grande échelle, voire permettre la prise de contrôle de comptes.

• SSRF (falsification de requêtes côté serveur) — 122 découvertes
  Les attaquants peuvent tromper le serveur pour qu’il envoie des requêtes en leur nom, souvent vers des systèmes internes. Cela peut exposer des API internes, des identifiants cloud ou une infrastructure qui ne devrait jamais être accessible publiquement.

• Authentification manquante — 105 découvertes
  Les points de terminaison 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 la manière dont l’application se comporte, et pas seulement sa configuration.
Les scanners traditionnels peinent ici car ils ne comprennent pas le comportement. Ils recherchent des signatures, pas la logique.

Pourquoi l’IA en trouve davantage

Jusqu’à récemment, trouver et exploiter ces types de vulnérabilités exigeait du temps, des compétences et un effort 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 points de terminaison, ils les explorent.

• Ils testent des cas limites

• Ils enchaînent plusieurs étapes

• Ils itèrent rapidement à travers 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 mémorisé l’ensemble des connaissances du monde.
Ce changement est ce qui alimente les résultats que nous observons : une découverte constante 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 le fonctionnement interne de la serrure, il est beaucoup plus facile de l’ouvrir.
Lorsque les systèmes d’IA ont accès au code source, ils peuvent analyser directement chaque chemin de code au lieu d’inférer le comportement depuis l’extérieur.
Lors de tests de référence contrôlés utilisant la suite de validation XBow, librement disponible, 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 :

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

• Identifier les hypothèses erronées dans la logique métier

• Explorer les cas limites beaucoup plus efficacement

Cela rend les failles logiques nettement plus faciles à trouver et à exploiter.
À mesure que de plus en plus d’applications sont développées au grand jour, et que les systèmes d’IA s’améliorent, la vitesse de découverte des vulnérabilités continue d’augmenter.
Cela dit, être en code source fermé ne vous rend pas sûr par défaut.
La sécurité par l’obscurité n’a jamais constitué une véritable défense. Un attaquant déterminé disposant de suffisamment de capacité de calcul et d’un grand nombre de jetons à brûler peut toujours énumérer, fuzzer et finir par découvrir des chemins exploitables, même sans accès direct au code.
La conclusion n’est donc pas qu’il faut choisir entre open source et closed source. 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 : vitesse accrue = coût moindre

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 :

• Exécuter des milliers de tests en parallèle

• Explorer en continu de nouveaux chemins de code

• Enchaîner automatiquement les exploits

Cela signifie que les vulnérabilités sont découvertes plus vite que jamais, souvent en 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 remédiation 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 pousser du code en production crée des fenêtres qu’un système plus rapide peut exploiter.
Cela crée un écart qui se creuse :

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

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

Cet écart constitue la véritable 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é trouvée. Elle est exploitable.
Le modèle traditionnel « tester, signaler, corriger plus tard » ne tient tout simplement pas lorsque les attaquants comme 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, il ne s’agit pas seulement d’un changement d’outillage.
Cela exige de repenser la façon dont la sécurité s’intègre au 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 fois par an

• La 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 de leurs workflows habituels

• 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 uniquement en augmentant les effectifs.
Les tests manuels ne peuvent pas suivre le rythme du développement moderne ni celui des attaquants modernes.
C’est pourquoi nous observons un déplacement 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 programmé.
Si votre application change tous les jours, vos tests de sécurité et votre capacité à corriger les problèmes doivent suivre le rythme.
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 source 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 développons des logiciels et la fréquence à 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 mettez pas activement à l’échelle la sécurité pour qu’elle corresponde à la menace, vos systèmes échoueront.

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