Test d'acceptation de revue de sécurité IA : ce qu'Aave V3 et V4 enseignent sur le triage des scanners de smart contracts

Commencez par la contrainte peu flatteuse. Un scanner de sécurité IA peut produire en quelques minutes une liste d'alertes formulées avec assurance. Un responsable sécurité doit encore décider quelles alertes sont réelles, lesquelles sont des doublons, lesquelles peuvent être reproduites et lesquelles méritent du temps de revue cette semaine.

C'est pourquoi la revue assistée par IA d'Aave sur Aave V3 et V4 est plus utile comme test de flux de travail que comme titre de victoire. Aave Labs a rapporté 71 constats au total sur trois outils de sécurité IA anonymisés. La revue manuelle en a accepté 20. L'article d'Aave indique que les constats acceptés étaient faibles ou informationnels, tandis que plusieurs alertes arrivées comme critiques ou élevées ont ensuite été traitées comme des faux positifs après validation humaine.

Ces chiffres sont intéressants. Ils sont aussi faciles à mal utiliser. Ce sont des résultats rapportés par un projet, dans un périmètre et une méthode définis. Ils ne prouvent pas qu'un protocole, un dépôt ou une version est sécurisé. Ils montrent quelque chose de plus étroit et de plus opérationnel : les sorties d'un scanner ont besoin d'un test d'acceptation avant d'être autorisées à façonner la transmission à l'audit, la politique CI ou les décisions de mise en production.

La même idée s'applique en dehors des smart contracts. Les revues de sécurité applicative, les contrôles d'API, les scans de politiques d'infrastructure et la revue de code assistée par IA rencontrent tous le même problème. Un outil qui semble certain peut encore se tromper sur l'atteignabilité, les hypothèses de rôles, l'impact ou une cause racine dupliquée. Optijara a utilisé le même modèle de porte d'acceptation pour la qualification de VLM local, la reproductibilité de l'algorithme X et l'infrastructure IA sensible à la latence. Les scanners de sécurité devraient être soumis à la même discipline.

Mon point de vue est direct : un scanner bruyant n'est pas un contrôle de sécurité. C'est une source de pistes. Il ne devient un contrôle qu'après que l'équipe peut reproduire ses entrées, normaliser ses constats, calibrer la sévérité et consigner les décisions humaines.

Pourquoi la revue assistée par IA d'Aave est un test de reproductibilité, pas un tour d'honneur

Aave a rapporté que trois outils de sécurité IA avaient été exécutés sur les dépôts de production Aave V3 et Aave V4. Les scans couvraient les arbres src complets à des commits épinglés. Lorsque les outils le permettaient, ils recevaient un contexte similaire à celui que recevraient des auditeurs humains, y compris le contexte de modèle de menace et d'audit.

Aave a aussi décrit des tests de mutation sur quatre contrats V4, Hub, Spoke, TreasurySpoke et AaveOracle. Le test utilisait 304 mutations délibérées. Les tests existants en ont éliminé 271, tandis que 33 étaient non concluants parce que les suites de tests expiraient.

Le titre était 71 constats remontés et 20 acceptés après revue manuelle. La meilleure leçon se trouve dans le filtrage. Aave dit que les constats ont été classés manuellement comme valides, faux positifs, doublons ou conformes à la conception. C'est là que se situe l'opération de revue.

Un scanner qui émet 71 alertes n'est pas automatiquement plus fort qu'un scanner qui en émet moins. Le volume peut signifier de la couverture. Il peut aussi signifier des causes racines répétées, un contexte faible, des hypothèses périmées ou des explications générées autour de chemins de code qui n'ont pas d'importance. La question pour un responsable sécurité est plus précise : après normalisation, déduplication, revue de sévérité et arbitrage humain, que reste-t-il ?

L'absence de constats critiques ou élevés confirmés dans ce périmètre rapporté ne doit pas être lue comme une preuve de sécurité. Elle signifie que ces constats n'ont pas été confirmés dans l'état de code, le comportement d'outil, la méthode de revue et le processus de classification humaine rapportés. Cela reste une preuve utile. Ce n'est pas un substitut à la modélisation des menaces, aux audits indépendants, à la vérification formelle, aux concours, à la surveillance, à la planification de réponse aux incidents ou aux contrôles de mise en production.

La base de preuves : épinglage de la source, du commit, de l'outil et de la méthode

