La détection des vulnérabilités par l’IA d’AWS repère les bugs, mais les faux positifs révèlent un déficit de confiance

AWS a testé 12 modèles d’IA généralistes et constaté un conflit marqué : ils détectaient la plupart des vulnérabilités, mais qualifiaient aussi fréquemment du code sûr de dangereux.

Le nouveau Deception Benchmark soumet les affirmations d’AWS sur la détection des vulnérabilités par l’IA à une épreuve plus exigeante qu’un autre classement de détection de bugs. Il demande si un modèle peut reconnaître qu’un code suspect est en réalité protégé par une mesure de mitigation fonctionnelle. Avec des prompts directs, les modèles testés ont signalé entre 41 % et 99 % des échantillons sûrs comme vulnérables.

Ce résultat déplace le débat autour des outils de sécurité basés sur l’IA. Repérer des motifs suspects ne suffit pas lorsque chaque alerte consomme du temps d’ingénierie. La véritable compétition oppose désormais la reconnaissance rapide de motifs à la vérification fondée sur des preuves, et les équipes de sécurité en paient la différence.

AWS a publié le benchmark le 9 septembre 2026, avec 14 822 échantillons couvrant 16 langages de programmation et plus de 70 catégories de Common Weakness Enumeration. Aucune configuration testée n’a atteint le minimum annoncé par AWS, consistant à maintenir les taux de faux positifs et de faux négatifs sous les 10 %.

AWS a créé un benchmark où le code sûr paraît dangereux

Le benchmark évalue si un modèle comprend l’exploitabilité, et non s’il reconnaît un schéma de vulnérabilité familier.

De nombreuses évaluations de sécurité partent d’un logiciel vulnérable et demandent à un système d’IA d’identifier ou d’exploiter la faille. Cette approche révèle des capacités offensives utiles, mais donne une image incomplète des performances défensives. En production, un réviseur doit aussi pouvoir écarter un code qui ressemble à une vulnérabilité sans créer de véritable chemin d’attaque.

AWS a conçu Deception Benchmark autour de cette distinction. Ses échantillons sûrs contiennent des frameworks réalistes, des flux de données à l’apparence dangereuse et des signaux de sécurité reconnaissables. Une mitigation subtile ferme le chemin d’exploitation, laissant au modèle la tâche de déterminer si la protection fonctionne réellement.

Un exemple décrit dans la publication du benchmark concerne un endpoint Flask qui accepte une entrée utilisateur et interroge une base de données. Le schéma environnant ressemble à une injection SQL. Toutefois, les requêtes paramétrées empêchent l’entrée de devenir une syntaxe de requête exécutable.

Un modèle qui s’arrête après avoir reconnu le schéma signalera une vulnérabilité. Un modèle qui suit l’ensemble du flux de données devrait classer l’échantillon comme sûr. Cette différence détermine si la sortie devient une preuve utile ou une alerte supplémentaire nécessitant une enquête manuelle.

Le benchmark comprend 6 988 défis au niveau du code. Ils présentent des variantes vulnérables et sûres qui diffèrent par une correction subtile. Les deux versions peuvent sembler suspectes, mais une seule reste exploitable.

2 707 autres défis ajoutent le contexte de déploiement. Le code source peut sembler vulnérable alors qu’un contrôle d’infrastructure bloque l’attaque. Les exemples incluent une Kubernetes Network Policy empêchant une falsification de requête côté serveur ou une limite d’identité empêchant une escalade de privilèges.

Ces cas conditionnés par l’environnement comptent, car la sécurité en entreprise s’arrête rarement à un seul fichier. L’exploitabilité dépend de la configuration, de l’accessibilité réseau, des autorisations, du comportement à l’exécution et des contrôles compensatoires. Un scanner qui ignore ces conditions peut décrire une attaque plausible qui ne peut pas se produire dans l’environnement déployé.

AWS affirme que chaque échantillon a été créé pour le benchmark et ancré dans des schémas de sécurité réels. L’entreprise a utilisé une boucle de développement adversarial qui générait des défis, les testait sur des modèles de pointe, renforçait les cas faciles et répétait le processus.

Cette méthode rend le jeu de données intentionnellement difficile. Elle signifie aussi que les résultats ne doivent pas être considérés comme un taux d’échec représentatif pour chaque dépôt de code source. Le benchmark sélectionne des cas conçus pour révéler un raisonnement superficiel, et non un échantillon aléatoire de revues de code quotidiennes.

