~10 minutes
Visa a publié le 5 juin 2026 VVAH — Visa Vulnerability Agentic Harness, un pipeline agentique en 11 étapes qui découvre, corrige et valide des vulnérabilités de manière autonome, construit sur les enseignements de Project Glasswing d’Anthropic. Voyons comment ce repo/tools peut s’articuler vis a vis d’une approche DevSecOPS.
Qu’est-ce que VVAH, concrètement
VVAH n’est ni un scanner SAST de plus, ni un simple wrapper autour d’un LLM qu’on pointe sur un repo. C’est un pipeline en quatre phases et onze étapes (S1 à S11), qui va de l’ingestion de code jusqu’au correctif validé :
| Phase | Étapes | Ce qu’elles font |
|---|---|---|
| 1 — Discovery & Modeling | S1–S3 | Cartographie la surface d’attaque, construit un plan de recherche via l’analyse de la menace |
| 2 — Deep Dive & Verification | S4–S6 | Analyse multiples (langage, crypto, logique métier, contrôle d’accès, IaC) puis vérification adversariale de l’exploitabilité |
| 3 — Synthesis & Reporting | S7–S9 | Déduplication, construction de chaînes d’attaque, création de findings structurés (Markdown + SARIF 2.1.0) |
| 4 — Remediation & Validation | S10–S11 | Propose des correctifs potentiels, puis les valide via un panel adversarial agentique avant mise en place |
Chaque étape du pipeline est implémentée comme un skill composable et versionnable : le mapper de surface d’attaque, le threat modeler AppSec (STRIDE, OWASP, trust boundaries), le stratège de recherche de vulnérabilités, les éléments spécialisées par domaine, le reviewer adversarial, le déduplicateur, le stratège d’exploit et le panel de validation. On peut retuner, versionner ou remplacer chaque skill indépendamment sans retoucher le reste du pipeline.
Trois commandes CLI structurent le tout : scan (S1–S9, détection), remediate (S10, en mode fix, propose et applique un correctif minimal), validate (S11, fait vérifier ces correctifs par un panel adversarial en lecture seule). Le multi-modèle est natif : Claude, modèles compatibles OpenAI, ou combinaison des deux via une couche d’abstraction, même si la remédiation et la validation en mode complet restent aujourd’hui centrées sur les modèles Anthropic.
Note du PandaRedacteur : un “multi-modèle” qui redevient mono-modèle dès qu’on active les fonctionnalités qui comptent vraiment, c’est une figure de style qu’on retrouve dans à peu près tous les outils agentiques du moment. Ça n’enlève rien à l’outil, mais lisez la doc jusqu’au bout avant de la citer dans un comité d’architecture.
Pourquoi cela semble solide et intéressant
Trois choix de conception retiennent mon attention, parce qu’ils attaquent directement les angles morts que je documente régulièrement sur ce blog.
Le threat modeling avant l’analyse. VVAH construit un modèle de menace (S2) avant de lancer la recherche de vulnérabilités, plutôt que de scanner à l’aveugle puis de trier après coup. C’est exactement la logique que je défends dans mes articles sur STRIDE et PASTA : prioriser en fonction du contexte métier plutôt que de la seule présence d’un pattern dangereux dans le code.
Le vote déterministe multi-agent pour réduire les faux positifs. Sur les backends sdk et openai, un vote à majorité tourne pour filtrer les faux positifs ; le backend cli (sans contrôle de température) reste en single-pass. C’est une réponse directe à un problème que je décris dans AST08 — Scanning insuffisant : les scanners classiques génèrent un volume de bruit qui noie les vraies findings, et personne ne trie correctement des centaines d’alertes chaque semaine.
La métrique qui compte réellement : le MTTA. VVAH mesure le Mean Time to Adapt : le temps entre la découverte d’une exploitabilité par l’IA et un correctif validé en production. C’est le pendant exact du Mean Time to Breach que documentait la Cloud Security Alliance dans l’article que j’ai analysé récemment : Mean Time to Breach, pourquoi vos cycles de patch ne vous protègent plus. La CSA chiffrait l’écart à 48 minutes pour compromettre contre 5 jours pour patcher ; VVAH répond directement à ce goulot d’étranglement en compressant le cycle découverte → correctif → validation dans un seul pipeline outillé.
Le vrai goulot d’étranglement de la gestion de vulnérabilités assistée par IA n’est pas la découverte, c’est le triage. VVAH est construit autour de cette contrainte, pas autour de la promesse de “tout scanner”.
Le pipeline en un coup d’œil
flowchart LR
subgraph P1["Phase 1 — Discovery"]
S1[S1 Attack surface] --> S2[S2 Threat model] --> S3[S3 Hunting plan]
end
subgraph P2["Phase 2 — Deep Dive"]
S4[S4 Multi-lens research] --> S5[S5 Pre-filter] --> S6[S6 Adversarial verification]
end
subgraph P3["Phase 3 — Synthesis"]
S7[S7 Dedup] --> S8[S8 Chaining] --> S9[S9 SARIF report]
end
subgraph P4["Phase 4 — Remediation"]
S10[S10 Remediate] --> S11[S11 Validate]
end
P1 --> P2 --> P3 --> P4
style P1 fill:#e8f4fd,stroke:#17a2b8,stroke-width:2px
style P2 fill:#fff3cd,stroke:#ffc107,stroke-width:2px
style P3 fill:#d1ecf1,stroke:#17a2b8,stroke-width:2px
style P4 fill:#f8d7da,stroke:#dc3545,stroke-width:2px
vvaharness scan --repo /path --stop-after s9 s’arrête à la détection, sans toucher au code. Sans ce flag, le profil par défaut va jusqu’à S10 en mode fix et modifie les fichiers sources du dépôt cible. C’est un point d’attention que je détaille plus bas.
Note du PandaRedacteur : un scanner qui devient committeur de code par défaut, c’est le genre de détail qu’on découvre en général après le premier incident de prod, pas avant. Lisez le flag
--stop-aftercomme une clause de sauvegarde, pas comme une option parmi d’autres.
Dans quel cadre ça s’insère
Je vois VVAH comme une couche complémentaire, pas un remplacement, dans une chaîne DevSecOps déjà outillée.
Face au SAST déterministe classique (Semgrep, CodeQL, Trivy) : ces outils restent imbattables sur la vitesse et la reproductibilité pour des patterns connus. VVAH ajoute ce que le pattern-matching ne voit pas : logique métier, chaînes d’exploitation multi-fichiers, contexte de menace, au prix d’un coût en tokens et d’un résultat non-déterministe. Les deux se combinent plutôt qu’ils ne s’excluent.
Face à la matrice de priorisation CVE/CVSS/EPSS/KEV que je détaillais en janvier (CVE, CVSS, EPSS, KEV : la matrice de priorisation ultime) : cette matrice répond à “quelle CVE de dépendance patcher en premier”. VVAH répond à une question différente et complémentaire : “quelles vulnérabilités dans mon propre code existent, indépendamment de toute CVE publiée”. Les deux flux (dépendances connues vs. code propriétaire) doivent alimenter le même backlog de remédiation.
Face à MITRE ATT&CK dans le pipeline DevSecOps (Intégrer MITRE ATT&CK dans une approche DevSecOps) : le threat modeler AppSec de S2 (STRIDE, OWASP, trust boundaries) et les règles de détection en production que je documentais gagnent à partager le même référentiel de menaces ; les findings VVAH devraient être annotés avec les mêmes techniques ATT&CK que votre SIEM, pour fermer la boucle détection ↔ développement.
Face au cycle de développement assisté par IA (Sécuriser le cycle de développement assisté par IA) : VVAH illustre le mouvement inverse de ce que je décrivais en mars : plutôt que de sécuriser le code pendant qu’un agent l’écrit, on fait auditer et corriger après coup par un autre agent. Les deux approches ne s’opposent pas : specs et revue en amont réduisent le volume que VVAH doit traiter en aval.
VVAH est lui-même un système agentique à threat-modeler
C’est le point que je trouve le plus intéressant, et que la documentation de Visa assume honnêtement dans sa section Limitations : VVAH tourne avec des privilèges élevés et doit être utilisé uniquement contre des dépôts de confiance, par des opérateurs autorisés ; l’exécuter contre une cible non fiable peut exposer les credentials de l’hôte, les clés API et les fichiers sensibles.
Appliqué à la grille MAESTRO que je présentais en avril, VVAH se lit comme un cas d’école : L3 (orchestration multi-agent des 11 étapes), L4 (déploiement : l’accès en écriture au dépôt cible en mode fix), et L7 (écosystème : les backends CLI/SDK/OpenAI comme dépendances tierces) sont toutes en jeu simultanément dès qu’on lance un scan en mode fix sur un repo qu’on ne maîtrise pas entièrement.
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d’identité) | Modéré | Le vol du credential Claude Code (CLAUDE_CODE_OAUTH_TOKEN) ou de la clé API permet d’exécuter des scans/remédiations sous l’identité de l’opérateur légitime. |
| Tampering (Falsification) | Oui (primaire en mode fix) | Le mode remédiation (S10) édite directement les fichiers sources de la cible ; un correctif halluciné ou un prompt injection via le code scanné peut introduire une régression ou une backdoor silencieuse. |
| Repudiation (Répudiation) | Modéré | run_manifest.json trace version, rôles de modèles, hash de config et SHA git cible ; bonne base d’audit, à condition de le conserver et de le corréler avec les logs de déploiement. |
| Information Disclosure (Divulgation) | Oui | Scanner un dépôt non fiable ou malveillant avec des privilèges élevés peut exposer credentials hôte, clés API et fichiers sensibles au modèle et, potentiellement, au dépôt scanné lui-même. |
| Denial of Service (Déni de service) | Faible | Le principal risque opérationnel est budgétaire : les caps sont par étape/finding, pas globaux ; un run mal cadré peut consommer un budget de tokens conséquent. |
| Elevation of Privilege (Élévation de privilèges) | Oui | Un correctif appliqué automatiquement en mode fix, sans build ni tests, qui touche un fichier de permissions ou de configuration CI peut élargir la surface d’attaque au lieu de la réduire. |
Note du PandaRedacteur : confier des privilèges élevés à un agent dont la mission est justement de débusquer des failles, c’est un peu demander au cambrioleur de tester vos serrures avec le trousseau que vous venez de lui remettre. Ça peut très bien se passer. Le hardening documenté n’est pas là pour la forme.
Impact potentiel d’un déploiement non maîtrisé
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Critique | Un scan lancé contre un dépôt malveillant ou non fiable, avec des privilèges hôte élevés, peut exposer credentials, clés API et fichiers sensibles au modèle ou à la cible elle-même. |
| Intégrité | Élevé | Le mode fix (S10) applique des correctifs sans build ni tests automatisés ; un patch halluciné ou mal ciblé s'intègre au code sans garde-fou technique avant la revue humaine. |
| Disponibilité | Modéré | Les caps de coût sont par étape et par finding, pas globaux ; un run mal cadré sur un gros dépôt peut consommer un budget de tokens important sans plafond agrégé. |
| Réputation | Sévère | Un correctif automatique fusionné sans revue, qui casse la production ou introduit une régression de sécurité, retombe entièrement sur l'équipe qui a activé le mode fix sans contrôle. |
Comment l’adopter sans se faire mal
Rien de tout ça n’est disqualifiant : Visa documente ces limites avec une honnêteté , ca a le mérite d’être apprécié dans un outil qui vient de sortir. Voici comment je le déploierais :
- Toujours démarrer en détection pure.
--stop-after s9avant d’envisager le mode fix, sur tout nouveau dépôt. - Ne jamais scanner un dépôt non fiable avec les privilèges par défaut. Le hardening documenté pour cibles peu fiables doit être une étape obligatoire de l’onboarding, pas une option.
- Traiter le mode fix comme une pull request classique. CODEOWNERS, revue humaine obligatoire, build et tests avant merge : exactement les contrôles que je détaillais dans CI/CD Fortress et Le minimum syndical sur GitHub. Un correctif généré par IA n’a pas moins besoin de revue qu’un correctif humain ; il en a probablement plus besoin.
- Garder
run_manifest.jsonet les rapports SARIF. Ils s’intègrent directement à un pipeline de scan existant et alimentent la même matrice de priorisation que vos CVE de dépendances. - Coupler la validation S11 avec vos propres gates CI/CD. Un verdict
validateddu panel adversarial ne dispense pas des contrôles SLSA sur la provenance du correctif ; voir SLSA : mettre sa supply chain sous haute surveillance.
Note du PandaRedacteur : “l’IA a proposé le correctif” n’a jamais dispensé personne de le lire avant de le merger. Ce n’est pas nouveau, c’est juste qu’on l’oublie plus vite quand le patch arrive déjà bien formaté et accompagné d’un rapport qui a l’air sérieux.
Ce contenu représente de nombreuses heures de travail, d'expérience etc... J'ai remarqué que mon contenu était repris par certaines sociétés/personnes et j'ai donc décidé de donner du contenu minimal sur ce blog. C'est pourquoi je vous invite a me contacter sur LinkedIn en mentionnant cet article pour plus d'informations.