À l'heure actuelle, les outils de sécurité déterministes font tellement partie intégrante de la sécurité que, pendant longtemps, nous ne nous sommes pas interrogés sur les alternatives. L'IA devenant un élément central de la sécurité avec des modèles probabilistes, il est temps de revisiter le déterminisme et de clarifier son utilité. Sinon, pourquoi ne pas tout remplacer par l'IA ?
En bref, nous avons besoin du déterminisme pour sa prévisibilité et son efficacité. Les outils déterministes tels que SAST vous SAST le même résultat à chaque fois que vous les utilisez sur le même élément, de manière efficace. Ils sont donc utiles dans un pipeline CI/CD, défendables dans un audit de conformité et constituent une base pour tout le reste. L'IA est excellente en matière de raisonnement logique, mais, en raison de son imprévisibilité, il vaut mieux la réserver aux cas où vous n'avez pas besoin de résultats reproductibles.
Alors que de plus en plus d'outils probabilistes apparaissent sur le marché, nous souhaitons analyser comment le déterminisme permet de créer des pratiques de sécurité durables, comment l'IA offre de nouvelles possibilités et comment les deux peuvent être combinés pour obtenir un impact maximal.
Quand les outils de sécurité doivent être prévisibles
Certaines tâches de sécurité exigent avant tout cohérence et auditabilité. Nous constatons que ce besoin de prévisibilité se manifeste tout au long du processus de sécurité.
Lorsqu'un scanner signale un problème, un développeur doit lui faire suffisamment confiance pour agir à 23 heures. Lorsqu'un pipeline CI/CD bloque un déploiement, ce blocage doit résister à un examen minutieux. Dans un pipeline, votre scanner s'exécute à chaque commit ou pull request. S'il signale 12 problèmes le lundi et 9 le mardi pour un code identique, ce n'est pas bon signe. Les résultats de votre pipeline ne sont plus fiables. Les développeurs commencent à ignorer les alertes car le signal est incohérent, et vous ne pouvez pas utiliser les résultats du scan comme un critère significatif pour les fusions.
De même, les tests de régression dépendent de la reproductibilité. Lorsque vous corrigez une vulnérabilité et que vous effectuez une nouvelle analyse, un résultat satisfaisant doit signifier que la vulnérabilité a bien été corrigée, et non que le modèle l'a manquée lors de cette analyse. La détection des valeurs de référence et des dérives en dépend également, car elle doit déterminer si une nouvelle découverte reflète un changement réel dans le code source ou simplement une variance dans le scanner.
La prévisibilité est également nécessaire pour la conformité. Les auditeurs veulent des résultats cohérents et explicables dans le temps, avec un enregistrement clair de ce qui a été détecté, quand et pourquoi. Un scanner qui produit des résultats différents à chaque utilisation ne peut pas fournir cela.
Le coût pratique du manque de fiabilité en matière de sécurité érode lentement la confiance dans les outils eux-mêmes, jusqu'à ce que plus personne ne prenne les résultats au sérieux. La reproductibilité, l'auditabilité et les faibles taux de faux positifs doivent constituer la base sur laquelle une équipe de sécurité peut s'appuyer.
Outils de sécurité déterministes
SAST un outil de sécurité déterministe par excellence qui recherche les modèles et les vulnérabilités connus. Pensez aux secrets codés en dur, aux CVE connus, aux vulnérabilités de dépendance et aux modèles d'injection. Il fonctionne en analysant le code dans un arbre syntaxique abstrait et en suivant la façon dont les données contrôlées par l'utilisateur se déplacent dans l'application, depuis les points d'entrée jusqu'à l'endroit où elles sont utilisées. Une découverte renvoie à une règle spécifique rédigée et révisée par un humain, et la règle correspond ou ne correspond pas. Exécutez le même scanner sur le même code mille fois, et vous obtiendrez les mêmes résultats.
La répétabilité est ce qui rend les outils déterministes particulièrement adaptés à l'avant d'un pipeline (ils sont cohérents). Ils sont vérifiables, car ce sont des humains qui ont écrit les règles, et vous pouvez les exécuter à chaque commit sans vous soucier d'un coût trop élevé.
DAST également à l'extrémité déterministe du spectre. Il exécute un ensemble défini de simulations d'attaques contre une application en direct et renvoie des résultats cohérents et reproductibles. Il s'agit d'un contrôle de base utile, car il est plus rapide et moins coûteux que pentest IA pour l'instant). Cependant, comme tout outil déterministe, il ne détecte que ce pour quoi il a été testé.
Nous ne disons certainement pas que la sécurité déterministe, ou même simplement les résultats prévisibles, sont toujours meilleurs. Le revers de la médaille qui rend les outils déterministes fiables est également leur limite. Ils ne détectent que ce pour quoi ils ont une règle, de sorte que les nouveaux modèles d'attaque, les failles logiques nuancées et les vulnérabilités qui nécessitent une compréhension du contexte commercial échappent à la capacité de détection d'un scanner déterministe.
Les outils déterministes seuls ne suffisent pas non plus à déterminer quelles sont les questions les plus importantes dans un contexte donné. Certains outils déterministes incluent analyse d’accessibilité de base analyse d’accessibilité essentiellement un traçage statique du graphe d'appels) qui permet de confirmer si une fonction vulnérable est réellement appelée. Mais si nous voulons savoir si cette découverte est exploitable dans notre application spécifique, compte tenu de nos flux de données et de notre logique métier ? Eh bien, ce type analyse d’accessibilité de hiérarchisation nécessite une couche de raisonnement au-delà de la simple correspondance de modèles.
Outils de sécurité probabilistes
Grâce à l'essor des LLM, nous disposons désormais de nouveaux outils de sécurité basés sur l'IA, tels que les scanners IA, le triage automatisé et les tests d'intrusion agentifs, qui sont de nature probabiliste. Les outils probabilistes (ou outils « model-first ») ne fonctionnent pas selon des règles fixes. Au contraire, ils traitent le code comme du texte et l'analysent.
Comme elles ne sont pas soumises à des modèles fixes, les IA suivent une logique transversale, déduisent les intentions et peuvent mettre en évidence les vulnérabilités. Pour détecter les failles dans la logique métier, il faut comprendre ce que le code cherche à faire, et pas seulement ce qu'il dit littéralement. Les outils probabilistes excellent dans ce domaine, et l'IA ne cesse de s'améliorer. L'IA peut détecter de nouvelles classes de vulnérabilités et des bogues dépendants du contexte qui, auparavant, auraient nécessité l'intervention d'un expert humain.
Cependant, de par leur nature, ces modèles probabilistes sont imprévisibles et incohérents. Les résultats peuvent varier (et varieront probablement) d'une exécution à l'autre. Les LLM génèrent des résultats en prédisant le token suivant le plus probable sur la base des distributions de probabilité de leurs données d'entraînement, ce qui signifie qu'une même entrée peut produire des résultats différents en fonction de la température, du comportement d'échantillonnage et du contenu de la fenêtre contextuelle. Cette variation est acceptable, voire utile, pour les tests d'intrusion et la recherche de nouvelles vulnérabilités. Mais pour vos pipelines CI/CD, ce n'est pas le cas.
Il y a également un problème de coût lorsque vous essayez d'utiliser un modèle de raisonnement probabiliste comme scanner de code global à chaque commit. James Berthoty, de Latio, a effectué des tests informels qui ont montré qu'un modèle d'IA probabiliste passait 17 minutes et 155 000 jetons pour détecter un problème qu'Opengrep, un SAST déterministe, avait trouvé en 30 secondes. Pour chaque pull request dans une base de code active, ce compromis n'a pas de sens.
Pourquoi nous avons besoin des deux
Cependant, lorsque vous combinez des modèles déterministes et probabilistes, et que vous utilisez chaque méthode selon ses points forts, vous obtenez un pipeline de sécurité dont le tout est plus grand que la somme des parties. En pratique, vous souhaitez que l'analyse déterministe s'exécute à chaque validation, afin de détecter rapidement et de manière cohérente les classes de vulnérabilités connues, puis que le raisonnement IA prenne le relais pour gérer le triage et le contexte.
Ensemble, ils couvrent tout le spectre, depuis « ce que nous savons être dangereux » jusqu'à « ce que nous n'avons pas encore pensé à rechercher ». Nous nous attendons à ce que cette dernière catégorie prenne de l'ampleur. À mesure que l'IA s'intègre dans davantage de bases de code et que les pirates accèdent aux mêmes capacités de raisonnement, de nombreuses vulnérabilités ne feront pas encore l'objet de règles écrites. Nous aurons donc besoin d'outils capables de suivre le rythme.
Une autre raison pour laquelle vous avez besoin des deux outils est qu'ils couvrent les mêmes problèmes à différents niveaux. DAST pentest IA, par exemple, fonctionnent à différents niveaux d'un même problème. DAST dans les vérifications rapides et déterministes qui doivent être effectuées en continu. Vous devez savoir dès que possible si vous avez des ports ouverts ou des pages qui ne devraient pas être publics. pentest IA plus lent et coûte plus cher par exécution, mais il fonctionne à un niveau de profondeur fondamentalement différent. Un IDOR qui nécessite trois étapes authentifiées pour y accéder n'apparaîtra pas dans un DAST , mais il apparaîtra dans un bon pentest IA. Vous pouvez rapidement éliminer les éléments faciles avec DAST, puis pentest IA des éléments plus complexes.
Comment Aikido les deux
Nous avons développé Aikido du principe que l'analyse déterministe et l'analyse basée sur l'IA résolvent différents problèmes à différents niveaux de la pile. Dès le premier jour, nous avons choisi d'utiliser l'outil qui produisait les meilleurs résultats à chaque étape.
La base déterministe est Opengrep, le moteur d'analyse de code open source Aikido diriger et Aikido maintenir. En plus de cela, nous avons développé une analyse de contamination et des ensembles de règles suffisamment précis pour s'intégrer directement dans les pipelines CI/CD sans générer de bruit.
Ce que nous apprécions dans la sécurité probabiliste, c'est la capacité à donner du sens à ces données. Le raisonnement de l'IA repose sur une base déterministe et traite les problèmes que les règles ne peuvent pas cartographier. Dans Aikido, cela se fait grâce à AutoTriage, qui se situe en aval des SAST et prend des décisions concernant l'exploitabilité et la gravité qu'un moteur de règles ne peut pas prendre seul.
AutoTriage fonctionne en deux étapes. Tout d'abord, le moteur d'accessibilité Aikido filtre les faux positifs avant même qu'un LLM n'examine le code. Il vérifie si les chemins de code vulnérables sont réellement accessibles, s'il existe une désinfection entre la source et le collecteur, et si la dépendance affectée est utilisée en production ou uniquement dans les outils ou les pipelines. Cette première étape permet à elle seule de supprimer une partie importante des alertes par rapport à un SAST moyen.
Pour les cas complexes qui passent ce filtre, des modèles de raisonnement entrent en jeu et évaluent les flux de contrôle et de données dans leur contexte. En interne, nous avons constaté que cette approche identifie correctement environ deux fois plus de faux positifs dans les cas complexes que les approches sans raisonnement. Une injection SQL peut être rétrogradée en toute sécurité, car l'entrée provient d'une source en amont fiable. Une injection NoSQL sur un point de terminaison de connexion est reclassée comme critique, car le chemin d'attaque est trivial et l'impact est direct.
La raison pour laquelle cela fonctionne est le contrôle du contexte. Exécuter un LLM sur l'ensemble d'une base de code et lui demander de trouver des vulnérabilités produit des résultats incohérents. Le modèle perd le fil, élargit ses suppositions et votre taux de faux positifs augmente. L'approche Aikido réduit ce que l'IA voit avant même qu'elle ne raisonne. L'analyse de contamination trace le cheminement des données contrôlées par l'utilisateur dans l'application, et la reconnaissance des points finaux fournit au modèle la trace complète de la pile et l'intention du code. S'agit-il d'une API web ? D'un outil en ligne de commande ? Que doit-il faire ? Une fois ce contexte défini, l'IA ne fait plus de suppositions. Elle évalue une question spécifique et délimitée. C'est ainsi que vous obtenez la puissance de raisonnement de l'IA sans renoncer à la reproductibilité.
Enfin, comme les modèles d'IA sont bien adaptés à la recherche de modèles d'attaques complexes et basés sur la logique, nous les avons trouvés très efficaces pour les tests d'intrusion. Aikido est pentest IA applique le raisonnement probabiliste à l'application en direct. Les agents effectuent les tests en quelques heures plutôt qu'en plusieurs semaines et détectent régulièrement des failles logiques plus profondes, notamment des IDOR, des contournements d'authentification et des falsifications de signatures électroniques, dont certaines échappent même aux testeurs humains. Et désormais, avec Aikido , les agents peuvent tester chaque version.
Pour les vrais positifs confirmés, issus SAST du pentesting, Aikido utilise Aikido l'IA pour raisonner sur la solution. AutoFix génère un correctif ciblé et ouvre une pull request, une autre fonctionnalité de l'IA qui nécessite du raisonnement et du contexte pour fonctionner.
Dans Aikido, le déterminisme gère la couverture prévisible à grande échelle. L'IA gère les décisions que les règles ne peuvent pas prendre.
Quelle est la suite ?
La sécurité nécessite à la fois une fiabilité déterministe et la créativité de l'IA. Le déterminisme vous offre des résultats cohérents, vérifiables et fiables à grande échelle, tandis que l'IA vous apporte la profondeur, la créativité, la persévérance et le raisonnement nécessaires pour éliminer les faux positifs, réduire le bruit et détecter les vulnérabilités inhabituelles. Les outils probabilistes et déterministes ont tous deux leurs limites, mais le véritable problème survient lorsqu'ils sont utilisés à mauvais escient. Les choses vont mal tourner si vous utilisez un moteur de raisonnement pour une tâche qui nécessite un outil de reconnaissance de formes (ou vice versa).
La tendance générale est plus claire que n'importe quelle catégorie de produits individuelle. Les outils déterministes s'améliorent grâce à l'intelligence artificielle qui les surmonte désormais, gérant la hiérarchisation, le triage et les corrections que les règles seules ne pouvaient pas effectuer. Les outils probabilistes s'améliorent dans la recherche de failles logiques complexes et de nouvelles voies d'attaque, et avec le temps, ils deviendront également plus rentables. Mais pour les vérifications de base continues, l'économie du scan déterministe ne disparaîtra pas. Vous voulez quelque chose de rapide, cohérent et bon marché qui fonctionne à chaque commit, et cela reste un outil de correspondance de modèles.
Les équipes qui mettent en place la posture de sécurité la plus durable sont celles qui utilisent à la fois des outils déterministes et probabilistes dans le bon ordre et aux bons endroits, sans miser sur un seul d'entre eux.
