La cybersécurité offensive entre dans une nouvelle phase. Jusqu’à récemment, parler d’une équipe red autonome semblait relever du laboratoire, d’une promesse de fournisseur ou d’une présentation trop ambitieuse. Aujourd’hui, apparaissent progressivement des frameworks open source capables de chaîner reconnaissance, exploitation, post-exploitation, analyse des résultats et remédiation de code au sein d’une architecture locale basée sur des conteneurs.

RedAmon illustre parfaitement cette tendance. Le projet se présente comme un framework de red team autonome alimenté par l’IA, automatisant les opérations offensives depuis la reconnaissance jusqu’à la remédiation. Il intègre également CypherFix, une couche de remédiation capable de corréler les vulnérabilités, de cloner un référentiel, d’appliquer des modifications et d’ouvrir une pull request avec le patch proposé.

Pour un média technologique ou de serveurs, ce qui est surtout capital, ce n’est pas uniquement la composante IA. C’est l’architecture. RedAmon n’est pas une API distante que quelqu’un consomme sans connaître l’environnement d’exécution. C’est une plateforme conteneurisée déployée sur une infrastructure privée, avec des services séparés, des bases de données, un sandbox Kali, un graph Neo4j, PostgreSQL, des agents, des orchestrateurs, des outils de scan et la prise en charge de modèles externes ou locaux.

Ce détail change la donne. Le pentesting autonome cesse d’être simplement un service cloud et commence à apparaître comme une charge de travail que une équipe technique peut déployer dans son propre environnement. Mais le fait qu’un outil puisse s’installer sur un serveur ne garantit pas sa préparation pour la production sans un jugement éclairé.

Une stack offensive empaquetée dans des conteneurs

RedAmon est conçu autour de Docker et Docker Compose. La documentation indique qu’il n’est pas nécessaire d’installer Node.js, Python ou des outils de sécurité directement sur le système hôte. Tout fonctionne via des conteneurs, avec différents services pour l’application web, l’agent, l’orchestrateur de reconnaissance, la base de données, Neo4j, le sandbox Kali et des modules optionnels tels que GVM/OpenVAS ou une base de connaissances locale.

Une installation légère peut tourner avec 2 cœurs, 4 Go de RAM et 20 Go d’espace disque. Si GVM/OpenVAS est activé, les prérequis montent à 4 cœurs, 8 Go de RAM et 50 Go d’espace disque, avec 16 Go de RAM recommandés. Ces chiffres ne sont pas extravagants, mais ils démontrent qu’un pipeline offensif comprenant scanners, graphes, modèles et conteneurs dynamiques consomme des ressources et doit être planifié comme une charge sérieuse.

Cette architecture robuste permet une séparation claire des responsabilités. La reconnaissance peut s’exécuter en parallèle, les résultats s’organisent en graphes facilement consultables, l’agent prend des décisions avec le contexte, et les outils s’exécutent dans un environnement contrôlé. Elle introduit également une certaine complexité opérationnelle : gestion des volumes, permissions, secrets, mises à jour, ressources, logs, réseau interne, sortie vers Internet et isolation du système hôte.

Dans un contexte serveur, la question fondamentale n’est pas seulement si l’outil peut démarrer, mais comment il est administré et contrôlé.

Le serveur de pentest ne devrait pas être un serveur ordinaire

La documentation de RedAmon précise qu’il est conçu pour un usage en local, non sécurisé pour une exposition à Internet. Cette mention doit suffire à éviter de mauvaises décisions. Un framework capable de lancer reconnaissance, outils offensifs, agents, actions de post-exploitation ne doit pas être publié comme un simple panneau web accessible publiquement.

Il doit être traité comme un environnement de laboratoire ou une plateforme interne très sécurisée. En aucun cas, il ne faut l’exposer sur une VPS publique sans protection, le laisser derrière une simple authentication faible, le mêler à des serveurs de production ou donner un accès large à des réseaux non explicitement intégrés dans sa portée.

Dans un contexte professionnel, cette plateforme devrait fonctionner dans un réseau isolé, avec un accès limité via VPN ou bastion, une authentification forte, une segmentation, des journaux d’audit, des sauvegardes contrôlées, et une politique claire d’utilisation. Il est également conseillé de séparer l’environnement de RedAmon des charges critiques de l’entreprise. Non pas parce que RedAmon serait intrinsèquement dangereux, mais parce qu’une plateforme offensive autonome amplifie le risque si elle n’est pas strictement encadrée.

La documentation prévoit des mesures de sécurité telles que des garde-fous, des règles d’engagement, des confirmations manuelles pour des outils sensibles et des blocages pour certains domaines. Ce sont des étapes indispensables, mais le contrôle technique externe reste sous la responsabilité de celui qui déploie.

L’offensive automatisée, un marché en maturation ; operation reste complexe

RedAmon témoigne de l’évolution du marché. Plusieurs capacités qui demanderaient auparavant une équipe complète commencent à se trouver dans des frameworks open source : reconnaissance parallèle, scans avec outils connus, graphes d’attaque, agents de consultation contextuelle, modèles locaux ou distants, rapports et remédiation assistés par IA.

Cela ne supprime pas le travail de sécurité, mais le transforme.