La première porte AISRAT est la fidélité de l'artefact. Avant que quiconque débatte de sévérité, l'équipe a besoin d'un paquet de preuves qui fixe la cible exacte de la revue. Au minimum, consignez l'URL du dépôt source, le hachage de commit, les fichiers de verrouillage des dépendances, les versions de compilateur, le conteneur de compilation, la configuration du scanner, les délais d'expiration, les permissions, les rapports générés, les chemins exclus et les notes de revue.

L'article d'Aave indique que les scans ont été exécutés sur des commits épinglés de dépôts de production et couvraient les arbres source. Les dépôts publics d'Aave V3 Origin et d'Aave V4 montrent du code, des audits, des rapports, des tests, des scripts et des répertoires de documentation pertinents. Cela donne aux lecteurs un contexte utile, mais un test d'acceptation interne a besoin de plus que du contexte.

L'équipe devrait pouvoir reconstruire la cible depuis un environnement propre et reproduire l'entrée du scanner. Si l'artefact scanné ne peut pas être reconstruit, la revue de sévérité repose déjà sur une base faible. Le périmètre du dépôt n'est pas la même chose que le périmètre du code revu. Un dépôt peut contenir src, des tests, des scripts, de la documentation, des fichiers générés, des modules dépréciés, des adaptateurs et des paquets périphériques. Chacun peut affecter le volume d'alertes et la charge des relecteurs.

Les scanners assistés par IA peuvent aussi changer de sortie lorsqu'un modèle, une invite, un jeu de règles, une source de récupération, une version de détecteur ou un délai d'expiration change. Les fournisseurs n'exposeront pas toujours chaque détail interne. Consignez ce que vous pouvez voir : version du produit, horodatage du rapport, fichier de configuration, modèle d'invite s'il est utilisé, instantané de documentation, ligne de commande, paramètres d'API et variables d'environnement qui affectent la sortie.

Le standard n'est pas une reproductibilité académique. Le standard est une reproductibilité opérationnelle suffisante pour décider si le scanner appartient à une voie qui affecte les files de revue, les portes CI, les paquets d'audit ou les décisions de mise en production.

Le cadre AISRAT

AISRAT signifie Optijara AI Security Review Acceptance Test. C'est un cadre de décision en six couches pour décider où un scanner IA doit se situer dans une voie de revue de sécurité des smart contracts ou des applications.

La fidélité de l'artefact vérifie que le scanner a revu le code qui compte pour l'équipe. Les champs requis incluent le dépôt, le commit, la commande de compilation, le compilateur, les verrous de dépendances, l'image de conteneur, le chemin source, les artefacts générés, les fichiers exclus, la version de l'outil, la version du modèle ou du jeu de règles lorsqu'elle est disponible et les permissions. Pour les smart contracts, ajoutez la version du compilateur, les hypothèses de chaîne, la configuration de déploiement, les dépendances simulées et les tests nécessaires pour reproduire le comportement.

La normalisation des problèmes rend les sorties du scanner comparables avant que les relecteurs y consacrent du temps. Normalisez chaque alerte en fichier, fonction, chemin de code, classe de vulnérabilité, préconditions, affirmation d'exploitabilité, preuves, confiance, groupe de doublons, sévérité proposée, statut de remédiation et notes de revue. Un long récit ne mérite pas de poids supplémentaire simplement parce qu'il semble faire autorité.

La sévérité est une affirmation. Ce n'est pas une preuve. AISRAT exige un argument d'exploitabilité ou d'impact qui correspond au modèle de confiance du système. Dans l'article d'Aave, la validation humaine a rétrogradé ou rejeté des alertes arrivées avec des étiquettes critiques ou élevées. L'outil propose la sévérité. Le relecteur la calibre par rapport à l'état atteignable, aux hypothèses de rôles, à l'impact, au chemin de code et au mode de défaillance.

L'arbitrage des relecteurs a besoin de structure. Lorsque c'est pratique, masquez l'identité de l'outil aux relecteurs pendant la première passe. Consignez les décisions acceptées, rejetées, doublons, conformes à la conception, non prises en charge et chemins de code hallucinés. Incluez un échantillonnage de faux positifs et un échantillonnage de faux négatifs par rapport à des vulnérabilités connues, des constats d'audits historiques, des tests de mutation ou des suites de bugs injectés.

L'économie de l'actionnabilité décide si l'adoption vaut le coût. Suivez le délai jusqu'au premier triage, le délai jusqu'à l'arbitrage, les minutes de relecteur par constat accepté, la charge de doublons, les constats rouverts et le coût par constat actionnable accepté. Définissez ensuite ce qui se passe après l'acceptation : seuils CI, dérogation humaine, paquets de transmission à l'audit, flux de divulgation, contrôle d'accès, télémétrie, canaris, critères de retour arrière et tests de régression.

