L’IA élargit votre surface d’attaque. La testez-vous ?

Les promesses abondent sur le marché. Un fournisseur arrive en tête d’un classement. Un autre lève des centaines de millions grâce à un pitch deck. Pendant ce temps, vos développeurs ont livré trois services générés par l’IA avant le déjeuner. Voici la conversation que le secteur évite, et vers laquelle nous travaillons depuis des années.

Cette conversation a lieu en ce moment au sein de toutes les équipes de sécurité.

Quelqu’un fait la démonstration d’un assistant de programmation IA. Sa rapidité est indéniable et l’équipe est impressionnée. Elle reste néanmoins prudente, parfois sceptique.

Un code qui demandait auparavant un sprint ne prend plus qu’un après-midi. La direction est très enthousiaste. Les développeurs qui traverseront cette époque le sont aussi. Et la sécurité, si elle est honnête, se demande discrètement si les outils dont elle dispose sont adaptés à ce qui se profile.

Narrateur : Ils ne le sont pas.

Le benchmark dont personne ne veut parler

BaxBench n’est pas un rapport sur les menaces : c’est une mesure. Lorsque des chercheurs ont évalué du code backend généré par des LLM sur des tâches réelles, 62 % de ce code était défectueux ou vulnérable. Parmi le code qui fonctionnait correctement, près de la moitié restait exploitable.

Relisez bien : l’IA écrit du code fonctionnel, dont la moitié reste exploitable.

Ce n’est pas une raison pour cesser d’utiliser les assistants de programmation IA : le mouvement est déjà irréversible. C’est une raison d’être précis sur la notion de sécurité, dans un monde où la génération de code a définitivement accéléré.

L’analyse statique dès la création du code, qu’il s’agisse d’un outil SAST dans l’IDE ou de conseils de sécurité assistés par l’IA tout au long du cycle de développement, est une première étape indispensable, mais pas une fin en soi. Elle peut vous indiquer ce qui se trouve dans le code, mais pas si ce code est réellement exploitable comme le ferait un acteur malveillant. Même les approches statiques multimodales les plus récentes, qui combinent l’analyse de taint et le raisonnement des LLM, ne peuvent que prédire ce qui pourrait être exploitable dans le code ; elles ne peuvent pas prouver le comportement réel à l’exécution dans des conditions d’attaque réelles.

Pour cela, vous devez sonder l’application depuis l’extérieur, à l’exécution, comme le ferait un véritable attaquant.

La deuxième surface d’attaque que personne n’a cartographiée

Tandis que le secteur débattait de la sécurité du code généré par l’IA, une deuxième surface d’attaque se dessinait discrètement.

Les agents IA ne fonctionnent pas en vase clos. Ils appellent des API, souvent privilégiées et souvent non documentées. Ces API ont été conçues avant que quiconque n’imagine qu’elles seraient appelées de manière autonome et à grande échelle. Gartner prévoit que d’ici 2028, les agents IA seront les principaux consommateurs des API d’entreprise. D’ici 2029, plus de 50 % des attaques réussies contre des agents IA devraient exploiter des défaillances de contrôle d’accès (BOLA/IDOR), précisément le type de faille que l’analyse statique a toujours eu du mal à valider.

Ce n’est pas une prédiction audacieuse : c’est la description de décisions architecturales que votre organisation a déjà prises.

BodySnatcher a rendu le risque concret. Avec la CVE-2025-12420, un attaquant non authentifié, muni de la seule adresse e-mail de sa cible, pouvait usurper l’identité d’un administrateur ServiceNow, contourner le MFA et le SSO, exécuter des flux de travail d’agents IA et créer des comptes dérobés dotés de tous les privilèges. Numéros de sécurité sociale, dossiers financiers, propriété intellectuelle confidentielle : tout était à portée de main… Tout était exposé.

La technique n’avait rien d’ésotérique : pas de faille zero-day, pas d’injection de prompt ingénieuse. La vulnérabilité se trouvait derrière un agent auquel l’organisation faisait entièrement confiance, sans avoir été testée. La conclusion du chercheur était sans équivoque : « Les agents IA amplifient considérablement l’impact des failles de sécurité traditionnelles. »

La vitesse de livraison a dépassé les capacités de validation. La solution ne peut pas être de ralentir. Il faut fondamentalement changer notre conception des tests.

Ces failles ne sont pas nouvelles : ce sont les mêmes failles qu’il était déjà difficile d’identifier, simplement amplifiées par la nouvelle architecture qui s’y superpose.

Pourquoi il s’agit en réalité d’un seul et même problème

Voici ce qui, selon moi, échappe à beaucoup lorsqu’on traite ces deux problèmes séparément : ils ont tous la même cause fondamentale. La vitesse de livraison a tout simplement dépassé les capacités de validation. Les assistants de programmation IA génèrent du code plus vite que tout processus de sécurité n’a jamais été conçu pour le gérer, et les agents IA appellent des API plus vite que tout inventaire n’a été conçu pour les répertorier. Dans les deux cas, quelque chose tourne en production sans avoir jamais fait l’objet d’une véritable attaque systématique : ce n’est pas seulement examiné ou analysé, c’est *attaqué*, comme le ferait un véritable acteur malveillant.

Nous pensons que la réponse ne peut pas consister à ralentir. Il faut repenser ce que signifie réellement tester.

Les tests dynamiques ne sont pas un vestige de l’époque révolue d’avant l’IA ; ils constituent la discipline dont l’ère de l’IA a enfin besoin. Dans un monde post-IA, ils deviennent un socle, un socle essentiel.

