Strix : un pentesteur IA open source qui prouve chaque faille

Tous ceux qui ont branché un scanner de vulnérabilités sur leur application connaissent le rituel : un rapport de quatre-vingts pages, trois cents alertes, et deux journées à trier les faux positifs pour finir avec quatre problèmes réels. Le scanner ne sait pas si la faille est exploitable — il sait qu'elle ressemble à une faille.

Strix prend le problème par l'autre bout : il n'annonce rien tant qu'il n'a pas réussi à exploiter. Chaque résultat arrive avec une preuve de concept qui fonctionne et les étapes pour la reproduire. Le projet, publié par usestrix sur GitHub sous licence Apache 2.0, a dépassé les 58 000 étoiles en un an d'existence, avec des versions qui sortent chaque semaine.

Un avertissement avant tout le reste

Strix n'analyse pas : il attaque. Il envoie de vraies requêtes malveillantes, tente de vraies injections, exécute de vraies commandes sur la cible qu'on lui désigne. Le projet le dit lui-même sans détour, et c'est la seule phrase de cet article qui n'est pas négociable : ne le lancez que sur des systèmes qui vous appartiennent, ou pour lesquels vous détenez une autorisation écrite explicite, et restez dans le périmètre convenu. Un test non autorisé est un délit dans la plupart des juridictions, et l'argument « c'est l'IA qui l'a fait toute seule » n'a jamais convaincu personne.

Cela vaut aussi pour le bug bounty : le périmètre d'un programme est un contrat, pas une suggestion. Un agent autonome à qui l'on donne une URL de départ explore beaucoup plus loin qu'un humain prudent.

Ce qu'il y a dans la boîte

Là où un scanner classique envoie une liste de charges utiles, Strix dispose d'un véritable poste de travail offensif, et décide quoi en faire :

Le champ couvert va du top 10 de l'OWASP et au-delà : contrôle d'accès cassé et IDOR, injections SQL et de commandes, SSRF, XXE, désérialisation, XSS et pollution de prototype, failles de logique métier et conditions de concurrence, problèmes de session, mauvaises configurations d'infrastructure et de cloud, sécurité des API. Les failles de logique métier sont d'ailleurs celles où l'approche a le plus de valeur : aucune règle statique ne détecte qu'on peut commander un article à un centime en rejouant une étape du panier dans le désordre.

Le mettre en route

Il faut deux choses : Docker qui tourne, et une clé d'API chez un fournisseur de modèle. C'est tout.

curl -sSL https://strix.ai/install | bash

export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="votre-cle"

strix --target ./mon-application

La première exécution télécharge l'image du bac à sable Docker, et les résultats atterrissent dans strix_runs/<nom-de-la-passe>. La cible peut être un dossier local, un dépôt GitHub, une application en ligne, un fichier OpenAPI ou une collection Postman — et on peut combiner code source et application déployée dans la même passe, ce qui est exactement la situation d'une équipe qui teste son propre produit.

Deux remarques d'hygiène. D'abord, cette installation en curl | bash mérite les trente secondes de lecture du script avant exécution, ici comme ailleurs. Ensuite, le bac à sable Docker n'est pas décoratif : si vous pointez Strix sur du code tiers dont vous ne savez rien, c'est lui qui vous protège.

Une fois la passe terminée, strix view ouvre un tableau de bord local : répartition par sévérité, détail des trouvailles avec étapes de reproduction, coordination des agents en direct, et historique des passes précédentes. On peut même réorienter une passe en cours plutôt que de la relancer.

Là où ça devient vraiment intéressant

Le mode interactif fait la démonstration, mais la valeur est ailleurs. Le drapeau -n passe l'outil en mode silencieux : il affiche ses trouvailles au fil de l'eau et sort avec un code d'erreur non nul s'il a trouvé quelque chose. C'est-à-dire qu'il se comporte comme n'importe quel test de votre chaîne d'intégration.

De là, deux usages qui changent la donne :