Sa valeur vient de l’isolement d’une capacité spécifique. Un modèle peut-il suivre une chaîne d’exploitation assez loin pour distinguer une véritable faiblesse d’un leurre convaincant ? Cette question se trouve au cœur d’une détection des vulnérabilités par l’IA d’AWS digne de confiance.

Le dépôt public du benchmark contient les 14 822 échantillons. AWS en évalue 9 695 et en laisse 5 127 non notés. Ces échantillons exclus incluent des cas contestés ou volontairement ambigus.

Les étiquettes ne sont pas incluses publiquement. Les participants doivent soumettre des prédictions pour chaque échantillon, y compris des explications, avant qu’AWS ne renvoie des résultats de précision et de taux d’erreur. Cette approche vise à limiter la mémorisation et l’ajustement spécifique au benchmark.

AWS affirme également que des réviseurs indépendants ont examiné les étiquettes à plusieurs reprises. Les échantillons contestés ont été déplacés vers le pool non noté plutôt que de recevoir des étiquettes corrigées. Selon l’entreprise, un examen humain de 100 échantillons notés sélectionnés aléatoirement n’a relevé aucune erreur.

Cela ne place pas le jeu de données au-delà de toute critique. Des chercheurs indépendants doivent encore examiner sa construction, l’équilibre des catégories, le processus de notation et le transfert au monde réel. Toutefois, cette publication donne aux équipes externes une cible commune pour comparer les systèmes dans les mêmes conditions adversariales.

Les résultats de la détection des vulnérabilités par l’IA d’AWS révèlent deux mauvais choix

Les prompts directs produisent trop de fausses alertes, tandis que des exigences de preuve plus strictes amènent les modèles à manquer davantage de vraies vulnérabilités.

AWS a évalué 12 modèles de cinq fournisseurs à l’aide de deux stratégies de prompting. Le prompting direct demandait à chaque modèle de classer le code comme vulnérable ou sûr. Le prompting avec preuve d’exploitation exigeait qu’il construise une exploitation concrète avant de déclarer une vulnérabilité.

Le benchmark distingue deux types d’erreurs, car elles créent des défaillances opérationnelles différentes. Un faux positif qualifie un code sûr de vulnérable. Un faux négatif classe une véritable vulnérabilité comme sûre.

Avec les prompts directs, les modèles favorisaient généralement la sensibilité. Selon AWS, ils ont détecté jusqu’à 95 % des véritables vulnérabilités. Toutefois, ils ont également signalé entre 41 % et 99 % du code sûr comme vulnérable.

Ce biais peut donner l’impression qu’un modèle est actif et prudent. C’est aussi un moyen facile de protéger le rappel, qui mesure la part des vulnérabilités réelles détectées. Un système qui qualifie tout de vulnérable ne manquera jamais une vulnérabilité, mais noiera les utilisateurs sous des alertes inutiles.

Mistral Large illustre ce mode de défaillance. Sa configuration avec prompt direct a enregistré un taux de faux positifs de 99 % et un taux de faux négatifs de 0 %. Elle a détecté les cas vulnérables en traitant pratiquement tous les cas sûrs comme dangereux.

Plusieurs autres configurations directes se sont comportées de manière similaire. GPT-5.6 Sol a enregistré un taux de faux positifs de 92,5 % et un taux de faux négatifs de 0,9 %. Claude Haiku 4.5 a atteint un taux de faux positifs de 92,1 % sans enregistrer de faux négatifs.

Nova 2 Lite d’Amazon n’a pas fait exception. Avec un prompting direct, AWS a signalé un taux de faux positifs de 89,2 % et un taux de faux négatifs de 1,2 %. L’inclusion du modèle d’Amazon aide à faire de cette publication davantage qu’une comparaison visant les fournisseurs externes.

Claude Opus 5 a produit le meilleur équilibre avec prompt direct parmi les systèmes listés. Il a atteint une précision de 77,3 %, avec un taux de faux positifs de 41,5 % et un taux de faux négatifs de 5,2 %. Même ce résultat restait bien au-delà du seuil de production annoncé par AWS.

La précision seule masque ces différences. Le benchmark est approximativement équilibré entre les cas sûrs et vulnérables, de sorte qu’un classifieur répondant toujours « vulnérable » peut obtenir un score proche de 50 %. Sa précision apparente cache le fait que chaque échantillon sûr devient une alerte.

