Un framework open source qui automatise la reconnaissance, l’exploitation, la post-exploitation et la remédiation — le tout en conteneurs, sur un serveur que vous gérez vous-même. RedAmon est arrivé sur GitHub avec une promesse concrète : concentrer la capacité d’une équipe red dans une seule architecture locale basée sur Docker.

C’est l’aspect qui mérite attention, au-delà du marketing IA. RedAmon n’est pas une API distante ni un service SaaS. C’est une plateforme conteneurisée déployée dans votre propre infrastructure, avec des services séparés, un sandbox Kali, un graphe Neo4j, PostgreSQL, des agents LangGraph, un orchestrateur de reconnaissance et une couche de remédiation baptisée CypherFix capable de cloner un dépôt, appliquer des modifications et ouvrir une pull request avec le patch proposé.

Ce choix architectural change la situation. Le pentesting autonome sort du cloud et peut désormais vivre dans votre propre réseau.

Une stack offensive complète, empaquettée en conteneurs

RedAmon fonctionne sur Docker et Docker Compose. Pas besoin d’installer Node.js, Python ou des outils de sécurité directement sur le système hôte — tout passe par les conteneurs, avec une séparation nette des services.

Une installation légère tourne avec 2 cœurs CPU, 4 Go de RAM et 20 Go de disque. Avec GVM/OpenVAS activé, les prérequis montent à 4 cœurs, 8 Go de RAM et 50 Go de stockage (16 Go recommandés). Ces chiffres montrent qu’un pipeline offensif avec scanners, graphes et modèles consomme des ressources réelles — ce n’est pas quelque chose qu’on range dans un coin d’une VM partagée.

L’architecture sépare les responsabilités : la reconnaissance tourne en parallèle, les résultats s’organisent en graphes consultables, l’agent décide avec le contexte complet, et les outils s’exécutent dans un sandbox isolé. C’est exactement le type de séparation qu’on attend d’une infrastructure sécurisée, comparable à ce que font les outils de gouvernance de l’infrastructure IA en entreprise.

Un outil puissant qui ne doit pas être exposé sur Internet

La documentation de RedAmon est explicite : il est conçu pour un usage en local, non préparé pour une exposition à Internet. Un framework capable de chaîner reconnaissance, outils offensifs, agents autonomes et actions de post-exploitation ne peut pas être publié comme un tableau de bord web accessible publiquement.

Les erreurs à éviter sont prévisibles : le déployer sur une VPS publique sans protection, se contenter d’une authentification faible, le mêler à des serveurs de production, ou lui donner accès à des réseaux non définis dans son périmètre.

Dans un contexte professionnel, ce type de plateforme doit vivre dans un réseau isolé, avec un accès limité via VPN ou bastion, une authentification forte, une segmentation réseau stricte, des journaux d’audit et une politique d’utilisation documentée. RedAmon intègre des garde-fous dans son code — règles d’engagement, confirmations manuelles pour les outils sensibles, blocages de domaines. Mais le contrôle de l’environnement reste sous la responsabilité de celui qui déploie.

Le moteur est open source ; l’opérationnel, lui, a un coût

RedAmon illustre une évolution de marché réelle. Plusieurs capacités qui nécessitaient auparavant une équipe complète se retrouvent dans des frameworks open source : reconnaissance parallèle, graphes d’attaque, agents contextuels, modèles locaux ou distants, rapports et remédiation assistée par IA.

Mais cela ne supprime pas le travail de sécurité. Nmap, Nuclei, OpenVAS ou Metasploit sont déjà courants. Ce qui distinguera les équipes demain, c’est leur capacité à construire un processus reproductible et auditable : périmètre défini, fenêtres d’exécution, validation humaine, preuves archivées, intégration avec les dépôts de code, traçabilité pour les revues réglementaires.

Un CISO qui évalue un tel outil ne cherche pas un moteur offensif. Il cherche une infrastructure. Et comme le montrent les difficultés que rencontrent les CIO avec l’IA agissante dans l’entreprise, ajouter une plateforme offensive autonome sans gouvernance clairement définie ne ferait qu’aggraver le problème de visibilité.

IA locale, modèles externes et contrôle des données

RedAmon prend en charge plusieurs fournisseurs de modèles : OpenAI, Anthropic, OpenRouter, AWS Bedrock, et des endpoints compatibles OpenAI comme Ollama, vLLM, LM Studio ou Groq. Cette flexibilité soulève une question concrète : vos données de test — charges utiles, résultats de scan, configurations — peuvent-elles sortir vers un fournisseur externe ?

Tous les environnements ne peuvent pas l’accepter. La possibilité de brancher des modèles locaux ou auto-hébergés offre plus de contrôle, au prix de ressources supplémentaires et d’une maintenance plus lourde. RedAmon ajoute aussi une base de connaissances locale optionnelle via RAG, qui interroge des datasets de sécurité avant de recourir à des sources externes — une façon de limiter l’exposition des requêtes sensibles.

L’approche hybride sera probablement la plus viable : modèles externes pour les raisonnements complexes, modèles locaux pour les requêtes répétitives et les données sensibles. Définir ce qui peut sortir et ce qui reste dans l’environnement contrôlé est une décision d’architecture à prendre avant le déploiement, pas après.

Du laboratoire au service géré : un saut qui demande de la rigueur

Déployer RedAmon pour expérimenter des concepts offensifs est tout à fait valable. En contexte professionnel, les exigences sont différentes : qui peut lancer des tests, sur quels périmètres, avec quelle intensité, quelles validations sont requises, comment les preuves sont archivées, qui révise les pull requests générées automatiquement, et comment éviter qu’une session de test touche la production par inadvertance.

RedAmon est publié sous licence MIT, mais intègre des outils tiers sous d’autres licences. WPScan, notamment, a une licence spécifique et certains usages commerciaux nécessitent une licence dédiée. En environnement géré ou pour un MSSP, ce détail n’est pas anodin.

Pour les équipes de sécurité interne, MSP, MSSP ou intégrateurs, RedAmon envoie un signal clair : le moteur open source de la sécurité offensive est disponible, accessible et fonctionnel. La question n’est plus de savoir si l’automatisation offensive est possible. La question est de savoir 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 déployé en conteneurs Docker, qui automatise reconnaissance, exploitation, post-exploitation, analyse des résultats et remédiation via pull requests grâce à sa couche CypherFix.

RedAmon s’installe dans une infrastructure privée ?

Oui. C’est une plateforme conteneurisée basée sur Docker Compose, avec des services séparés : webapp, agent, sandbox Kali, Neo4j, PostgreSQL et modules optionnels. L’infrastructure reste entièrement sous votre contrôle.

Quelles ressources matérielles faut-il pour faire tourner RedAmon ?

Une installation légère demande 2 cœurs CPU, 4 Go de RAM et 20 Go de disque. Avec GVM/OpenVAS activé, les prérequis montent à 4 cœurs, 8 Go de RAM (16 Go recommandés) et 50 Go de stockage.

Peut-on exposer RedAmon directement sur Internet ?

Non. La documentation indique qu’il est conçu pour un usage local, non sécurisé pour une exposition à Internet. Il doit être déployé dans un réseau isolé avec accès VPN ou bastion, authentification forte et segmentation réseau.

Quels modèles d’IA RedAmon supporte-t-il ?

OpenAI, Anthropic, OpenRouter, AWS Bedrock, et des endpoints compatibles OpenAI comme Ollama, vLLM, LM Studio ou Groq. Des modèles locaux ou auto-hébergés sont possibles pour les environnements avec contraintes de confidentialité.

Source : Open Security