Les outils de sécurité déterministes sont, à ce stade, devenus une composante si courante de la sécurité que, pendant longtemps, nous n'avons pas remis en question les alternatives. Avec l'IA qui devient un élément central de la sécurité grâce aux modèles probabilistes, il est temps de revisiter le déterminisme et de clarifier son utilité. Sinon, pourquoi ne devrions-nous pas simplement tout remplacer par l'IA ?
En bref, nous avons besoin du déterminisme pour sa prévisibilité et son efficacité. Les outils déterministes comme le SAST donnent le même résultat à chaque fois que vous les exécutez sur la même chose, et ce, de manière efficace. Ils sont donc utiles dans une pipeline CI/CD, défendables lors d'un audit de conformité, et constituent une base pour tout le reste. L'IA est excellente pour le raisonnement logique, mais, en raison de son imprévisibilité, elle est préférable pour les cas où vous n'avez pas besoin de résultats reproductibles.
À mesure que de plus en plus d'outils probabilistes apparaissent sur le marché, nous voulons expliquer comment le déterminisme crée des pratiques de sécurité durables, comment l'IA offre de nouvelles possibilités et comment les deux peuvent être combinés pour un impact maximal.
Quand les outils de sécurité doivent être prévisibles
Certaines tâches de sécurité exigent avant tout de la cohérence et de l'auditabilité. Nous constatons ce besoin de prévisibilité à travers l'ensemble du flux de travail de sécurité.
Lorsqu'un scanner signale une découverte, un développeur doit lui faire suffisamment confiance pour agir à 23h. Lorsqu'une pipeline CI/CD bloque un déploiement, ce blocage doit résister à un examen minutieux. Dans une pipeline, votre scanner s'exécute sur chaque commit ou PR. S'il signale 12 problèmes le lundi et 9 le mardi pour un code identique, ce n'est pas bon. 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 la sortie du scan comme une porte significative sur les merges.
De même, les tests de régression dépendent de la reproductibilité. Lorsque vous corrigez une vulnérabilité et relancez un scan, un résultat propre doit signifier qu'elle est réellement corrigée, et non que le modèle l'a manquée cette fois-ci. La détection de référence (baseline) et de dérive (drift) en dépend également, car elles doivent savoir si une nouvelle découverte reflète un changement réel dans la base de code ou simplement une variance du scanner.
La prévisibilité est également nécessaire pour la conformité. Les auditeurs exigent 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 exécution ne peut pas offrir cela.
Le coût pratique de l'imprévisibilité en matière de sécurité dégrade lentement la confiance dans les outils eux-mêmes, jusqu'à ce que personne ne prenne les résultats au sérieux. La reproductibilité, l'auditabilité et de 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
Le SAST est un outil de sécurité déterministe par excellence qui recherche les schémas et vulnérabilités connus. Pensez aux secrets codés en dur, aux CVE connues, aux vulnérabilités de dépendances et aux schémas d'injection. Il fonctionne en analysant le code pour en faire un arbre syntaxique abstrait et en suivant la manière dont les données contrôlées par l'utilisateur se déplacent dans l'application, des points d'entrée à leur utilisation. Un résultat remonte à une règle spécifique qu'un humain a écrite et révisée, et la règle correspond ou non. 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 bien adaptés au début d'un pipeline (ils sont cohérents). Ils sont auditables parce qu'un humain a écrit les règles, et vous pouvez les exécuter sur chaque commit sans craindre que cela ne devienne trop coûteux.
Le DAST se situe également à l'extrémité déterministe du spectre. Il exécute un ensemble défini de simulations d’attaque contre une application en direct et renvoie des résultats cohérents et reproductibles. C'est un contrôle de base utile, car il est plus rapide et moins cher que le pentest IA (pour l'instant). Cependant, comme tout outil déterministe, il ne trouve que ce pour quoi il a un test.
Nous ne disons certainement pas que la sécurité déterministe, ou même simplement un résultat prévisible, est toujours meilleure. Le revers de la médaille de ce qui rend les outils déterministes fiables est aussi leur limite. Ils ne trouvent que ce pour quoi ils ont une règle, de sorte que les nouveaux schémas d'attaque, les failles logiques nuancées et les vulnérabilités qui nécessitent une compréhension du contexte métier échappent à ce qu'un scanner déterministe peut détecter.
Les outils déterministes seuls ne pourront pas non plus vous dire quels problèmes sont les plus importants dans leur contexte. Certains outils déterministes incluent une analyse d’accessibilité de base (essentiellement un traçage statique du graphe d'appels) qui peut confirmer si une fonction vulnérable est réellement appelée. Mais si nous voulons savoir si ce résultat 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 d'analyse d’accessibilité et de priorisation nécessite une couche de raisonnement supplémentaire au-delà de la simple correspondance de motifs.
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 le pentesting agentique, qui sont de nature probabiliste. Les outils probabilistes (ou outils basés sur des modèles) ne fonctionnent pas sur des règles fixes. Au lieu de cela, ils traitent le code comme du texte et raisonnent dessus.
Parce qu'ils ne sont pas liés à des schémas fixes, une IA suit la logique à travers les fonctions, déduit l'intention et peut révéler des vulnérabilités. Les failles de logique métier nécessitent de comprendre ce que le code tente de faire, et pas seulement ce qu'il dit littéralement. Les outils probabilistes excellent dans ce domaine, et l'IA continue de s'améliorer. L'IA peut trouver de nouvelles classes de vulnérabilités et des bugs dépendants du contexte qui auraient auparavant nécessité une revue humaine experte pour être détectés.
Cependant, par leur nature, ces modèles probabilistes sont imprévisibles et incohérents. Les sorties peuvent (et vont probablement) varier entre les exécutions. Les LLM génèrent des sorties en prédisant le prochain token le plus probable basé sur les distributions de probabilité de leurs données d'entraînement, ce qui signifie que la même entrée peut produire des sorties différentes en fonction de la température, du comportement d'échantillonnage et de ce qui se trouve dans la fenêtre de contexte. Cette variation est acceptable, voire utile, pour le pentesting et la découverte de nouvelles vulnérabilités. Mais pour vos pipelines CI/CD, ce n'est pas le cas.
Il y a aussi un problème de coût lorsque vous essayez d'utiliser un modèle de raisonnement probabiliste comme scanner de code généralisé sur chaque commit. James Berthoty chez Latio a effectué des tests informels qui ont montré qu'un modèle d'IA probabiliste passait 17 minutes et 155 000 tokens à révéler un problème qu'Opengrep, un moteur SAST déterministe, a trouvé en 30 secondes. Sur chaque pull request dans une base de code active, cet échange 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 forces, vous obtenez un pipeline de sécurité dont le tout est plus grand que la somme de ses parties. En pratique, vous voulez un scanning déterministe exécuté sur chaque commit, détectant rapidement et de manière cohérente les classes de vulnérabilités connues, puis le raisonnement de l'IA se superpose, gérant le triage et le contexte.
Ensemble, ils couvrent le spectre allant de « ce que nous savons être dangereux » à « ce que nous n'avons pas encore pensé à chercher ». Nous nous attendons à ce que cette dernière catégorie se développe. À mesure que l'IA s'intègre dans davantage de bases de code et que les attaquants accèdent aux mêmes capacités de raisonnement, de nombreuses vulnérabilités n'auront pas encore de règle écrite pour elles, 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. Le DAST et le pentest IA, par exemple, fonctionnent à différentes couches du même problème. Le DAST excelle dans les vérifications rapides et déterministes qui doivent s'exécuter en continu. Vous devez savoir dès que possible si vous avez des ports ouverts évidents ou des pages qui ne devraient pas être publiques. Le pentest IA est plus lent et coûte plus cher par exécution, mais il opère à une profondeur fondamentalement différente. Un IDOR qui nécessite trois étapes authentifiées pour être atteint n'apparaîtra pas dans un scan DAST, mais il apparaîtra dans un bon pentest IA. Vous pouvez régler rapidement les problèmes simples avec le DAST, puis le pentest IA s'occupe des problèmes plus complexes.
Comment Aikido utilise les deux
Nous avons construit Aikido sur la prémisse que le scanning déterministe et celui basé sur l'IA résolvent des problèmes différents à différentes couches de la stack. Depuis le premier jour, nous avons choisi d'utiliser l'outil qui produisait les meilleurs résultats à chaque étape.
La fondation déterministe est Opengrep, le moteur d'analyse de code open-source qu'Aikido aide à diriger et à maintenir. En plus de cela, nous avons développé l'analyse de taint et des ensembles de règles (rulesets) suffisamment précis pour s'intégrer directement dans les pipelines CI/CD sans générer de bruit.
Là où nous apprécions la sécurité probabiliste, c'est pour donner du sens à ces données. Le raisonnement de l'IA se superpose à la fondation déterministe, gérant les problèmes auxquels les règles ne peuvent pas correspondre. Dans Aikido, cela se produit via AutoTriage, qui se situe en aval des scans SAST et prend des décisions sur l'exploitabilité et la gravité qu'un moteur de règles ne peut pas prendre seul.
AutoTriage fonctionne en deux étapes. Premièrement, le moteur d'analyse d’accessibilité d'Aikido filtre les faux positifs avant qu'un LLM n'examine le code. Il vérifie si les chemins de code vulnérables sont réellement accessibles, si une sanitization existe entre la source et le sink, et si la dépendance affectée est utilisée en production ou uniquement dans les outils ou les pipelines. Cette première étape seule supprime une partie significative des alertes par rapport à un scanner SAST moyen.
Pour les cas complexes qui survivent à ce filtre, les modèles de raisonnement interviennent 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 sur les cas complexes par rapport aux approches sans raisonnement. Un résultat d'injection SQL pourrait être rétrogradé en toute sécurité car l'entrée provient d'une source amont fiable. Une injection NoSQL sur un endpoint de connexion est élevée au rang 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 une base de code entière et lui demander de trouver des vulnérabilités est ce qui produit des résultats incohérents. Le modèle perd le fil, élargit ses suppositions, et votre taux de faux positifs augmente. L'approche d'Aikido restreint ce que l'IA voit avant même qu'elle ne raisonne. L'analyse de taint (taint analysis) retrace la manière dont les données contrôlées par l'utilisateur se déplacent dans l'application, et la connaissance des endpoints (endpoint-awareness) donne au modèle la trace de pile complète (full stack trace) et l'intention du code. S'agit-il d'une API web ? D'un outil en ligne de commande ? Que doit-il faire ? Avec ce contexte verrouillé, l'IA ne devine pas. Elle évalue une question spécifique et délimitée. C'est ainsi que vous obtenez la puissance de raisonnement de l'IA sans sacrifier la reproductibilité.
Enfin, parce que les modèles d'IA sont bien adaptés pour trouver des schémas d'attaque complexes et basés sur la logique, nous les avons trouvés très efficaces pour le pentesting. Aikido Attack est un pentest IA qui met le raisonnement probabiliste au service de l'application en direct. Les agents effectuent des tests en quelques heures plutôt qu'en semaines et trouvent régulièrement des failles logiques plus profondes, y compris des IDORs, des contournements d'authentification (auth bypasses) et des falsifications de signature électronique, dont certaines sont même manquées par les testeurs humains. Et maintenant, avec Aikido Infinite, les agents peuvent pentester chaque version.
Pour les vrais positifs confirmés, issus du SAST ou du pentesting, Aikido utilise également l'IA pour raisonner sur la solution. AutoFix génère un correctif ciblé et ouvre une pull request, une autre capacité de l'IA qui nécessite un raisonnement et un contexte.
Chez Aikido, le déterminisme gère une couverture prévisible à l'é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 offre des résultats cohérents, auditables et fiables à grande échelle, tandis que l'IA 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écouvrir les vulnérabilités inhabituelles. Les outils probabilistes et déterministes ont tous deux des limites, mais le vrai problème survient lorsqu'ils sont utilisés au mauvais endroit. Les choses vont se gâter si vous placez un moteur de raisonnement là où un détecteur de motifs est nécessaire (ou vice versa).
L'orientation générale est plus claire que n'importe quelle catégorie de produit individuelle. Les outils déterministes s'améliorent car l'IA les chapeaute désormais, gérant la priorisation, le triage et les correctifs que les règles seules ne pouvaient pas effectuer. Les outils probabilistes s'améliorent dans la détection des failles logiques complexes et des chemins d'attaque inédits, et avec le temps, ils deviendront également plus rentables. Mais pour les vérifications de base continues, l'économie du scanning déterministe ne disparaîtra pas. Vous voulez quelque chose de rapide, cohérent et bon marché s'exécutant à chaque commit, et cela reste un détecteur de motifs.
Les équipes qui construisent la posture de sécurité la plus robuste sont celles qui utilisent des outils déterministes et probabilistes dans le bon ordre et aux bons endroits, sans miser sur un seul.
