Une étude récente chiffre à 45 % la part du code généré par IA contenant des vulnérabilités sérieuses. On parle beaucoup de la dette technique que ce code produit. Beaucoup moins des failles de sécurité qu'il introduit discrètement. Strix est né précisément de ce constat.

Strix est un projet open-source (licence Apache 2.0, dépôt usestrix/strix) créé par Ahmed Allam. Quelques semaines après son lancement, il atteignait la première place de Hacker News avec plus de 600 étoiles GitHub en une nuit. L'idée n'est pas nouvelle dans son principe, mais l'exécution l'est : plutôt que d'analyser du code statiquement, des agents IA naviguent sur votre application comme un attaquant le ferait, et cherchent activement des vecteurs d'exploitation réels.

Ce que Strix fait concrètement

Le point de départ est une critique légitime des outils de sécurité traditionnels : ils génèrent beaucoup de faux positifs. Un scanner classique va signaler des centaines de potentielles injections SQL, dont 90 % ne sont pas exploitables en pratique. Le résultat : les équipes finissent par ignorer les alertes.

Strix prend le problème à l'envers. Chaque vulnérabilité suspectée est validée par une tentative d'exploitation réelle dans un sandbox Docker. Si l'agent soupçonne une injection SQL time-based, il l'exécute, observe le délai de réponse, et génère un script Python fonctionnel qui reproduit l'attaque. Si ça ne fonctionne pas, rien n'est remonté. Zéro faux positif.

L'outil dispose de 17 compétences spécialisées couvrant les principales familles de vulnérabilités :

  • Contrôle d'accès : IDOR (Insecure Direct Object Reference), élévation de privilèges, contournement d'autorisation
  • Injections : SQL (union-based, blind, error-based, time-based), NoSQL, commandes système, template injection
  • Côté serveur : SSRF, XXE, désérialisation, path traversal
  • Côté client : XSS, prototype pollution, attaques DOM
  • Authentification : faiblesses JWT, gestion de session, contournement MFA
  • Logique métier : race conditions, manipulation de workflow

Une architecture multi-agents

Ce qui distingue Strix d'un simple scanner automatisé, c'est la coordination entre agents. Un agent de reconnaissance découvre un endpoint API qui expose des identifiants utilisateurs. Il transmet cette information à un agent d'énumération, qui teste systématiquement l'accès aux ressources en incrémentant ces identifiants. Si un utilisateur peut lire les données d'un autre en modifiant un paramètre dans sa requête, c'est un IDOR confirmé, avec PoC à l'appui.

Cette chaîne d'attaque coordonnée permet de trouver des vulnérabilités complexes qu'aucun outil mono-agent ne détecterait, précisément parce qu'elles nécessitent plusieurs étapes et plusieurs contextes d'authentification.

Le toolkit mis à disposition de ces agents est complet : proxy HTTP pour intercepter et manipuler les requêtes, navigateur multi-onglets pour les scénarios XSS et CSRF, terminal pour les tests d'exécution de commandes, et environnement Python pour le développement d'exploits personnalisés.

Installation et prise en main

L'installation se fait en trois étapes :

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

# 2. Configuration du LLM
export STRIX_LLM="openai/gpt-4o"
export LLM_API_KEY="votre-clé-api"

# 3. Lancement sur votre cible
strix --target ./repertoire-application

Strix nécessite Docker (pour l'environnement sandbox d'exploitation) et une clé API vers un fournisseur LLM. Les agents tournent en parallèle, ce qui accélère significativement l'analyse mais demande des ressources CPU et RAM suffisantes.

Comment nous l'avons utilisé

Sur notre plateforme, l'isolation entre organisations est portée par l'infrastructure : chaque client dispose de sa propre base de données. Les vecteurs d'attaque les plus critiques se situent donc à l'intérieur d'une organisation : un membre qui tenterait de lire les commandes, les messages ou le profil d'un autre membre en manipulant les identifiants de ses requêtes, ou d'obtenir des droits d'administration qui reviennent à un autre rôle.

Nous lançons Strix sur notre environnement de préproduction, avec des comptes de test de rôles différents. L'agent IDOR teste systématiquement les endpoints en tentant d'accéder aux ressources d'un compte depuis le contexte authentifié d'un autre. Chaque résultat confirmé arrive avec sa preuve d'exploitation, ce qui permet de le corriger puis de rejouer le PoC pour valider la correction.

L'outil propose également une intégration CI/CD via GitHub Actions, qui permet d'automatiser les scans à chaque pull request.

Une règle à respecter absolument

Strix effectue de vraies tentatives d'exploitation. Il ne simule pas : il attaque réellement les endpoints qu'il cible. Cela signifie qu'il ne doit jamais être lancé sur un environnement de production. Les conséquences peuvent être réelles : données corrompues, comptes verrouillés, états incohérents en base.

La bonne pratique est de réserver son usage à un environnement de staging ou de preprod isolé, avec des données de test, et en s'assurant que cet environnement est restaurable rapidement si nécessaire.

En résumé

Strix répond à un vrai problème : le pentest traditionnel est lent, coûteux, et intervient trop tard dans le cycle de développement. Un outil qu'on lance à la demande sur la preprod, et qui remonte uniquement des vulnérabilités prouvées, change la nature du travail de sécurité. On passe de la revue périodique à un test offensif disponible à tout moment.

Pour une équipe qui génère du code avec l'aide de l'IA, c'est particulièrement pertinent : les mêmes outils qui accélèrent la production de code peuvent introduire des failles que seule une exploitation active permet de détecter.