{
  "framework": "AISRAT",
  "minimumEvidence": ["repo", "commit", "build", "toolConfig", "normalizedFinding", "reviewerDecision"],
  "routeOptions": ["research", "triageAssistant", "ciSignal", "auditInput"],
  "acceptanceQuestion": "Does the scanner produce reproducible, evidence-backed, non-duplicate findings at an acceptable reviewer cost for this route?"
}

Matrice de décision des voies

Un scanner avec des idées utiles mais une reproductibilité faible peut encore appartenir à la voie de recherche. Une porte CI exige un niveau plus élevé parce qu'elle peut ralentir la livraison ou créer une fausse confiance. L'entrée d'audit formel exige le paquet de preuves le plus propre parce que les auditeurs doivent pouvoir inspecter les décisions acceptées et rejetées, pas seulement la liste finale des défauts.

Checklist de mise en oeuvre AISRAT

Pour les smart contracts, ajoutez la compilation des contrats, les hypothèses de déploiement, les rôles de gouvernance, les dépendances aux oracles, les fonctions privilégiées, les hypothèses de messagerie inter-chaînes et les tests d'invariant ou de fuzzing. Pour la sécurité applicative, ajoutez les versions de services, les schémas d'API, les flux d'identité, la classification des données, la parité d'environnement et l'état du graphe de dépendances.

Erreurs courantes

Le nombre d'alertes est le chiffre le plus facile à commercialiser et le plus faible à exploiter. Il récompense les outils verbeux et pénalise les outils qui suppriment les sorties à faible confiance. La meilleure mesure est celle des constats actionnables acceptés après normalisation, déduplication et arbitrage des relecteurs.

Une étiquette critique sans chemin exécutable ou revuable n'est pas une vulnérabilité critique. AISRAT demande aux relecteurs de séparer la classe de vulnérabilité des preuves d'exploitabilité, de l'état atteignable, des hypothèses de rôles et de l'impact. C'est important dans les systèmes avec des rôles de gouvernance, des délais de verrouillage, des hypothèses d'oracle et un comportement de revert délibéré.

Les doublons consomment du temps de revue. Les fichiers hallucinés, les chemins inatteignables, les fonctionnalités de cadre technique non prises en charge, les dépendances périmées et les cibles qui ne compilent pas peuvent donner l'impression qu'un scanner est productif tout en ajoutant peu de valeur de sécurité. Suivez ces éléments comme leurs propres catégories. Les hallucinations rejetées devraient devenir des exemples de régression afin que le même outil ne les renvoie pas comme de nouveaux problèmes.

Les faux positifs sont faciles à voir parce que les relecteurs les regardent directement. Les faux négatifs exigent des tests délibérés. Utilisez des vulnérabilités connues, des problèmes d'audits historiques, des tests de mutation, des suites de bugs injectés et des lignes de base d'analyse statique conventionnelle. Un scanner avec moins de faux positifs peut encore être un mauvais signal CI s'il manque des problèmes connus.

Plan de mesure

Comparez la voie assistée par IA à une base de référence utilisant le même artefact épinglé et le même modèle de menace. La base de référence peut être une revue humaine seule, une analyse statique conventionnelle ou la suite de scanners existante de l'équipe. Les cibles universelles de précision sont généralement paresseuses. Le langage, le cadre technique, la maturité du code, la qualité du contexte et le modèle de menace changent tous le niveau de bruit acceptable.

Commencez par un pilote délimité : un dépôt, un commit, un modèle de menace, une voie. Décidez si le scanner mérite d'être une aide à la recherche, un assistant de triage, un signal CI ou une entrée d'audit. N'élargissez qu'après que le paquet de preuves est assez bon pour être inspecté par quelqu'un en dehors de l'équipe immédiate.

La revue d'Aave est utile parce qu'elle montre l'écart entre la sévérité du scanner et les preuves confirmées par des humains. AISRAT transforme cet écart en système de gestion. Il protège les relecteurs du bruit, donne aux fournisseurs des retours concrets et aide les équipes à adopter la revue de sécurité assistée par IA sans prétendre que l'outil est devenu l'auditeur. Si votre équipe conçoit une voie de revue assistée par IA, Optijara peut aider à définir les portes d'acceptation, le plan de mesure et les contrôles de gouvernance avant que le scanner commence à influencer les décisions de production.