L’essentiel ne sera plus seulement d’exécuter Nmap, Nuclei, OpenVAS, Metasploit ou Hydra, ni de se vanter d’utiliser de l’IA. Ces composants deviendront de plus en plus accessibles. La différence fondamentale résidera dans la conception d’un processus sécurisé, reproductible, auditable et réellement exploitable en production.

Un responsable sécurité (CISO) ne cherche pas uniquement « un moteur offensif », mais une infrastructure : périmètre défini, fenêtres d’exécution, contrôle de l’intensité, validation humaine, preuves, mémoire entre audits, priorisation selon le risque, intégration avec des dépôts, validation des correctifs et traçabilité jusqu’aux revues réglementaires ou internes.

Cette distinction est cruciale pour les entreprises souhaitant internaliser ces outils. Les déployer chez soi peut faire sens si l’équipe a l’expérience, les compétences et la capacité opérationnelle, mais si l’organisation doit gérer des dizaines d’outils, résoudre des incompatibilités, suivre des licences, ajuster des modèles et répondre aux incidents, le coût réel n’est plus nul.

Les logiciels libres suppriment la dépense de licence, mais pas celle de la responsabilité.

IA locale, modèles externes et souveraineté technique

Un aspect clé de RedAmon est le support pour divers fournisseurs de modèles : OpenAI, Anthropic, OpenRouter, AWS Bedrock et endpoints compatibles OpenAI comme Ollama, vLLM, LM Studio ou Groq. Cela permet de mixer modèles avancés avec des modèles locaux ou déployés en infrastructure propre.

Pour les équipes de serveurs, cette capacité est importante. Si un framework offensif doit envoyer des données sensibles, comme des charges utiles, des résultats ou des configurations à un fournisseur externe, se posent des questions de confidentialité, de conformité réglementaire et de dépendance. Tous les environnements ne peuvent pas faire cela. La possibilité d’utiliser des modèles locaux ou des endpoints auto-hébergés offre plus de contrôle, même si cela demande plus de ressources informatiques et de maintenance.

RedAmon intègre également une base de connaissances locale optionnelle, utilisant un pipeline RAG (Retrieval-Augmented Generation) pour consulter des datasets de sécurité avant de recourir à des recherches externes. Cela s’inscrit dans une tendance plus large : rapprocher l’intelligence du storage pour réduire coûts, latence et exposition.

L’approche hybride sera probablement la plus équilibrée : utiliser des modèles externes pour des raisonnements complexes ou des tâches à forte valeur ajoutée, tout en conservant des modèles locaux pour les requêtes répétitives, le classement, l’enrichissement ou les données sensibles. La clé sera de définir précisément ce qui doit rester dans l’environnement contrôlé et ce qui peut être externalisé.

Du laboratoire au service géré, il y a un saut considérable

L’enthousiasme face à des outils comme RedAmon peut pousser à croire qu’il suffit de déployer, de configurer des modèles et d’automatiser ses pentests. Pour apprendre ou tester des concepts c’est valable, mais dans un cadre professionnel, le vrai défi est différent.

Il faut définir qui peut lancer des tests, sur quels objets, avec quelle intensité, quelles approbations sont nécessaires, quels résultats sont acceptables, comment les preuves sont archivées, qui valide les pull requests, comment éviter que cela touche la production sans contrôle, et comment gérer un impact éventuel d’un scan.

Il faut également vérifier la compatibilité des licences. RedAmon est publié sous licence MIT, mais comporte des outils tiers sous autres licences. La documentation indique que WPScan a une licence spécifique et que certains usages commerciaux peuvent nécessiter une licence dédiée. En environnement géré, ces détails ne sont pas neutres.

Pour les fournisseurs d’infrastructure, MSP, MSSP ou équipes de plateforme, RedAmon est un signal clair : le futur de la sécurité offensive ne sera pas simplement des consultants exécutant des outils à la main, ni un agent autonome attaquant à tout va, mais un équilibre entre automatisation, gouvernance, contrôle et intervention humaine.

RedAmon montre que le moteur open source est là. La question qui reste est : qui sait construire une opération sécurisée autour ?

Questions fréquentes

Qu’est-ce que RedAmon ?
RedAmon est un framework open source de red team autonome, automatisant reconnaissance, exploitation, post-exploitation, analyse des résultats et remédiation par pull requests.

Il s’installe dans une infrastructure privée ?
Oui, conçu comme une plateforme conteneurisée basée sur Docker et Docker Compose, comprenant plusieurs services : webapp, agent, sandbox Kali, Neo4j et PostgreSQL.

Quels ressources sont nécessaires ?
Une installation légère nécessite 2 cœurs, 4 Go de RAM et 20 Go de disque. Avec GVM/OpenVAS, la recommandation monte à 4 cœurs, 8 Go de RAM et 50 Go, avec 16 Go conseillé.

Peut-elle être exposée sur Internet comme un simple tableau de bord ?
Ce n’est pas conseillé. La documentation indique qu’elle est conçue pour un usage local non exposé, et ne doit pas être publiée telle quelle en accès public.

Quelle valeur ajoutée par rapport à des outils séparés ?
Elle intègre outils, agents, graphe d’attaque, règles, mémoire entre sessions, rapports et remédiation, permettant une orchestration coordonnée plutôt qu’une simple exécution d’outils isolés.

Source : Open Security