La prochaine ère de l’AppSec : pourquoi le code généré par l’IA nécessite des tests dynamiques offensifs

Mon collègue Manoj Nair a récemment écrit sur l’écart grandissant entre ce que l’IA crée et ce que les équipes de sécurité testent réellement. Il a expliqué que le développement accéléré par l’IA a fondamentalement dépassé les capacités de validation, et que la solution ne consiste pas à ralentir, mais à repenser les tests. Je suis entièrement d’accord.

Je voudrais ici approfondir la question. J’ai consacré près de dix ans à créer des moteurs de tests dynamiques de sécurité. D’abord chez Probely, que j’ai cofondé, puis chez Snyk, où notre technologie alimente Snyk API & Web. Alors, quand je dis que notre façon d’envisager les tests dynamiques de sécurité va complètement changer, je ne fais pas de prédiction sur le marché : je décris ce que je vois à l’œuvre dans les architectures que nous testons chaque jour.

L’analyse du code a fait d’immenses progrès. Mais cela ne suffit toujours pas.

Commençons par reconnaître les progrès accomplis : l’analyse statique a fait un bond considérable.

Pendant des années, cette catégorie est restée cantonnée à une époque de correspondances rigides et bruyantes, avec des moteurs fondés sur des règles qui généraient une multitude de résultats, mais très peu de signaux pertinents.

Puis est arrivée une première vague d’apprentissage automatique et d’IA symbolique, capable de suivre des flux de données plus complexes dans les bases de code : des moteurs comme Snyk Code, optimisé par DeepCode AI, qui a apporté une véritable compréhension sémantique à l’analyse statique.

Aujourd’hui, une capacité véritablement différente émerge : des outils agentiques qui s’appuient sur le raisonnement sémantique pour comprendre l’intention réelle du code, et pas seulement sa syntaxe. Ces modèles peuvent détecter directement dans le code source des défauts complexes de logique métier et des problèmes d’autorisation, d’une manière inimaginable il y a cinq ans.

Il s’agit d’une avancée réelle et importante. Elle est telle qu’on peut se demander si le secteur continuera d’appeler cela « SAST » ou s’il inventera un tout nouveau terme.

Mais voilà : même le moteur d’analyse de code le plus avancé a une limite : il ne peut pas tester ce qu’il ne peut pas exécuter.

Les applications modernes ne sont pas monolithiques. Ce sont des environnements fortement distribués, composés et multicouches : des applications monopages qui communiquent avec des dizaines de microservices backend, chacun ayant son propre contexte d’authentification, ses schémas d’accès aux données et son cycle de déploiement. Un analyseur de code sophistiqué peut détecter une faille d’autorisation dans la base de code d’un microservice. Mais que se passe-t-il si la vulnérabilité ne se manifeste que lorsque plusieurs composants interagissent ?

Prenons un cas concret : un problème d’autorisation qui n’apparaît qu’en raison de la façon dont une application frontend traite un jeton, combinée à la manière dont une passerelle API achemine la requête et dont un service backend secondaire interprète le rôle de l’utilisateur. Aucune base de code ne contient à elle seule la vulnérabilité. Celle-ci résulte de leur interaction. Aussi intelligente soit-elle, l’analyse statique peine à suivre l’état entre les composants de différentes bases de code, car elle ne peut fondamentalement pas observer le système dans son ensemble.

C’est précisément ce que permettent les tests dynamiques de sécurité. Ils peuvent vérifier si un attaquant est réellement capable d’exploiter un système lorsque tous ces composants distincts sont assemblés dans un environnement réel.

Cette zone d’ombre liée à l’exécution concerne directement la nouvelle frontière décrite par Manoj : des agents IA qui appellent des API de manière autonome et à grande échelle, d’une façon que leurs créateurs n’avaient jamais envisagée. Des risques comme l’injection de prompt, le détournement d’objectif et l’empoisonnement du contexte n’existent pas dans le code source. Ce sont des comportements émergents qui ne se manifestent qu’à l’exécution. Tout comme les interactions complexes entre microservices, ces menaces ne peuvent être vérifiées qu’en interagissant dynamiquement avec le système en production.

La convergence dont personne ne parle

Une autre évolution du marché mérite, selon moi, qu’on s’y intéresse plus directement.

Au cours de l’année écoulée, une nouvelle appellation a fait son apparition : « AI Pentester ». Et cette appellation décrit une réalité, car ces outils représentent une véritable évolution de l’approche. Au lieu d’un analyseur rigide qui envoie des charges utiles statiques à chaque entrée détectée, cette nouvelle génération d’outils peut raisonner sur l’état de l’application et décider des étapes suivantes en fonction du contexte, à la manière d’un chercheur en sécurité.

Mais voici ce que j’ai constaté et ce que le marché, selon moi, comprend mal : ces approches sont fondamentalement complémentaires, et non concurrentes.

Nous avons récemment testé une application volontairement vulnérable à l’aide d’un moteur traditionnel de tests dynamiques de sécurité et d’une approche autonome de tests d’intrusion basée sur l’IA. Et les résultats sont éloquents.

