ASVS (Application Security Verification Standard) est l'un des référentiels OWASP les plus utiles pour évaluer une app : 14 chapitres, des niveaux L1/L2/L3, ~280 contrôles vérifiables. Le problème en 2026 : il a été conçu pour des apps web classiques, pas pour des apps LLM. Du coup beaucoup de contrôles passent à côté de la surface IA. Voilà comment je l'utilise en pratique sur une mission audit d'une app LLM.
Garder ASVS comme colonne vertébrale
Première décision : on garde ASVS comme structure. Il couvre déjà :
- Auth (V2), Session (V3), Access control (V4)
- Validation des inputs (V5)
- Stored crypto (V6), Comm (V9)
- Erreurs et logging (V7)
- Data protection (V8)
- Business logic (V11)
- Configuration (V14)
Tout ça reste pertinent. Une app LLM est avant tout une app — elle a de l'auth, de la session, du logging, des secrets à stocker. ASVS le couvre déjà.
Ce que j'ajoute par chapitre
Pour chaque chapitre, j'identifie les contrôles spécifiques LLM à ajouter ou renforcer. Niveau cible : équivalent ASVS L2 pour la plupart, L3 sur les chapitres qui touchent la surface LLM.
V2 — Authentication
Ajouts LLM :
- Auth indépendante pour les services tiers appelés via tools/MCP (pas la même clé pour l'utilisateur et pour l'agent).
- Rotation des clés API LLM provider documentée et planifiée.
- Pas de credentials en clair dans les system prompts (souvent oublié).
V4 — Access Control
Ajouts LLM :
- Isolation tenant côté RAG et vector DB strictement vérifiée.
- Tools accessibles à un agent strictement scopés au tenant courant.
- Least privilege côté MCP / function calls.
V5 — Validation, Sanitization, Encoding
Le chapitre le plus touché. Ajouts :
- Validation et structured prompting des inputs utilisateur (séparation système / contenu utilisateur).
- Sanitization des contenus externes intégrés (RAG documents, web crawl) avant injection contexte.
- Encoding des outputs avant rendu UI (XSS via output LLM est un cas réel).
- Validation des sorties structurées (function call args, JSON outputs, code généré exécuté en sandbox).
V7 — Errors and Logging
Ajouts LLM :
- Log de chaque appel LLM avec : prompt complet (ou hash si volumineux), réponse, model version, temperature, durée, coût.
- Log des tools calls avec paramètres, résultat, statut validation humaine.
- Log des refus du modèle et des activations de guardrails.
- Pas de PII en clair dans les logs (souvent oublié quand on log les prompts).
V8 — Data Protection
Ajouts LLM :
- Politique DPA avec fournisseur LLM (voir DPA fournisseur LLM 7 clauses).
- Pas d'envoi de données catégories particulières RGPD au LLM sans base légale documentée.
- Output filtering qui détecte les fuites PII (regex emails, téléphones, NIR si France, etc.).
- Données utilisées pour fine-tuning : provenance, consentement, droit d'effacement.
V10 — Malicious Code
Ajouts LLM :
- Scan des modèles importés (ModelScan, Picklescan).
- Validation des plugins/tools MCP ajoutés au catalogue.
- Code généré jamais exécuté hors sandbox.
V11 — Business Logic
Ajouts LLM :
- Limites par session (tokens, tool calls, wall-clock, budget) — voir migration chatbot vers agent.
- Validation humaine pour actions à fort impact.
- Détection des prompts qui essaient de manipuler la logique métier (escalade privilèges via texte).
V14 — Configuration
Ajouts LLM :
- Versioning du system prompt en SCM, review obligatoire avant changement.
- Configuration model/temperature documentée et change-controlled.
- Catalogue tools / MCP versionné, ajout/modif soumis à revue.
Comment je structure l'audit
Sur une mission de 5-15 jours, ma démarche typique :
- J1-J2 — Discovery + scoping (quelle app, quelle architecture, quel cas d'usage métier).
- J3-J7 — Audit ASVS L2 classique (V2 à V14) avec les ajouts LLM ci-dessus, livré sous forme de gap analysis (statut par contrôle, criticité).
- J8-J10 — Audit OWASP LLM Top 10 en parallèle (voir OWASP LLM Top 10).
- J11-J13 — Cross-référencement ASVS / LLM Top 10 / NIST AI RMF, déduplication des recommandations.
- J14-J15 — Roadmap remédiation chiffrée en jours-dev par priorité.
Le livrable final fait ~40-60 pages, dont 70% est défendable face à un auditeur ISO 27001 / 42001.
Les pièges classiques
Vouloir cocher tous les contrôles d'ASVS L3
L3 est extrêmement exigeant. Pour 90% des apps LLM PME/scale-up, L2 suffit. Tirer un L3 sur le scope LLM-critique (V5, V8 surtout), L2 sur le reste.
Faire ASVS sans OWASP LLM Top 10
Vous passez à côté de la surface IA spécifique (prompt injection, model leakage, excessive agency). Les deux référentiels doivent être combinés.
Confondre ASVS et MASVS
MASVS est pour les apps mobiles. Si vous avez une app mobile qui parle à un backend LLM, vous avez besoin des deux : MASVS côté client, ASVS côté backend.
Ne pas re-passer ASVS après refactor
Une app LLM évolue vite (mise à jour modèle, nouveaux tools). Re-faire le pass ASVS au moins 1 fois par an sur les chapitres impactés.
Mon avis en 1 ligne
ASVS reste le meilleur cadre pour une app LLM, à condition de greffer les ajouts LLM par chapitre et de le coupler à OWASP LLM Top 10. Compter 10-15 jours pour un audit complet d'une app de complexité moyenne. Et planifier le re-pass annuel.