AWS a donc fixé ce qu’elle a qualifié de seuil minimum généreux. Une configuration prête pour la production devrait maintenir les deux taux d’erreur sous les 10 %. Aucune des configurations testées n’a atteint cet objectif.

Les résultats directs montrent pourquoi la détection des vulnérabilités par l’IA ne peut pas être évaluée uniquement par le rappel. Détecter presque chaque faille réelle paraît rassurant jusqu’à ce qu’une équipe découvre que la plupart des codes sûrs ont aussi déclenché des avertissements.

Il ne s’agit pas d’un simple problème esthétique de qualité. Chaque fausse alerte entre dans un flux de travail. Quelqu’un doit inspecter le code, reproduire le chemin allégué, vérifier la configuration, consulter l’équipe responsable et documenter pourquoi la conclusion peut être clôturée.

À l’échelle de l’entreprise, ce coût d’examen peut effacer l’avantage de vitesse promis par l’automatisation. Il peut aussi créer une fatigue face aux alertes, les ingénieurs commençant à ignorer les signalements parce que trop d’alertes précédentes étaient erronées.

La conséquence pour la sécurité est inconfortable. Un taux élevé de faux positifs peut indirectement accroître le risque, même lorsque le modèle présente un excellent rappel. L’alerte importante doit rivaliser pour capter l’attention avec des dizaines d’erreurs convaincantes.

Des travaux universitaires antérieurs ont identifié le même schéma. Une évaluation de sécurité de 2024 a testé huit modèles de langage sur 228 scénarios de code et signalé des taux élevés de faux positifs. Les modèles continuaient parfois à signaler des vulnérabilités après que le code testé eut été corrigé.

Cette étude a également relevé des réponses non déterministes et un raisonnement fragile face à de simples modifications du code. La publication plus vaste d’AWS étend cette préoccupation à davantage de langages, de catégories de faiblesses, de modèles et d’exemples sûrs construits de manière adversariale.

La preuve d’exploitation réduit le bruit mais crée un nouvel angle mort

Exiger des preuves améliore la discipline, mais les modèles testés ont souvent obtenu cette précision en négligeant de véritables vulnérabilités.

Le prompting avec preuve d’exploitation demande à un modèle d’aller au-delà du soupçon. Avant de qualifier un code de vulnérable, il doit décrire un chemin concret qu’un attaquant pourrait emprunter. Cela modifie le seuil de décision, de « cela paraît dangereux » à « je peux expliquer comment l’attaque fonctionne ».

AWS a signalé que cette stratégie réduisait les taux de faux positifs de 17 à 74 points de pourcentage. Il s’agit d’une amélioration significative. Elle a également augmenté les taux de faux négatifs, qui allaient de 7 % à 44 % avec l’approche plus stricte.

GPT-5.4 offre l’exemple le plus clair de ce compromis. Sa configuration directe produisait un taux de faux positifs de 81 % et un taux de faux négatifs de 1,5 %. Le prompting avec preuve d’exploitation a fait tomber les faux positifs à 10,1 %, mais les faux négatifs ont grimpé à 33,6 %.

Llama 3.3 70B a suivi un schéma similaire. Son taux de faux positifs est passé de 84,2 % à 10,2 %. Son taux de faux négatifs est passé de 1,1 % à 44,2 %, ce qui signifie que la configuration a manqué presque la moitié des vulnérabilités notées.

Claude Opus 5 a enregistré la précision globale la plus élevée, soit 79,3 %, avec le prompting avec preuve d’exploitation. Pourtant, son taux de faux positifs de 24,9 % et son taux de faux négatifs de 16,8 % restaient au-dessus du seuil d’AWS des deux côtés.

Les résultats ne signifient pas que le prompting avec preuve d’exploitation est inefficace. Ils montrent que le prompting modifie les types d’erreurs qu’un modèle commet. Les responsables de la sécurité doivent décider si leur flux de travail peut absorber davantage de fausses alertes, davantage de failles manquées, ou une combinaison soigneusement mesurée.

Cette décision dépend de l’application. L’examen d’un service d’authentification exposé à Internet devrait tolérer moins de vulnérabilités manquées. Un dépôt interne à faible risque pourrait privilégier la précision afin d’éviter d’épuiser une petite équipe d’ingénierie.

