Il existe désormais quatre méthodes véritablement distinctes pour rechercher des vulnérabilités dans une application, et chacune d’entre elles teste des aspects que les autres ne peuvent structurellement pas couvrir. Cela va de la comparaison basée sur des modèles (connue sous le nom d’ SAST, qui compare le code à des modèles connus) aux analyses approfondies par agents. Ces analyses par agent peuvent prendre la forme de signaux précoces (analyses « Deep PR »), qui évaluent l’impact d’une modification sur le reste du code du référentiel ; d’analyses « analyse de code par IA » (souvent appelées« AI SAST» sur le marché), qui analysent la logique d’une base de code sans nécessiter de déploiement ; ou d’analyses « pentest IA », qui fonctionnent de la même manière mais sur une cible active et en exécution, et valident leurs résultats en tentant d’exploiter les failles détectées. Cet article vous aide à déterminer quel outil est le mieux adapté à chaque cas d’utilisation.
TL;DR
Ces quatre outils ne sont pas concurrents. Chacun fonctionne différemment, et pas seulement à des niveaux de profondeur différents. « SAST » est déterministe : le même code produit toujours le même résultat, mais uniquement pour les modèles qu’il connaît déjà. « Deep PR Review », « analyse de code par IA » et « AI Pentest » s’appuient quant à eux sur la logique et l’intention, détectant ainsi ce que « SAST » ne peut structurellement pas détecter, à différentes échelles et à différentes étapes du cycle de vie.
Couverture : SAST. Étendue, continue et peu coûteuse. Elle s'exécute à chaque commit, pull request et pour chaque modèle connu. C'est votre porte d'entrée. Elle est également très utile dans l'IDE, où elle peut s'exécuter pendant que le développeur ou l'agent crée du code, ce qui vous permet d'obtenir un retour d'information avant même que le code ne soit validé.
Premières impressions : Analyse approfondie d'PR . Justification de la logique métier pour chaque pull request, détection des failles IDOR, des failles de type « contrôle d’accès défaillant » et d’autres failles que l’ SAST ion et une révision humaine rapide ne parviennent pas à détecter. Il examine chaque modification dès son ouverture, en analysant son impact sur le reste du code.
Confiance : analyse de code par IA. Le même raisonnement que pour la revue « Deep PR », appliqué à l’ensemble du référentiel plutôt qu’à une modification à la fois. Cette portée en fait la couche idéale pour les modifications significatives et les cibles difficiles à tester, permettant de mettre en évidence de véritables failles logiques bien avant même qu’une cible en production n’existe pour effectuer des tests.
Démonstration : Test d'intrusion par IA. Le même raisonnement, validé sur un système en production par le biais d'une exploitation réelle. Cela fournit une preuve tangible plutôt qu'une simple estimation, ce qui explique également pourquoi cette méthode répond aux exigences de conformité.
Ensemble, ils couvrent l'intégralité du cycle de vie : chaque commit, chaque modification significative et chaque version nécessitant une validation. Voici ce que chacun d'entre eux couvre concrètement, en commençant par la couche de base.
Ce que vérifie « SAST » : les modèles connus, de manière déterministe
Tests de sécurité des applications statiques Il permet de détecter des schémas de problèmes, par exemple lorsqu’un paramètre corrompu est transmis à un appel de base de données. Si vous exécutez deux fois le même code avec cet outil, vous obtiendrez exactement le même résultat.
Sa limite réside dans son incapacité à raisonner. Un moteur de règles ne dispose d’aucun modèle permettant de comprendre ce que fait réellement l’application. Il se contente de lire le code ligne par ligne, en recherchant des motifs qu’il connaît déjà, et il est incapable de distinguer les données fiables des données non fiables au fur et à mesure que celles-ci transitent par l’application.
Prenons l’exemple classique de l’injection SQL: une entrée utilisateur directement intégrée dans une requête. Cela arrive encore, mais dans un code abouti, cela se présente rarement sous une forme aussi « propre ». Les données non fiables entrent généralement par un point inoffensif, comme un en-tête de requête , puis transitent par plusieurs fonctions sans rapport les unes avec les autres avant d’atteindre une destination finale et de devenir dangereuses, souvent plusieurs couches en aval. Un scanner basé sur la reconnaissance de motifs ne peut pas suivre ce chemin. Il ne peut pas séparer les données fiables des données non fiables au fur et à mesure que celles-ci se déplacent ; il signale donc tout ce qui ressemble à une injection, qu’un attaquant puisse ou non y accéder. Ces signalements inaccessibles sont à l’origine du bruit, et c’est la raison pour laquelle la reconnaissance de motifs a valu à l’ SAST e sa réputation de faux positifs.
Mais cela ne signifie pas pour autant qu’il ne fail SAST . Si SAST signale douze problèmes le lundi et neuf le mardi pour un code identique, les développeurs cesseront de lui faire confiance. Des études montrent que 65 % des équipes affirment que les faux positifs les poussent à adopter des comportements risqués, qu’il s’agisse de retarder les corrections, d’ignorer les alertes ou de contourner les contrôles, bien que la fonctionnalité AutoTriage d’ Aikido soit spécialement conçue pour filtrer ce bruit avant qu’il n’atteigne les développeurs. Même avec ce coût, SAST reste suffisamment abordable pour contrôler chaque commit, ce qui correspond exactement aux besoins de l’intégration continue (CI), du déploiement continu (CD), des tests de régression et de la conformité.
Analyse approfondie de l'PR : raisons justifiant une modification avant sa fusion
Se contenter d’examiner un diff ne permet pas de comprendre comment cette modification se comporte une fois intégrée au reste de l’application. L’analyse approfondie des « PR s » (souvent appelée « AI Code Review » dans le secteur) est conçue pour aller au-delà du simple diff. Plutôt que d’évaluer une modification de manière isolée, elle analyse la façon dont celle-ci interagit avec le code présent ailleurs dans le dépôt, y compris les bibliothèques partagées et les services des dépôts liés. C’est essentiellement ce que vous demanderiez à un ingénieur senior de faire, s’il disposait de la marge de manœuvre nécessaire pour tracer réellement chaque dépendance avant d’approuver une « PR » (ce qui reste un vœu pieux). Vous pouvez ainsi mettre au jour des bogues tels que les fuites de données croisées ou les « contrôle d’accès défaillant » — des failles de la logique métier qu’aucune révision humaine rapide ni aucun outil de reconnaissance de motifs ne serait en mesure de détecter, car rien de tout cela n’est visible à partir des seules lignes modifiées.
Ce sont généralement le genre de problèmes qui, autrement, seraient détectés lors d’un test d’intrusion ou en production, plusieurs semaines voire plusieurs mois après l’écriture du code, alors que la personne qui l’a écrit est déjà passée à autre chose et ne dispose plus du contexte nécessaire pour expliquer son choix. Deep Review permet de les repérer plus tôt, directement dans la pull request elle-même, afin que la personne à l’origine de la modification se souvienne encore pourquoi elle l’a écrite de cette manière. Les commentaires peuvent être ajoutés directement sur l’ PR, ce qui permet d’indiquer clairement, par exemple « c’est intentionnel » ou « c’est un faux positif », sans avoir à changer d’outil ni à quitter la revue.
analyse de code par IA teste le comportement et la logique, sans environnement de production
Plutôt que de se contenter de faire correspondre des modèles, l’analyse de code ( analyse de code par IA , souvent appelée « IA d’ SAST » sur le marché) lit votre code source et l’analyse de la même manière qu’un ingénieur expérimenté le ferait lors d’une révision. Elle suit les références d’un fichier à l’autre, retrace le parcours d’une requête depuis le gestionnaire de route jusqu’à la requête de base de données, et vérifie si le code fonctionne comme prévu. Elle peut effectuer cette analyse sur un dépôt entier, ou sur plusieurs dépôts connectés, y compris des monodépôts couvrant le front-end, le back-end et l’infrastructure-as-code. Il lui suffit pour cela d’avoir accès au dépôt.
Le raisonnement permet de détecter les failles de la logique métier, ce que l’ SAST e ne peut pas faire. Les IDOR en sont un bon exemple, car le raisonnement est nécessaire pour déterminer si un point de terminaison doit être limité à l’utilisateur demandeur ou non. Modifier un identifiant utilisateur pour consulter le profil public d’une personne peut être un comportement attendu. Le modifier pour consulter ses messages privés ou les paramètres de son compte constitue quant à lui une violation. Cette distinction dépend de ce que le point de terminaison est censé appliquer, et non de la ressource elle-même, ce qui ne peut pas faire l’objet d’une règle statique.
De plus, cet outil n’a pas besoin d’une cible en production pour fonctionner. Il n’est pas nécessaire de mettre en place un environnement de test (c’est-à-dire sans flux d’authentification configuré), car l’analyse s’effectue directement sur le dépôt de code. Cela lui permet d’accéder à des éléments inaccessibles lors d’un test d’intrusion en production, tels que du code masqué derrière un « feature flag », des routes réservées aux administrateurs sans identifiants fournis, ainsi que des scénarios de déni de service qu’il serait risqué d’exécuter sur un système de production. Le même raisonnement s’applique aux applications mobiles, aux contrats intelligents, aux applications de bureau et, en substance, à n’importe quel langage de programmation, y compris les langages plus anciens ou de niche pour lesquels aucun scanner basé sur des règles n’a jamais été conçu.
Il s’agit du même type de raisonnement que celui appliqué par Deep PR Review au niveau de l’ PR , mais la différence réside dans le fait que Deep PR Review détecte les problèmes à chaque modification, en comparant une pull request à l’ensemble du code source. analyse de code par IA , en revanche, effectue une analyse globale de l’ensemble du code source en une seule fois, ce qui explique pourquoi il convient particulièrement aux modifications majeures et aux versions complètes (c’est l’étape recommandée pour « Commencer »), tandis que Deep PR Review assure l’analyse continue au niveau de l’ PR qui s’ensuit.
Il convient de préciser pourquoi cela ne revient pas à demander directement à un modèle d'examiner votre code. Un modèle sollicité directement effectue un passage généraliste, qui s'apparente davantage à la relecture rapide d'un développeur à la recherche d'erreurs manifestes qu'à une révision approfondie. analyse de code par IA intègre ce même modèle dans un cadre qui exécute des analyses, recherche les problèmes en parallèle et effectue des validations indépendantes sur chaque dépôt ; c'est cette orchestration qui explique en grande partie la différence observée en conditions réelles en termes de bugs détectés.
Le choix entre l’ SAST traditionnelle et l’ analyse de code par IA ne se résume pas à une simple question de coût. Le raisonnement sur l’ensemble d’une base de code nécessite davantage de ressources de calcul et prend plus de temps que la recherche de correspondances de motifs. De plus, en l’absence d’application en production sur laquelle s’appuyer, les résultats sont classés par ordre de priorité en fonction de leur probabilité d’être réels, plutôt que d’être confirmés par l’exécution. C’est grâce à la rapidité et au déterminisme de SAST que vous pouvez l’intégrer directement dans votre processus CI/CD. C’est pourquoi analyse de code par IA convient mieux aux modifications significatives et aux versions majeures qu’à chaque commit. Cependant, le coût et l’efficacité des fonctionnalités basées sur des agents ne cessent de s’améliorer, et nous verrons donc toutes ces capacités d’IA devenir monnaie courante au sein des organisations.
pentest IA analyse votre code et l'exécute sur votre application
pentest IA, ce qui est le cas de l'attaque de type « Aikido », repose sur le même raisonnement sous-jacent que analyse de code par IA. Mais le test d'intrusion va plus loin en s'exécutant sur une application en production. Cela signifie qu'il peut tenter une exploitation réelle via des agents envoyant de véritables requêtes et cartographiant une surface d'attaque réelle.
C'est cette validation en temps réel qui permet d'éliminer en grande partie le problème des faux positifs (que nous aborderons plus en détail dans la section suivante). analyse de code par IA peut déduire, à partir du code, qu'une faille de logique métier telle que l'IDOR semble exister ; un test d'intrusion permet alors de tenter l'exploitation de cette faille sur le système en fonctionnement et de vérifier si elle fonctionne réellement.
Un test d'intrusion nécessite un environnement stable, un système d'authentification opérationnel et des rôles d'utilisateurs réels déjà configurés, autant d'éléments dont analyse de code par IA n'a pas besoin puisqu'il lit directement à la source. Une fois cet environnement en place, le test lui-même s'exécute rapidement, mais le traitement du trafic en temps réel et l'analyse des conséquences d'une interaction donnée restent plus coûteux par exécution que l'analyse de texte. C'est pourquoi un test d'intrusion se situe au-dessus de SAST et de analyse de code par IA en termes de coût de calcul.
Un test d'intrusion basé sur l'IA est également le seul de ces trois types à répondre aux exigences de conformité de référentiels tels que SOC 2 et ISO 27001 pour un test d'intrusion en conditions réelles. analyse de code par IA ne peut pas se substituer à un test d'intrusion en conditions réelles lorsque la conformité l'exige, mais il peut néanmoins être utile de l'effectuer au préalable. Corriger les failles logiques avant le test d'intrusion audité permet de réduire le nombre de failles détectées lors du test en conditions réelles, tout en diminuant le coût par mission.
Il convient également de noter que le fait de donner à un agent de test d’intrusion l’accès au code source (ce qu’on appelle le « test en boîte blanche ») modifie considérablement les résultats obtenus (ainsi que le coût de l’opération). Sur plus de 1 000 tests d’intrusion basés sur l’IA réalisés sur la plateforme Aikido, les missions avec accès au code (boîte blanche) ont mis en évidence, en moyenne, sept fois plus de vulnérabilités élevées et critiques que celles sans accès au code (boîte grise), pour un coût de calcul par vulnérabilité environ deux fois moins élevé. Les tests « greybox » ont nécessité 31 lancements d’agents pour mettre en évidence une seule vulnérabilité, contre 15 pour les tests « whitebox ». Ainsi, en combinant efficacement les deux approches (analyse du code source fournie par analyse de code par IA) et l’exploitation en temps réel via pentest IA, vous obtenez une vision plus complète de la situation qu’en utilisant l’une ou l’autre méthode seule. Il s’agit d’un choix simple à effectuer : sélectionnez « whitebox » dans l’interface utilisateur de Aikido Attack.
Si vous ne savez pas comment évaluer les produits de tests d'intrusion basés sur l'IA, consultez notre guide d'achat.
Pourquoi on obtient davantage de faux positifs
analyse de code par IA analyser votre code sans l'exécuter. Il peut détecter qu'une requête aboutit à une opération dangereuse et qu'aucun mécanisme n'intervient en cours de route pour l'arrêter, et signaler cela comme une faille exploitable. Comme il fonctionne à partir du code source plutôt que d'une cible en production, certaines des failles qu'il signale s'avéreront en réalité protégées par des mécanismes que le modèle ne pouvait pas détecter à partir du dépôt seul.
Un test d'intrusion ajoute à ce même raisonnement une exploitation en conditions réelles. Il exploite la vulnérabilité présumée sur l'application en cours d'exécution et rend compte de ce qui a effectivement abouti ; c'est pourquoi ses conclusions s'appuient sur des preuves plutôt que sur des estimations.
L'exécution simultanée des deux permet de combler les lacunes dans les deux sens. analyse de code par IA accède à du code qu'un test d'intrusion n'atteint jamais, comme tout ce qui se trouve derrière un indicateur de fonctionnalité ou une route d'administration sans identifiants. Un test d'intrusion confirme ce que analyse de code par IA signale, dès lors qu'il existe une cible en production sur laquelle effectuer les tests.
Lequel te faut-il ?
Adapter les dépenses au risque
C'est votre budget et votre tolérance au risque qui déterminent la part de votre patrimoine que chaque outil de gestion doit couvrir.
Une petite équipe dispose d’une base solide et économique grâce à la seule fonctionnalité « analyse de code par IA », qu’elle exécute sur le code existant pour détecter ce qui était passé inaperçu jusqu’à présent. Il n’y a pas d’environnement à mettre en place au préalable, ni d’authentification à configurer, ce qui en fait la couche capable de commencer à couvrir les risques avant même que quoi que ce soit d’autre ne soit en place. L’ajout, à partir de là, d’une couche supplémentaire de « Deep PR Review » permet d’éviter que cette base ne soit négligée à mesure que du nouveau code est déployé, en détectant les problèmes de logique métier à chaque pull request sans avoir besoin d’un environnement de production ni d’un cycle de tests d’intrusion planifié.
Un test d'intrusion basé sur l'IA (Aikido ) s'inscrit au-dessus des couches de raisonnement sous la forme d'une validation périodique en temps réel, généralement annuelle ou à chaque nouvelle version majeure, qui porte sur l'ensemble de l'environnement et de la configuration plutôt que sur le code seul. La plupart des organisations effectuent des tests d’intrusion basés sur l’IA à cette fréquence, souvent pour satisfaire à une exigence de conformité telle que SOC 2 ou ISO 27001. L’ pentest IA e continue (Aikido Infinite) se situe au-dessus de cela, en tant que niveau distinct, pour les équipes dont la posture de sécurité exige que la vulnérabilité soit vérifiée en continu plutôt qu’à intervalles réguliers, quelle que soit la taille de l’entreprise.
La plupart des équipes se situent à un stade ou à un autre de cette progression, où la véritable question porte sur la définition du périmètre : quels dépôts et quelles versions justifient un test d’intrusion planifié, et lesquels peuvent être couverts au quotidien par l’ analyse de code par IA et le Deep PR Review ? Commencer par analyser les couches logiques et corriger les failles avant le test d’intrusion est un moyen de rentabiliser davantage cet investissement, car une cible plus « propre » signifie moins de failles détectées lors du test d’intrusion qui auraient pu être corrigées à moindre coût en amont.
Considérez cela comme une valeur par défaut de départ que les équipes adapteront en fonction de leur propre profil de risque.
En résumé
Dans la pratique, la couverture de l’ensemble du cycle de vie implique d’exécuter ces quatre processus simultanément, en fonction de vos besoins à un moment donné. L’analyse des commits ( SAST ) couvre chaque commit et chaque pull request, et s’exécute en continu. L’analyse approfondie des tests unitaires (Deep PR ) examine la logique métier de chaque modification dès sa création, avant sa fusion. L’analyse des tests de sécurité ( analyse de code par IA ) étend ce même raisonnement à l’ensemble du référentiel pour les modifications significatives, avant même tout déploiement, et permet de détecter les erreurs de configuration ou les paramètres spécifiques à l’environnement qu’un test en production pourrait ne pas repérer. AI Pentest assure une validation en production périodique, le contrôle le plus approfondi qui soit et celui auquel s’attendent les cadres de conformité, tandis que Continuous Pentest est disponible pour les équipes dont la posture de sécurité nécessite cette validation en continu plutôt qu’à intervalles réguliers. Les programmes de sécurité les plus performants exploitent ces quatre solutions de manière hiérarchisée, plutôt que de devoir choisir entre elles.
