Déploiement de CyberStrikeAI : même un outil simple exige du soin dans les détails

Je viens de me frotter à CyberStrikeAI, une plateforme de tests de sécurité IA-native écrite en Go. Je pensais qu'un « déploiement en un clic » se résumait à cloner le dépôt et lancer un script, mais je suis tombé sur quelques pièges de taille moyenne. Tant que tout est frais en mémoire, voici le récit complet — beaucoup de ces pièges ne viennent pas de l'outil lui-même, mais de détails qu'on a négligés.

D'abord, de quel outil s'agit-il

CyberStrikeAI se définit comme un « système d'action de cybersécurité IA-native », écrit en Go, qui réunit planification, exécution, supervision humaine, conservation des preuves et relecture dans un espace de travail auditable. Ses composants clés : des Agents propulsés par Eino, des outils natifs MCP, une base de connaissances RAG, des workflows visuels et une modélisation et analyse des chaînes d'attaque.

Il embarque plus de 100 recettes d'outils couvrant toute la kill chain : scan réseau avec nmap, masscan, rustscan ; scan web avec sqlmap, nikto, gobuster, ffuf ; scan de vulnérabilités avec nuclei, wpscan, dalfox ; sans oublier l'énumération de sous-domaines, la sécurité des API, la sécurité des conteneurs, la sécurité cloud, l'analyse binaire, l'exploitation, le cassage de mots de passe, la forensique, le post-exploitation, etc. Bref, tout l'attirail d'un test d'intrusion autorisé est déjà orchestré pour vous.

Il existe aussi un plugin Burp Suite et une extension de navigateur pour envoyer directement le trafic capturé vers la plateforme pour une analyse assistée par IA. Un design malin — votre workflow actuel reste inchangé.

Préparer l'environnement avant le déploiement

Deux prérequis officiels ; attention à ne pas passer sous les versions requises :

• Go 1.25+(version explicitement exigée dans le go.mod ; en dessous, la compilation échoue immédiatement)
• Python 3.10+(nécessaire pour certains outils, comme api-fuzzer et http-framework-test)

Piège n°1 : la version de Go. À mon premier essai, j'utilisais le vieux Go fourni avec le système, et l'erreur n'a surgi qu'à la compilation. Mieux vaut d'abord go version vérifier, et installer la nouvelle version depuis le site officiel si besoin. Ce genre de « prérequis » est le plus souvent négligé, car l'erreur n'apparaît que bien plus tard.

Déploiement en un clic : ce que le script fait pour vous

La commande officielle de déploiement en un clic est très concise :

git clone https://github.com/Ed1s0nZ/CyberStrikeAI.git
cd CyberStrikeAI
chmod +x run.sh && ./run.sh

Mais run.sh en fait plus que vous ne l'imaginez ; il exécute dans l'ordre :

• ✅ Vérifie et valide les environnements Go et Python
• ✅ Crée l'environnement virtuel Python
• ✅ Installe les dépendances Python
• ✅ Télécharge les dépendances Go
• ✅ Compile le projet
• ✅ Démarre le service

Détail n°1 : le venv est géré automatiquement par le script. Le répertoire venv/ est créé et maintenu automatiquement par run.sh, et les outils qui nécessitent Python (api-fuzzer, http-framework-test, etc.) l'utilisent automatiquement. Ne le créez pas à la main, au risque de conflits.

Vérifier le démarrage : les points à confirmer

Une fois le script terminé, ne vous précipitez pas sur le navigateur : regardez d'abord le terminal.

• Vérifiez que le terminal affiche ● ONLINE, suivi de l'adresse réelle de l'interface web
• Ouvrez cette adresse : en mode HTTPS par défaut, c'est un certificat auto-signé local ; le navigateur affiche un avertissement, acceptez-le une fois et c'est réglé
• Une nouvelle installation génère un mot de passe administrateur à usage unique : affiché dans le terminal sous ADMIN SETUP REQUIRED ; changez-le dès la connexion

Détail n°2 : HTTPS ou HTTP. run.sh démarre par défaut avec le paramètre –https (TLS auto-signé local ; officiellement, plus adapté aux flux concurrents). Si vous voulez du HTTP pur, il faut explicitement utiliser ./run.sh --http. Au démarrage manuel, ajoutez –https ou définissez la variable d'environnement CYBERSTRIKE_HTTPS=1.

En production, n'utilisez pas de certificat auto-signé : configurez server.tls_cert_path et server.tls_key_path dans config.yaml.

Piège n°2 : l'erreur de protocole incompatible. Si vous voyez « client sent an HTTP request to an HTTPS server » dans les logs, un client accède encore au port TLS via http://. Corrigez simplement l'URL, inutile de bricoler la configuration serveur.

Première configuration : le canal IA est indispensable

Sans cette étape, la plateforme est comme inexistante. Après le premier démarrage, ouvrez https://127.0.0.1:8080/ (le port doit correspondre à server.port dans config.yaml), puis allez dans System Settings → Basic Settings → AI Channel Configuration, ajoutez un canal et renseignez provider, Base URL, clé API, model et plafond de tokens.

Vous pouvez aussi modifier directement config.yaml ; le format ressemble à ceci :

ai:
default_channel: openai-main
channels:
openai-main:
provider: openai_compatible
api_key: “${OPENAI_API_KEY}”
base_url: “https://api.openai.com/v1”
model: “gpt-4o”