La gravité devrait aussi influencer le seuil. Un système pourrait orienter les conclusions critiques à forte confiance vers une revue humaine immédiate tout en traitant les avertissements plus faibles par une validation de priorité inférieure. Un seuil de classification mondial ne conviendra probablement pas à toutes les bases de code.

C’est ici que la conception en un seul tour du benchmark prend toute son importance. AWS a délibérément supprimé l’échafaudage agentique, les outils externes et les boucles de validation répétées. L’objectif était de mesurer le raisonnement intrinsèque du modèle de base plutôt qu’un produit commercial de sécurité complet.

Par conséquent, les résultats n’établissent pas que chaque scanner agentique présente les mêmes taux d’échec. Un produit peut associer des modèles de langage à l’analyse statique, aux tests dynamiques, au contexte du dépôt, aux vérifications de politiques et à la validation déterministe des exploits. Ces composants peuvent modifier le point de fonctionnement.

AWS reconnaît explicitement cette distinction. Son benchmark accepte séparément les soumissions agentiques et les résultats des modèles en un seul tour. Cette séparation évite qu’un système assisté par outils soit présenté comme équivalent à un appel de modèle non assisté.

Cette réserve ne rend pas la référence de base non pertinente. Chaque flux de travail agentique hérite de certaines limites de son modèle sous-jacent. Répéter un jugement faible peut produire une explication plus élaborée sans apporter le fait technique manquant.

Un système a besoin d’une source fiable de nouvelles preuves. Il peut exécuter un test, suivre des données à travers plusieurs fichiers, inspecter une politique de déploiement ou vérifier si un endpoint est accessible. De multiples appels de modèle ne garantissent pas à eux seuls une compréhension plus approfondie.

La tâche la plus difficile consiste à prouver la sûreté. Les tests offensifs fournissent souvent un résultat visible, car un exploit réussit ou échoue. Une tentative échouée ne prouve pas qu’aucun autre exploit n’existe ; l’absence de succès demeure donc difficile à interpréter.

Les exemples d’AWS conditionnés par l’environnement précisent ce problème. Un modèle doit raisonner à la fois sur le code et l’infrastructure, puis reconnaître qu’une mesure d’atténuation bloque la voie qu’il avait d’abord repérée. AWS affirme que les modèles identifiaient fréquemment le schéma risqué, mais ignoraient le contrôle adjacent.

Ce comportement rappelle un biais humain courant lors des revues de sécurité. Une fois qu’un examinateur reconnaît une forme de vulnérabilité familière, la confirmation peut arriver plus vite que l’infirmation. Les modèles de langage amplifient le problème, car la reconnaissance de motifs est centrale dans leur manière de générer des réponses.

Pour les acheteurs, la leçon pratique est précise. Demandez si un produit de sécurité IA vérifie l’exploitabilité et comment il mesure les deux taux d’erreur. Un chiffre de rappel sans données sur les faux positifs révèle peu de chose sur la charge de travail créée par le produit.

Les propres systèmes de sécurité d’AWS montrent pourquoi l’architecture compte

Les affirmations d’AWS en production reposent sur des agents en couches, des vérifications déterministes et une approbation humaine, et non sur un modèle non assisté qui décide si le code est sûr.

Le benchmark est arrivé quelques mois après qu’AWS a décrit deux systèmes de sécurité agentiques. Ces divulgations antérieures apportent un contrepoint important, car elles montrent comment Amazon tente de gérer les limites désormais mesurées directement.

RuleForge génère des règles de détection à partir d’exemples d’exploits accessibles au public. AWS affirme que le système a augmenté de 336 % la productivité de production de règles par rapport à un processus manuel au cours des quatre derniers mois de 2025.

Son architecture répartit la tâche entre des étapes spécialisées. Un composant ingère et priorise les informations sur les vulnérabilités. Des agents de génération proposent plusieurs règles de détection. Un juge distinct les évalue, des tests synthétiques les mettent à l’épreuve, et des données de trafic prennent en charge une validation supplémentaire.

Un ingénieur en sécurité reste le dernier point d’approbation. Ce rôle humain est important, car RuleForge ne considère pas la confiance d’un modèle IA comme une preuve suffisante pour le déploiement.

AWS a indiqué que le modèle de génération évaluait presque toutes les règles très favorablement lorsqu’on lui demandait de juger son propre travail. Selon l’analyse de RuleForge de l’entreprise, confier l’évaluation à un modèle distinct a réduit les faux positifs de 67 % tout en préservant le nombre de détections de vrais positifs.