Le moteur de tests dynamiques de sécurité a détecté des vulnérabilités qui avaient échappé à l’approche basée sur l’IA, tout simplement parce que les moteurs traditionnels sont conçus pour effectuer des vérifications exhaustives et systématiques : ils testent méthodiquement chaque paramètre, chaque point de terminaison et chaque cas limite.

De son côté, l’approche basée sur l’IA a décelé des failles de logique complexes que le moteur traditionnel ne pouvait pas comprendre, car elle était capable de raisonner sur les chaînes d’autorisation et la logique métier, contrairement à un analyseur déterministe.

Aucune des deux approches ne suffisait à elle seule. Ensemble, elles ont dressé un tableau bien plus complet.

À mes yeux, le secteur se dirige clairement vers une convergence. Le futur produit de cette catégorie combinera probablement ces deux capacités : un mode exhaustif pour couvrir l’ensemble des pipelines (ce dont les organisations ont besoin pour assurer une protection continue), et un mode ciblé, guidé par le contexte, pour détecter en profondeur les failles de logique (notamment les problèmes d’autorisation et les vulnérabilités en chaîne introduits à grande échelle par le code généré par l’IA).

On ne sait pas encore quelle appellation s’imposera : le marché conservera-t-il « DAST », adoptera-t-il « AI Pentesting » ou inventera-t-il un tout nouveau terme ? Mais la convergence elle-même semble inévitable.

La direction que prend le secteur

Si je devais décrire l’évolution architecturale la plus importante qui se profile, je dirais que l’intelligence au niveau du code et les tests dynamiques de sécurité sont en train de s’imbriquer profondément.

Pendant la majeure partie de son histoire, les tests dynamiques de sécurité ont fonctionné comme une boîte noire : sans connaissance du code source ni compréhension de la logique interne de l’application. Ils testaient le système de l’extérieur et signalaient leurs découvertes. C’était à la fois leur force (ils testaient la réalité, pas la théorie) et leur limite (ils ignoraient le contexte qui aurait pu les rendre bien plus efficaces).

La situation évolue. À mesure que les plateformes gagnent en maturité, elles tendent naturellement vers ce que les chercheurs en sécurité appellent depuis toujours les tests « grey-box » : une approche qui interagit avec l’application en production et comprend le code source sous-jacent. Dans un sens, l’analyse au niveau du code peut formuler des hypothèses sur des points de terminaison cachés ou des failles de logique, que les tests dynamiques de sécurité vérifient ensuite (ou réfutent) en environnement réel. Dans l’autre sens, comme le font les hackers chevronnés, les tests dynamiques de sécurité peuvent repérer un comportement suspect lorsque des applications ou des API sont en production, puis s’appuyer sur le contexte du code pour comprendre précisément comment une protection est mise en œuvre et concevoir la charge utile exacte, plutôt que de procéder par force brute.

Cette évolution contribue également à résoudre l’un des principaux obstacles historiques aux tests dynamiques de sécurité : la remédiation. Un outil dynamique pouvait toujours prouver l’existence d’un exploit en montrant la requête et la réponse HTTP malveillantes, ainsi que les preuves de l’exploitation, mais il laissait les développeurs deviner à quel endroit de la base de code se trouvait l’origine de la faille. En corrélant la preuve dynamique et le contexte du code, on obtient un résultat bien plus puissant : un constat qui prouve l’exploitabilité à l’exécution et indique directement le code à corriger.

C’est cette évolution qu’il faut suivre. Non pas parce qu’un fournisseur l’a déjà pleinement concrétisée (même si c’est notre cas), mais parce que les conditions architecturales nécessaires se mettent en place. Les équipes qui comprendront cette convergence le plus tôt seront celles qui bâtiront les programmes de sécurité les plus solides.

La conviction d’un bâtisseur

Je terminerai par une conviction qui se renforce à chaque architecture que nous testons.

L’époque où les tests dynamiques de sécurité étaient une simple case de conformité à cocher — des analyseurs lents et bruyants exécutés une fois par trimestre, dont on archivait les résultats — touche à sa fin. Non pas parce que l’idée était mauvaise, mais parce que le monde a changé.

Le code généré par l’IA est livré plus vite qu’aucun processus humain n’a été conçu pour le vérifier. Les agents IA invoquent des API plus vite qu’aucun inventaire n’a été conçu pour en assurer le suivi. Et les vulnérabilités introduites par ces forces, comme les défauts d’autorisation, les failles de logique métier et les problèmes d’état entre composants, sont précisément celles que seuls les tests dynamiques de sécurité peuvent prouver de façon concluante.

Ce qui se dessine ne remplace pas l’analyse du code : c’est l’autre moitié de l’équation. L’analyse du code indique ce qui pourrait être vulnérable, tandis que les tests dynamiques de sécurité révèlent ce qui est exploitable. Lorsque ces deux signaux se rejoignent, le bruit diminue et les résultats gagnent en précision… les développeurs peuvent livrer en toute confiance plutôt qu’avec appréhension.

Si vous élaborez un programme de sécurité adapté à l’ère de l’IA, cette confiance est un atout dans lequel il vaut la peine d’investir.