Strix — l'audit de sécurité automatique de ton appli

Tu livres une appli, un client ou tes propres utilisateurs commencent à s’en servir, et c’est à ce moment-là — pas avant — que tu découvres la faille qui traînait depuis le début. Un formulaire qui ne valide rien, une route d’API accessible sans authentification, un token qui traîne en clair. Le problème n’est pas que ces failles existent, c’est que tu les apprends toujours trop tard.

Ce qu’est Strix

Strix, ce sont des agents IA open source qui font le travail d’un pentester plutôt que celui d’un scanner. La différence compte : un outil d’analyse statique classique lit ton code et sort une liste d’alertes, souvent longue, souvent pleine de faux positifs que tu dois trier un par un. Strix fait l’inverse. Il lance vraiment ton appli dans un bac à sable, l’attaque comme le ferait un humain malveillant, et chaque faille qu’il remonte est validée par un exploit réel qui a fonctionné. Si Strix te dit qu’une route est vulnérable, c’est qu’il l’a exploitée devant toi, pas qu’il a deviné.

Avant de commencer

Il te faut trois choses. Docker, installé et lancé, parce que Strix exécute ses agents dans un conteneur isolé plutôt que directement sur ta machine. Une clé API pour un modèle d’IA : Strix s’appuie sur un LLM pour raisonner, et accepte OpenAI, Anthropic, Google Gemini, ou des modèles passés par OpenRouter (son modèle par défaut est GLM via OpenRouter). Et bien sûr, une appli à toi, que ce soit un dossier en local ou un dépôt GitHub.

Installation

L’installation passe par un script shell :

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

Configure ensuite ton modèle et ta clé API. Par exemple avec OpenRouter :

export STRIX_LLM="openrouter/z-ai/glm-5.3"
export LLM_API_KEY="ta-cle-api"

Lance ensuite un premier scan sur un dossier de test :

strix --target ./mon-appli

Les trois façons de lancer un scan

Strix accepte trois types de cibles avec la même commande, seul ce qui suit --target change. Sur un dossier en local, pour auditer le code sur lequel tu travailles :

strix --target ./mon-appli

Sur un dépôt GitHub, pratique pour auditer un projet sans le cloner toi-même :

strix --target https://github.com/ton-compte/ton-repo

Ou directement sur une URL, pour tester l’appli telle qu’elle tourne en production ou en préproduction :

strix --target https://ton-appli.com

Intégrer Strix à ta CI

Le vrai intérêt, c’est de ne plus avoir à y penser : un audit automatique à chaque pull request, qui bloque la fusion si une faille exploitable est trouvée. Voici un workflow GitHub Actions qui fait ça :

name: strix-audit
on:
  pull_request:

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0

      - name: Installer Strix
        run: curl -sSL https://strix.ai/install | bash

      - name: Lancer Strix sur le diff
        env:
          STRIX_LLM: ${{ secrets.STRIX_LLM }}
          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
        run: strix -n -t ./ --scan-mode quick

Deux détails font tout le travail ici. Le -n passe Strix en mode non interactif : il tourne seul dans la CI et ressort avec un code d’erreur si une faille a été trouvée, ce qui suffit à bloquer la pull request. Et --scan-mode quick recentre l’audit sur les fichiers modifiés par la PR plutôt que de rescanner toute l’appli à chaque fois, pour que ça reste rapide.

Lire le rapport

Chaque scan range ses résultats dans strix_runs/<nom-du-run>. Pour les consulter dans un vrai tableau de bord plutôt qu’en brut dans le terminal :

strix view

Commence toujours par les failles de sévérité la plus haute : ce sont elles qui ont un exploit fonctionnel derrière, pas une simple suspicion. Comme chaque ligne du rapport est accompagnée de la preuve que Strix a utilisée pour la valider, tu sais exactement quoi reproduire pour vérifier que ton correctif tient, au lieu de deviner si l’alerte était réelle.

Les limites, honnêtement

Strix ne remplace pas un pentest humain. Un agent IA, aussi bon soit-il, raisonne sur ce qu’il peut observer et tester automatiquement ; il passe à côté des failles de logique métier qu’un pentester expérimenté repère en comprenant vraiment ce que ton appli est censée faire. Vois-le comme un premier filtre solide, pas comme l’audit final.

Et le coût réel, ce n’est pas Strix lui-même : c’est le modèle d’IA branché derrière. Chaque scan consomme des appels à un LLM payant, et sur un projet actif où Strix tourne à chaque pull request, la facture suit le rythme de tes PR. Avant de le brancher partout, regarde combien coûte un scan avec le modèle que tu as choisi.