Le juge a également reçu des questions spécifiques au domaine. Au lieu de demander si une règle semblait correcte, le système demandait si elle risquait de manquer des requêtes malveillantes. Il vérifiait aussi si une règle capturait le mécanisme de la vulnérabilité ou seulement une caractéristique de surface corrélée.

Cette distinction reflète Deception Benchmark. Une expression permissive peut correspondre à des entrées contenant une apostrophe, mais la correspondance avec ce caractère ne prouve pas une injection SQL. La règle doit distinguer le comportement d’exploitation du trafic bénin partageant la même caractéristique.

AWS Security Agent utilise une stratégie similaire pour les tests d’intrusion automatisés. Des agents spécialisés explorent les applications et produisent des conclusions candidates, tandis que des validateurs exigent des preuves d’exploitation.

AWS a indiqué que son système avait atteint un taux de réussite d’attaque de 92,5 % sur CVE Bench v2.0 lorsqu’il recevait des instructions de capture-the-flag et les retours du correcteur. Ce taux tombait à 80 % sans ces aides et atteignait 65 % avec un modèle dont la date limite d’entraînement précédait le benchmark.

Ces chiffres mesurent le succès offensif, et non la précision défensive. CVE Bench contient des applications vulnérables et vérifie si les agents peuvent exploiter des failles connues. Il ne répond pas à la question de savoir à quelle fréquence le système accuserait du code sûr.

Néanmoins, l’architecture agentique illustre une réponse crédible à la faiblesse du benchmark. Les conclusions candidates sont soumises à des vérifications déterministes et fondées sur des modèles, tandis que les rapports incluent des preuves d’exploitation et un contexte technique.

Cela ne crée une contradiction apparente que si la « détection de vulnérabilités par IA » est traitée comme une technique unique. Le benchmark du modèle de base expose la faiblesse du jugement en un seul passage. Les systèmes de production d’AWS revendiquent leur valeur grâce à des flux de travail qui recueillent des preuves et contraignent ce jugement.

La comparaison étaye une conclusion plus précise. Les modèles généralistes sont des composants utiles pour l’automatisation de la sécurité, mais c’est le système qui les entoure qui détermine si leur sortie mérite une confiance opérationnelle.

Un fournisseur ne peut pas combler l’écart en apposant une étiquette d’agent sur des invites répétées. Les questions pertinentes portent sur les outils, les preuves, le calibrage, la gestion des échecs et la supervision humaine. Les acheteurs devraient demander ce qui change entre le premier soupçon et la conclusion finale.

Le produit exécute-t-il le chemin prétendument vulnérable ? Inspecte-t-il les contrôles d’infrastructure ? Peut-il suivre les données au-delà des frontières du dépôt ? Compare-t-il les résultats avec des analyseurs déterministes ? Un examinateur peut-il voir pourquoi la conclusion a survécu à la validation ?

Les équipes ont également besoin d’un contexte durable pendant l’investigation. Les notes d’architecture, les exceptions antérieures, les modèles de menace et les décisions de remédiation sont souvent répartis entre documents et conversations. Une base de connaissances d’ingénierie consultable peut aider les examinateurs à retrouver ce contexte, même si elle ne remplace pas la validation technique.

Les évaluations d’approvisionnement devraient distinguer trois couches. La première est le modèle sous-jacent, pour lequel Deception Benchmark offre une référence commune. La deuxième est l’architecture de validation, qui détermine comment le système recueille des preuves supplémentaires. La troisième est le processus opérationnel, y compris la responsabilité de la revue et le risque acceptable.

Un produit peut être performant à une couche et médiocre à une autre. Un modèle capable peut être affaibli par des invites vagues et un contexte manquant. Un modèle moins capable peut devenir plus utile lorsque des outils étroits et une validation stricte contraignent ses décisions.

Les divulgations d’AWS contiennent également des résultats rapportés par l’entreprise, et non des audits indépendants de performances en production. L’affirmation d’une productivité accrue de 336 % et la réduction de 67 % des faux positifs décrivent RuleForge dans le cadre de l’évaluation d’Amazon. Elles ne doivent pas être généralisées à des dépôts ou produits non liés.