• Le test limité au différentiel. On peut restreindre la passe aux modifications par rapport à une branche de base : au lieu de repasser toute l'application à chaque fois, on teste ce que la pull request vient d'introduire. C'est ce qui rend l'exercice tenable au quotidien, en durée comme en budget.
• L'intégration aux agents de développement. npx skills add usestrix/strix installe neuf compétences utilisables depuis Claude Code, Cursor ou Codex : lancer une passe, corriger une trouvaille puis revérifier qu'elle a disparu, câbler l'analyse en intégration continue. La boucle trouver-corriger-confirmer se ferme sans quitter l'éditeur.

Le support des serveurs MCP, ajouté tout récemment, permet en plus d'exposer vos propres outils aux agents pendant le test — de quoi brancher un environnement de recette ou un jeu d'identifiants maison.

Ce que ça coûte réellement

Le CLI est gratuit ; les jetons ne le sont pas. C'est le poste de dépense que personne n'affiche et que tout le monde découvre : un agent qui explore, essaie, échoue et recommence consomme énormément, d'autant que l'effort de raisonnement est réglé sur « élevé » par défaut. Le réduire à « moyen » pour les passes rapides est le premier réglage à connaître, la restriction au différentiel le second.

Côté modèles, le projet recommande openai/gpt-5.4, anthropic/claude-sonnet-4-6 ou vertex_ai/gemini-3-pro-preview, mais accepte n'importe quel fournisseur compatible — y compris un modèle auto-hébergé, ce qui est l'option à retenir si le code testé ne doit pas sortir de chez vous. Prévoyez de surveiller la consommation dès la première passe plutôt que de découvrir la facture en fin de mois.

Un mot sur le modèle économique, parce qu'il explique la générosité du dépôt : Strix est un projet à cœur ouvert. Le CLI est libre et complet, mais il existe aussi une plateforme hébergée qui ajoute les intégrations GitHub, GitLab, Slack ou Jira, les correctifs proposés en pull request, l'analyse continue, et une édition entreprise avec rapports de conformité SOC 2, ISO 27001 et PCI DSS. Rien de choquant, mais autant le savoir avant de bâtir tout un processus dessus.

Ce que ça ne remplace pas

Trois limites méritent d'être posées, et elles n'enlèvent rien à l'outil.

• Ce n'est pas reproductible. Deux passes sur le même code peuvent ne pas donner le même résultat. C'est la nature d'un agent, pas un défaut de jeunesse — mais cela signifie qu'un rapport vierge ne prouve rien.
• Absence de preuve n'est pas preuve d'absence. Strix trouve ce qu'il parvient à exploiter. Un audit humain reste un exercice différent, et une exigence de certification ne se satisfait pas d'une sortie de CLI.
• Il vous rend des failles, pas de la compréhension. C'est le vrai piège. Recevoir une preuve d'exploitation d'IDOR fonctionnelle sans savoir ce qu'est un IDOR, c'est appliquer le correctif suggéré sans voir les douze autres endroits du code où le même schéma se répète.

Sur ce dernier point, il n'y a pas de raccourci : il faut avoir lu les bases une fois. Comprendre ce que l'agent fait à votre place, c'est la différence entre corriger un symptôme et corriger une classe de bogues.

Les Bases du hacking Lien affilié

Initiation au pentest : reconnaissance, exploitation, post-exploitation.

23,00 €

4.5/5

Voir sur Amazon →

Et pour la culture générale qui va autour — vocabulaire, familles d'attaques, réflexes défensifs — un ouvrage plus large fait le travail, y compris pour les développeurs qui ne feront jamais de sécurité leur métier mais dont le code sera attaqué quand même.

Hacking et Cybersécurité Mégapoche pour les Nuls Lien affilié

Comprendre les attaques pour mieux protéger ses comptes et ses données.

25,95 €

5.0/5

Voir sur Amazon →

Le mot de la fin

Strix fait basculer quelque chose : le test d'intrusion cesse d'être un événement trimestriel commandé à un prestataire pour devenir un test parmi d'autres, exécuté à chaque pull request. Ce n'est pas la fin des pentesteurs — c'est la fin des vulnérabilités évidentes qui survivent six mois en production parce que personne n'a regardé.

Le meilleur moment pour découvrir qu'on peut contourner votre contrôle d'accès, c'est avant que quelqu'un d'autre ne le découvre. Sur votre propre application, avec votre propre autorisation.