Project Glasswing : Anthropic révolutionne la détection de failles
Origines et historique
L'idée d'utiliser des grands modèles de langage pour aider à détecter des vulnérabilités n'est plus théorique. Des équipes de recherche et des entreprises expérimentent depuis plusieurs années des chaînes hybrides mêlant analyses statiques, fuzzing dynamique et approches basées sur le machine learning. Dans ce contexte, Anthropic a présenté Project Glasswing, une initiative visant à intégrer son modèle Claude dans des flux de travail de sécurité pour automatiser la génération d'hypothèses d'attaque, préparer des entrées de fuzzing et synthétiser des rapports enrichis¹.
Le point clef ici n'est pas seulement d'automatiser, mais d'élargir la surface d'analyse tout en essayant de maintenir un taux acceptable de faux positifs et de faux négatifs. Les premiers retours du terrain montrent des gains réels sur le temps de découverte, mais aussi des défis concrets : biais d'entraînement, vecteurs d'erreurs propres aux LLM et risques d'exposition d'informations sensibles. OWASP a formalise une typologie des risques liés aux LLM qui est utile comme référentiel opérationnel pour évaluer ces technologies².
Fonctionnement technique
Architecture générale proposée
Un pipeline Glasswing-like se conçoit en modules clairement séparés, chacun avec des responsabilités et des garanties de sécurité.
- Ingestion et normalisation des artefacts - collecte du code source, manifests IaC, images de conteneurs, fichiers de configuration; normalisation pour formats structurés (JSON, YAML) et annotations de provenance.
- Analyse statique préliminaire - exécution d'outils SAST (Bandit, SonarQube, CodeQL) pour repérer les patterns connus et produire des résumés structurés exploitable par le modèle.
- Enrichissement par LLM - le modèle propose des hypothèses d'attaque, génère payloads et séquences de requêtes à fuzz. Cette étape doit recevoir un contexte normé et limité pour réduire la surface d'exposition des données.
- Validation dynamique - fuzzing ciblé et exécution de POC en sandbox pour confirmer ou invalider les hypothèses générées.
- Triage et priorisation - corrélation des résultats dynamiques, scores de criticité (CVSS) et métriques de confiance issues du modèle pour ordonner les corrections.
- Rapportage et remediation - génération de rapports exploitables contenant POC reproductibles, recommandations de patch et métadonnées de traçabilité.
Chaque brique doit exposer des interfaces minimalistes (API REST ou queues) et des contrôles d'accès stricts. Les artefacts envoyés au modèle doivent être dépouillés des secrets et limités au strict nécessaire.
Rôle de Claude et limites techniques
Claude apporte trois types d'apports : classification et résumé de blocs de code, génération d'hypothèses d'exploitation et rédaction de rapports humains. Sur ces tâches, le modèle accélère l'investigation et structure les idées qui guideront l'effort de fuzzing.
Cependant, plusieurs limites techniques exigent des garde-fous.
- Hallucinations - le modèle peut proposer des scénarios plausibles mais non réalisables. Sans vérification dynamique, ces sorties risquent de produire du bruit et de fausser le triage. Il faut systématiquement rejouer les hypothèses dans des oracles de test automatisés.
- Faux positifs / faux négatifs - les chaînes logiques complexes ou la logique métier spécifique échappent parfois au modèle. Un simple contrôle d'autorisation implémenté via en-têtes ou contextes d'état peut être mal interprété.
- Exposition de secrets - prompts mal conçus peuvent divulguer des clés ou des données sensibles; chiffrement et anonymisation des entrées doivent être la règle.
Pour ces raisons, le modèle est un accélérateur, pas un remplaçant. Les sorties doivent être traitées comme des propositions nécessitant validation et traçabilité.
Mécanismes de vérification
La confiance dans le pipeline se construit par instrumentation et preuves d'exécution.
- Environnements hermétiques - exécution des POC dans des sandboxes containers isolés, avec seccomp, cgroups et monitoring des syscalls.
- Cross-validation - juxtaposer les hypothèses du LLM avec résultats d'analyses statiques et traces de fuzzing (CodeQL, AFL, boofuzz). Une hypothèse gagnante est celle qui a au moins une validation dynamique et une corrélation statique.
- Métadonnées de confiance - chaque alerte doit embarquer l'origine des artefacts, la version du modèle, le prompt utilisé, le score de confiance et les traces d'exécution du POC.
- Journaux immuables - conserver un log horodaté et signé des interactions modèle-pipeline pour audits et post-mortems.
Ces mécanismes aident à réduire le taux de faux positifs et à fournir des preuves exploitables pour les équipes de remediation.
Études de cas
Cas 1 - Bibliothèque open source vulnérable
Sur un projet Node, une dépendance NPM contenait une routine de parsing vulnérable. Le pipeline a ingéré le repo, produit un résumé de la fonction en cause, puis le modèle a généré des payloads ciblés. Un fuzz contrôlé a provoqué le plantage attendu; la combinaison d'un résultat statique et d'un POC dynamique a permis de prioriser la correction et de proposer un patch d'atténuation temporaire. Le temps entre découverte et preuve reproductible a été réduit de manière significative.
Cas 2 - Configuration cloud mal sécurisée
Un manifeste IaC présentait des buckets avec des ACL trop permissives. L'analyse structurée a extrait les ressources sensibles, le modèle a identifié les motifs d'exposition, et une simulation d'accès dans une sandbox a confirmé l'impact. Le rapport fourni comprenait la liste des ressources à modifier et un score de priorité basé sur l'exposition et la criticité du service.
Cas 3 - Application web et logique d'autorisation
Une API microservices reposait sur une logique d'autorisation dispersée dans plusieurs composants. Le modèle a proposé une séquence de requêtes exploitant une faiblesse d'enchaînement; le fuzzing reproduisait la chaîne et produisait un POC exploitable. Là encore, la force du pipeline a été d'agréger preuves statiques et dynamiques pour convaincre les équipes de corriger rapidement.
Perspectives
Pour une mise en production prudente, la gouvernance et la traçabilité sont aussi critiques que la qualité technique du pipeline. OWASP fournit une liste de risques et des contrôles applicables aux LLM qui doivent être intégrés à toute stratégie de déploiement². Sur le plan opérationnel, les priorités sont les suivantes : limiter les données envoyées aux modèles, chiffrer les canaux, journaliser les interactions et exiger une validation dynamique avant toute alerte critique.
À l'avenir, on devrait voir des pipelines hybrides où les LLM alimentent des outils classiques (SAST, fuzzers, moteurs formels) et où les standards de sécurité des modèles deviennent des requis sectoriels. Du côté des équipes, améliorer la qualité des prompts spécialisés et formaliser des "protocoles de questionnement" permettra de réduire les sorties erratiques et d'augmenter la valeur opérationnelle.
Project Glasswing illustre la promesse et les contraintes de l'intégration des LLM dans la détection de failles. Passer à l'échelle demande des garanties concrètes : preuves d'exécution, gouvernance des données et contrôles techniques robustes. Avec ces conditions en place, ces outils peuvent accélérer la découverte et la remediation sans compromettre la sécurité du pipeline.