Détail n°3 : la portée du canal par défaut. ai.default_channel s'applique aux nouvelles sessions et aux tâches sans canal explicitement choisi ; dans la page de chat, vous pouvez aussi sélectionner par session n'importe quel canal sauvegardé. Avec plusieurs modèles, nul besoin de vous limiter à un seul.

En mettant openai_compatible dans provider, vous raccordez la plupart des services compatibles avec l'API OpenAI ; base_url peut devenir https://api.deepseek.com/v1 et model deepseek-chat, de même pour qwen3-max. Les modèles chinois se branchent sans contrainte — un vrai point positif.

⚠️ Avertissement sécurité : ne commitez pas de vraies clés dans config.yaml. Les développeurs le disent clairement : pas de vraies informations d'identification dans les commits, injectez-les via des variables d'environnement.

La mise à niveau aussi demande de la méthode

Un script de mise à niveau en un clic est fourni, mais il faut d'abord lui donner les droits d'exécution :

chmod +x upgrade.sh && ./upgrade.sh –yes

Ce qu'il fait : sauvegarder config.yaml et le répertoire data/ → récupérer le nouveau code depuis GitHub Release → mettre à jour le numéro de version dans config.yaml → redémarrer le service.Les répertoires locaux tools/, roles/ et skills/ sont toujours préservés — c'est essentiel : vos recettes d'outils personnalisées ne seront pas écrasées.

Piège n°3 : les dépendances du script de mise à niveau. Il a besoin de curl ou wget pour télécharger le paquet Release, et de rsync pour une synchronisation sûre du code (officiellement recommandé/requis). Si l'API GitHub est rate-limitée, attendez d'abord export GITHUB_TOKEN="..." avant de relancer.

En cas de problème, restaurez depuis .upgrade-backup/, ou recopiez manuellement data et config.yaml avant de relancer run.sh.

Principe important : avant toute mise à niveau, lisez impérativement les release notes de la version cible ; soyez d'autant plus prudent s'il y a des changements de configuration, de base de données ou d'API. Les développeurs le formulent sans détour — « la sauvegarde est obligatoire, même pour un simple correctif ; le numéro de version n'est pas en soi une garantie de compatibilité. »

Aperçu rapide de l'arborescence

Comprendre le rôle de chaque répertoire, c'est s'éviter de se perdre lors de la maintenance :

• cmd/ — serveur, point d'entrée MCP stdio, outils
• internal/ — Agents, cœur MCP, processeurs, C2, exécuteur sécurisé
• web/ — SPA statique et templates
• tools/ — recettes d'outils YAML (100+ exemples)
• roles/ — configurations de rôles (12+ rôles de tests de sécurité préconfigurés)
• skills/ — répertoire des Agent Skills (SKILL.md + fichiers optionnels)
• agents/ — multi-agents en Markdown (orchestrator.md + sous-Agents)
• config.yaml — configuration d'exécution
• run.sh / upgrade.sh — scripts de démarrage / de mise à niveau

La sécurité, aucun outil ne peut la faire à votre place

Cette plateforme intègre des capacités à haut risque comme la gestion de WebShells et un C2 intégré (listeners, beacons chiffrés, sessions, files de tâches). La position des développeurs est très claire : à n'utiliser que sur des systèmes que vous possédez ou pour lesquels vous avez une autorisation explicite de test.

Avant d'activer des outils à haut risque dans un environnement partagé ou de production, lisez impérativement le modèle de sécurité et le guide de durcissement. La plateforme embarque aussi une interception des appels d'outils — des vérifications par expressions régulières configurables avant l'exécution MCP, avec une protection des domaines gouvernementaux activée par défaut.

Par ailleurs, l'écoute par défaut se limite à 127.0.0.1 ; si vous exposez le service vers l'extérieur, durcissez impérativement d'abord. Ce n'est pas de la politesse : c'est le genre d'avertissement qu'on n'écrit dans la doc qu'en s'étant déjà brûlé.

Pour conclure

Avec le recul, ce déploiement n'a pas connu de vrai pépin : le script avait déjà fait 90 % du travail. Ce qui m'a réellement fait m'arrêter et fouiller la doc, ce sont des détails « passés inaperçus » : la version minimale de Go, le venv à ne pas créer à la main, le HTTPS activé par défaut provoquant l'incompatibilité de protocole, la sauvegarde avant mise à niveau, les clés à ne jamais mettre dans la configuration.

Pris isolément, chacun de ces détails est simple ; mais en en oublier un seul peut vous bloquer une demi-heure. Plus un outil est mature, plus « lire la doc » rapporte — la complexité est encapsulée dans le script, et le reste se niche dans les détails de configuration.

Le projet a rejoint knownsec 404Starlink et est open source sous licence Apache 2.0. Ceux qui font des tests de sécurité autorisés peuvent l'essayer.

Déployer en un clic ne revient pas à comprendre en un clic : ce sont les détails qui font vraiment gagner du temps.

Adresse du projet : github.com/Ed1s0nZ/CyberStrikeAI (migré vers github.com/AIPentest/CyberStrikeAI)
Prérequis : Go 1.25+ / Python 3.10+
Licence : Apache License 2.0
⚠️ Réservé aux tests autorisés