Cette incertitude renforce l’intérêt d’un benchmark public. Les fournisseurs peuvent soumettre leurs systèmes complets à Deception Benchmark et communiquer des résultats agentiques distincts. Les clients peuvent alors comparer des affirmations formulées dans le cadre d’une tâche commune plutôt que de s’appuyer sur des études de cas incompatibles.

Les faux positifs transforment la vitesse de l’IA en travail humain

Le risque métier n’est pas que l’IA ne trouve rien ; c’est que des erreurs plausibles monopolisent les personnes nécessaires pour confirmer les véritables conclusions.

Les outils de sécurité luttent depuis longtemps contre les faux positifs. Les tests statiques de sécurité des applications analysent traditionnellement le code source à la recherche de flux ou de constructions dangereux, souvent sans contexte d’exécution complet. L’IA promet un meilleur raisonnement sémantique, mais les résultats d’AWS montrent que les motifs reconnaissables continuent d’exercer une forte attraction.

Imaginez une équipe de développement recevant un avertissement urgent d’injection SQL. Un ingénieur interrompt son travail planifié, trouve le responsable concerné, examine le chemin de requête et confirme que le paramétrage des requêtes empêche l’injection. L’alerte nécessite ensuite des notes de clôture afin qu’elle ne se rouvre pas lors du prochain scan.

Une erreur semble gérable. Des milliers de dépôts et des scans fréquents modifient le calcul. Un taux élevé de faux positifs transforme la détection automatisée en file récurrente de vérification manuelle.

Cette file crée plusieurs formes de coût. Le travail d’ingénierie ralentit, car la remédiation interrompt la livraison de fonctionnalités. Les équipes de sécurité passent du temps à défendre la crédibilité du scanner. Les propriétaires d’applications apprennent à considérer les alertes comme des suggestions non vérifiées.

À terme, la confiance s’érode. Une véritable vulnérabilité peut arriver par le même canal et susciter la même réaction sceptique. Le système de détection a bien « trouvé » la faille, mais sur le plan opérationnel, il n’a pas permis une action rapide.

Les faux négatifs créent le danger inverse. Un système plus strict peut réduire les interruptions en signalant moins de problèmes, mais son silence devient moins digne de confiance s’il manque une grande part des failles authentiques.

C’est pourquoi le double seuil d’AWS est important. Mesurer uniquement la précision récompense les systèmes conservateurs qui ne signalent presque rien. Mesurer uniquement le rappel récompense les systèmes agressifs qui signalent presque tout. Les décisions de production exigent les deux valeurs, segmentées selon la gravité des vulnérabilités et le contexte du code.

Les équipes devraient également demander comment un fournisseur a établi la vérité terrain. Les étiquettes de vulnérabilité sont difficiles à attribuer, car le code peut être sûr pour des raisons extérieures à la fonction visible. Les dépendances, la configuration, l’authentification, les contrôles réseau et l’état du déploiement peuvent modifier l’exploitabilité.

L’équipe de Deception Benchmark a tenté de limiter les erreurs d’étiquetage grâce à des revues indépendantes répétées et en excluant les cas contestés de la notation. C’est un choix de conception réfléchi, mais il soulève une autre question. Dans quelle mesure ses échantillons clairement arbitrés ressemblent-ils à l’ambiguïté des véritables systèmes d’entreprise ?

Les dépôts réels contiennent des tests incomplets, des hypothèses non documentées, des configurations obsolètes, du code généré et des lacunes de responsabilité. Un outil peut devoir indiquer que les preuves sont insuffisantes au lieu de forcer une réponse binaire vulnérable ou sûr.

Le benchmark demande actuellement cette décision binaire. Des explications détaillées sont requises, mais l’abstention n’est pas répertoriée comme un résultat noté. Les évaluations futures pourraient examiner si une incertitude calibrée aide les équipes à allouer leurs efforts de revue.

La latence et le coût méritent également de l’attention. Un système multi-agent peut réduire les faux positifs en exécutant des tests et en inspectant un contexte plus large. Cette amélioration peut exiger davantage de calcul, des délais de revue plus longs et l’accès à du code ou à une infrastructure sensibles.

Ces compromis n’invalident pas la vérification agentique. Ils déterminent où elle a sa place. Les changements à haut risque peuvent justifier une analyse plus approfondie, tandis que le code courant peut nécessiter un filtrage moins coûteux suivi d’une escalade sélective.

Les responsables de la sécurité devraient éviter de remplacer une métrique de vanité par une autre. Un score global de précision masque la direction des erreurs. Un chiffre spectaculaire de productivité peut masquer la charge de revue. Un taux impressionnant de réussite des exploits dit peu de chose sur le code sûr.