La question n’est donc plus de savoir si vous devez effectuer des tests dynamiques, mais si vos tests dynamiques sont suffisamment intelligents et capables de suivre le rythme de ce qui tourne aujourd’hui en production : du code généré par l’IA, à la vitesse de l’IA, derrière des API que les agents appellent plus vite que tout inventaire humain ne peut les répertorier.

Les tests dynamiques modernes doivent eux-mêmes s’appuyer sur l’IA : être assez rapides pour s’intégrer au pipeline, assez intelligents pour distinguer une exploitabilité réelle du bruit, et conçus spécifiquement pour une surface d’attaque qui n’existait pas il y a seulement deux ans.

Du signal, pas du bruit

Voici le véritable problème du code généré par l’IA à grande échelle : il ne produit pas seulement davantage de code, mais aussi davantage de résultats, d’alertes et d’éléments qui semblent nécessiter une intervention. Imaginez tout cela traité par des outils de sécurité conçus pour un monde beaucoup plus lent.

Submergés par ce bruit, les développeurs doivent décider où consacrer leur temps. Le plus souvent, leur choix repose sur l’instinct, l’ancienneté ou la pression constante des échéances.

La lassitude face aux alertes n’est pas nouvelle, mais à l’ère du développement assisté par l’IA, elle s’aggrave : les développeurs n’examinent plus les résultats d’un seul sprint ; ils passent en revue une quantité de code qui aurait demandé toute une équipe pendant un trimestre. Si chaque résultat a la même priorité, rien n’est corrigé. Du moins pas avec confiance.

La donne change lorsque l’on établit des corrélations. Lorsqu’un résultat statique et un résultat dynamique renvoient exactement à la même cause (lorsque le code indique une vulnérabilité et que les tests à l’exécution prouvent qu’elle est exploitable), vous n’avez plus deux problèmes à trier. Vous avez une seule correction prioritaire, à laquelle les développeurs peuvent vraiment se fier.

Le bruit s’atténue. Le signal se précise.

Cette précision est plus importante à l’ère de l’IA qu’elle ne l’a jamais été. Un taux de faux positifs de 0,08 %, ce n’est pas une spécification produit : c’est ce qui se passe lorsque la sécurité cesse d’être un poids pour les développeurs et devient un accélérateur. L’IA écrit le code, vous prouvez ce qui est réellement défectueux et les développeurs livrent plus vite, en toute confiance plutôt qu’avec anxiété.

✔️ SAST alimenté par les LLM, capable d’identifier les schémas de code généré par l’IA et les risques associés, dans l’IDE et le pipeline, dès aujourd’hui.

✔️ DAST intelligent qui sonde activement les applications et API en cours d’exécution pour confirmer leur exploitabilité réelle, en particulier les failles BOLA, IDOR et les problèmes d’autorisation propres aux agents.

✔️ Des résultats corrélés qui relient les signaux statiques à une confirmation dynamique : une correction prioritaire, pas une file d’attente à trier.

✔️ La découverte d’API qui révèle les points de terminaison appelés de manière autonome par vos agents IA, y compris ceux qui ne sont pas documentés.

✔️ Une couverture continue intégrée au pipeline de livraison, et non une intervention trimestrielle.

Ce que sont (ou devraient être) les tests d’intrusion par l’IA

De nombreux fournisseurs adoptent aujourd’hui l’appellation « tests d’intrusion par l’IA ». Pour certains, cela signifie simplement utiliser des LLM pour créer des charges utiles d’attaque ; pour d’autres, générer des rapports de résultats à l’aide d’« agents » (nous nous interrogeons aussi sur la notion d’agentivité). Quelques-uns seulement désignent par là quelque chose de bien plus intéressant.

Ce que cette discipline exige réellement, et ce que l’ère de l’IA exige tout particulièrement, c’est une approche capable de tester le code généré par l’IA à la recherche de défauts logiques propres à l’IA, de suivre les API appelées par les agents (y compris celles qui ne sont pas documentées), de corréler les résultats dynamiques au contexte et aux informations du code pour distinguer le signal du bruit, et de le faire en continu plutôt qu’au cours d’une intervention ponctuelle et décousue.

Au passage, cela ne devrait pas être une liste de fonctionnalités ni une feuille de route : cela devrait être la norme. Or, le secteur n’a pas encore réussi à bien la définir. C’est précisément pourquoi le moment est venu de le faire. Alors, faisons-le.

Nous travaillons à l’établissement de cette norme depuis des années, et les résultats que nous observons chez nos clients en production continuent de confirmer la pertinence de cette approche.

Les tests de sécurité à l’ère de l’IA ne se contentent pas de détecter davantage de problèmes plus rapidement. Ils corrèlent les prédictions statiques à des preuves dynamiques et fournissent aux développeurs des corrections qu’ils peuvent déployer en toute confiance, sans anxiété.

Le débat sur la sécurité de l’IA a été dominé par deux questions présentées comme distinctes : pouvons-nous sécuriser les modèles d’IA ? Et pouvons-nous utiliser l’IA pour trouver des vulnérabilités ? Ces deux questions sont légitimes, mais aucune ne suffit à elle seule.

La question la plus urgente est plus simple : qui teste et attaque le code et les API que l’IA crée et fait fonctionner ?

Si ce n’est pas vous, vous pouvez être sûr que quelqu’un (ou quelque CHOSE) d’autre s’en chargera.