L’IA peut désormais mettre au jour des faiblesses logicielles plus rapidement que de nombreuses équipes de sécurité ne peuvent les examiner. Dans son annonce du 2 juin consacrée à l’extension du projet Glasswing, Anthropic indique que ses premiers partenaires ont utilisé Claude Mythos Preview pour analyser des bases de code et identifier plus de 10 000 failles de gravité élevée ou critique. L’annonce souligne également le goulot d’étranglement moins visible qui suit la découverte : vérifier les résultats, les divulguer de manière responsable, rédiger des correctifs et déployer les logiciels corrigés.
C’est cette séquence qui constitue l’enseignement utile. Un résultat généré par l’IA ne devient pas un rapport de vulnérabilité tant qu’une personne n’a pas pu le reproduire, en expliquer l’impact et le relier à un plan de remédiation autorisé. Le processus ci-dessous transforme ce principe en guide reproductible pour les équipes de sécurité, les mainteneurs et les développeurs. Il est conçu pour un travail défensif sur des systèmes que vous possédez ou que vous êtes explicitement autorisé à tester.
1. Définir le périmètre avant de demander des résultats
Commencez par un périmètre écrit. Indiquez le dépôt, le commit ou la branche, l’environnement de test autorisé, la classification des données et les personnes responsables de l’approbation. Si l’analyse concerne un service connecté à la production, précisez ce que l’outil ne doit pas faire : aucune action destructive, aucune utilisation d’identifiants, aucune extraction de données, aucune persistance ni aucun test contre des systèmes tiers.
Utilisez autant que possible un clone jetable ou soumis à un contrôle d’accès. Supprimez les secrets, les données clients, les clés privées et les identifiants actifs avant qu’un outil d’IA n’accède au code. Enregistrez le commit exact, les fichiers de verrouillage des dépendances et la configuration utilisés pour l’analyse. L’équipe dispose ainsi d’une base reproductible ultérieurement et évite qu’un modèle ne transforme un contexte sensible en exposition de sécurité inutile.
2. Transformer chaque résultat du modèle en fiche de triage
Ne versez pas une liste non structurée de résultats dans une file de tickets. Exigez une fiche standardisée pour chaque problème potentiel :
- Emplacement : dépôt, fichier, fonction et plage de lignes.
- Catégorie : faiblesse suspectée, comme une autorisation incorrecte, une injection ou une désérialisation dangereuse.
- Préconditions : accès, entrée ou configuration nécessaires.
- Impact : actif ou propriété de sécurité menacé, formulé en langage clair.
- Éléments probants : chemin de code concerné, flux de données ou résultat d’une reproduction sûre.
- Niveau de confiance : ce qui est établi, ce qui est déduit et ce qui doit encore être vérifié.
- Action proposée : correctif minimal, test à ajouter et éventuelle obligation de divulgation.
Demandez au modèle d’identifier les incertitudes plutôt que de combler les lacunes par des suppositions. Une consigne utile demande d’analyser uniquement le code fourni, de proposer un plan de reproduction non destructif et de distinguer les observations des hypothèses. Conservez la consigne, le nom du modèle, la date et le commit d’entrée avec la fiche. Cette piste d’audit est importante lorsqu’un évaluateur doit comprendre pourquoi un problème a été priorisé.
3. Reproduire de manière sûre, sans intensifier le test
La vérification humaine est la porte d’entrée entre une suggestion de l’IA et une tâche d’ingénierie. Reproduisez le comportement suspect dans un environnement isolé, avec des données synthétiques et les permissions les plus limitées possibles. Préférez les tests unitaires, les tests d’intégration, l’analyse statique et les fixtures contrôlées à l’exploitation en conditions réelles. Si une preuve exige un accès réseau, utilisez un service simulé ou un hôte de test dédié et documentez d’abord les points de terminaison autorisés.
L’objectif est de confirmer la propriété de sécurité, pas de démontrer les dommages maximaux possibles. Par exemple, si un résultat suggère qu’un utilisateur peut lire l’enregistrement d’un autre utilisateur, un test sûr doit utiliser deux comptes de test et une fixture inoffensive. Il ne doit pas énumérer de vrais enregistrements ni tenter d’accéder à des locataires sans rapport. Arrêtez-vous lorsque l’affirmation est confirmée ou réfutée, et conservez les journaux, les entrées, les détails de l’environnement et le résultat exact.
Classez le résultat comme confirmé, faux positif, doublon, impossible à reproduire ou nécessitant davantage de preuves. « Impossible à reproduire » ne signifie pas que le processus a échoué ; c’est une raison pour écarter le problème de la décision de mise en production jusqu’à ce que quelqu’un puisse établir les conditions manquantes.
4. Corriger la cause racine et ajouter un test de régression
Utilisez l’assistant d’IA pour comparer des options de remédiation, expliquer un diff proposé ou rédiger un test, mais gardez la modification ciblée. Le correctif doit appliquer la limite de sécurité prévue à l’endroit où la décision est prise, plutôt que de masquer les symptômes ailleurs dans l’application. Demandez des alternatives et les compromis connus, puis laissez un mainteneur sélectionner l’implémentation.
Chaque problème confirmé doit produire au moins un test de régression qui échoue sur la révision vulnérable et réussit sur la révision corrigée. Ajoutez des cas négatifs en plus du parcours de réussite attendu. Exécutez la suite de tests habituelle du projet, les vérifications des dépendances et l’analyse statique pertinente. Examinez le diff final pour détecter toute journalisation accidentelle de secrets, modification de permissions, nouvel appel réseau, validation affaiblie ou refactorisation sans rapport.
5. Organiser une revue à deux personnes avant la divulgation ou la mise en production
Un second évaluateur doit pouvoir reproduire le problème à partir de la fiche sans s’en remettre à l’autorité du modèle. Il doit vérifier le périmètre, la gravité, les versions affectées, le comportement du correctif et la couverture des tests. Si le code est partagé avec des clients, des mainteneurs en aval ou des utilisateurs open source, préparez un avis clair expliquant l’impact, les versions affectées, la version corrigée et les mesures d’atténuation. Envoyez-le via le contact de sécurité établi par le projet ou son processus de divulgation coordonnée.
Ne publiez pas de détails d’exploitation simplement parce qu’un système d’IA les a produits. Partagez suffisamment de preuves pour permettre aux mainteneurs concernés de valider et de corriger le problème, tout en retenant les détails opérationnels qui faciliteraient une exploitation non autorisée. Coordonnez le calendrier de publication avec le mainteneur responsable et conservez une trace des notifications et des réponses.
6. Mesurer le processus, pas seulement le nombre de résultats
Suivez le taux de confirmation, le taux de doublons, le délai entre la découverte et la vérification, le délai de correction, la couverture des tests de régression et le nombre de problèmes divulgués en toute sécurité. Ces indicateurs montrent si l’IA réduit la charge de travail défensive ou si elle ne fait qu’alimenter une file plus importante d’alertes non vérifiées. Examinez les résultats après chaque analyse et resserrez les consignes, les permissions et les critères d’acceptation lorsque le processus produit trop de bruit.
Le message plus large du projet Glasswing est que la découverte de vulnérabilités n’est qu’une partie du travail moderne de sécurité. Un processus contrôlé qui préserve les preuves, limite les accès, exige une vérification humaine et considère la divulgation comme une composante de la remédiation peut rendre l’assistance de l’IA utile sans lui accorder une autorité sans contrôle.