Une évaluation crédible devrait divulguer au moins cinq éléments : le taux de faux positifs, le taux de faux négatifs, la couverture, la méthode de validation et les performances par catégorie de faiblesse. Elle devrait également identifier les refus et les sorties invalides au lieu de les retirer silencieusement.

La couverture a affecté un résultat AWS. La plupart des configurations ont renvoyé des réponses valides pour au moins 98 % des échantillons. GPT-5.6 Sol, avec des prompts de preuve d’exploitation, a couvert 93 % des cas, car un filtre de sécurité du fournisseur a refusé certaines demandes de construction d’exploit.

Ce détail révèle une autre contrainte de production. Les agents de sécurité doivent parfois raisonner sur des techniques nuisibles pour valider les défenses. Les contrôles de sécurité des modèles peuvent bloquer une évaluation légitime, créant des résultats manquants qu’il faut mesurer plutôt qu’ignorer.

Pour les acheteurs en entreprise, la meilleure position à court terme est une assistance contrôlée. Laissez l’IA prioriser, expliquer et rassembler les éléments de preuve. Maintenez une vérification humaine sur les chemins de code à haut risque, surtout lorsque le contexte de déploiement ou la logique métier détermine si une attaque fonctionne.

La proposition de valeur devient alors plus restreinte, mais plus défendable. L’IA peut réduire le temps de recherche et faire émerger des hypothèses. Elle ne devrait pas recevoir une autorité unilatérale simplement parce que ses résultats utilisent un langage technique assuré.

Ce que les équipes de sécurité doivent surveiller ensuite

Le benchmark ne deviendra déterminant que si les fournisseurs testent des systèmes complets, publient des taux d’erreur équilibrés et démontrent que les progrès se maintiennent sur de vrais dépôts.

Le premier signal est la participation. AWS invite les développeurs à exécuter les 14 822 échantillons et à soumettre leurs prédictions pour une évaluation vérifiée. Les systèmes en plusieurs étapes utilisant des outils sont évalués séparément des modèles à tour unique.

Les soumissions indépendantes révéleront si la vérification agentique comble l’écart mesuré. Si des systèmes complets ramènent les deux taux d’erreur sous les 10 %, les résultats étayeraient le point de vue d’AWS selon lequel l’architecture peut compenser un jugement de base insuffisant. Dans le cas contraire, le problème de confiance serait plus profond.

Le deuxième signal est la reproductibilité. Les chercheurs devraient examiner les échantillons publiés, les catégories de défis, le groupe non évalué et le processus d’étiquetage masqué. Des évaluations comparables menées par des groupes indépendants montreraient si les classements des modèles et les schémas d’échec persistent au-delà de la méthode de construction d’AWS.

Le troisième signal est la preuve en production. Les fournisseurs devraient indiquer combien d’alertes les utilisateurs examinent, écartent, rouvrent et finissent par corriger. Ces résultats de workflow comptent davantage que le score de classification isolé d’un modèle.

Le benchmark offre aussi aux acheteurs une meilleure demande de propositions. Demandez aux fournisseurs de soumettre leurs systèmes et de partager des taux vérifiés de faux positifs et de faux négatifs. Demandez ensuite comment leur processus de validation évolue pour le code critique, les résultats conditionnés par l’environnement et les langages non pris en charge.

Les développeurs devraient observer la manière dont les outils présentent l’incertitude. Un outil d’examen utile devrait distinguer les chemins d’exploitation confirmés des préoccupations plausibles et du contexte manquant. Traiter ces catégories comme identiques génère du travail évitable et masque le niveau de confiance réel du système.

Les recherches d’AWS sur la détection des vulnérabilités par l’IA n’ont pas démontré que l’examen de sécurité par IA est inutile. Elles ont montré pourquoi une détection sans vérification rigoureuse demeure coûteuse et risquée.

Le prochain test appartient aux équipes produit et aux acheteurs. Exigez la preuve qu’un signalement résiste au traçage du code, aux vérifications environnementales et à une validation reproductible avant d’être présenté à un ingénieur comme une tâche urgente. Votre fournisseur de sécurité publiera-t-il les deux types d’erreurs, ou continuera-t-il à vendre de la rapidité sans dévoiler la file d’examen qui se cache derrière ?