Osmedeus : orchestrer le recon en YAML, sans magie

Le problème : des scripts de recon qui ne sont ni relus ni rejoués

Un pipeline de reconnaissance classique finit en scripts shell enchaînés, avec des chemins en dur, des variables exportées à la main et aucune trace de ce qui a tourné. Osmedeus part d'un constat simple : si le pipeline est décrit dans un fichier YAML, il devient lisible, différable et rejouable. Le projet vise donc les pentesters, les équipes de bug bounty et les responsables de la surface d'attaque qui doivent relancer régulièrement la même séquence sur des cibles changeantes, et qui veulent pouvoir dire ce qui a été exécuté, avec quels paramètres. Le README parle d'automatisation composable sans sacrifier l'intégrité de l'infrastructure, ce qui situe clairement la cible : des gens qui exécutent déjà beaucoup d'outils et cherchent à les envelopper dans un cadre commun, pas des débutants qui attendent un résultat sans rien configurer.

Ce que le YAML décrit vraiment

Les workflows Osmedeus sont des définitions YAML qui portent des hooks, du routage conditionnel, de l'exclusion de modules et des branchements. Le README distingue deux formes : les modules, lancés avec l'option -m, et les flows, lancés avec -f. Un flow peut exclure des modules, soit par nom exact avec -x portscan, soit par sous-chaîne avec -X vuln. Cette nuance compte en pratique : sur un pipeline long, on veut souvent retirer une famille entière d'étapes sans réécrire le flow. Le moteur expose aussi une bibliothèque de plus de 80 fonctions utilitaires, dont l'intégration nmap, les sessions tmux, l'exécution SSH, le scripting TypeScript et Python, l'analyse SARIF et la classification CDN ou WAF. Ces fonctions sont évaluables directement en ligne de commande, par exemple osmedeus func eval 'log_info("hello")', ce qui donne un moyen de tester un fragment de logique sans lancer un workflow complet. C'est probablement l'aspect le plus utile pour déboguer une définition récalcitrante.

Exécution locale, Docker, SSH, puis Redis

Le moteur sait exécuter une étape sur l'hôte, dans Docker ou via SSH, ce qui évite d'écrire trois variantes du même pipeline selon l'environnement. Au-delà d'une machine, Osmedeus bascule sur un schéma maître-ouvrier appuyé sur Redis, avec file d'attente, déclencheurs webhook et synchronisation de fichiers entre les ouvriers. Les commandes correspondantes sont explicites : osmedeus worker queue new -f general -t example.com met une tâche en file, osmedeus worker queue run --concurrency 5 la consomme, osmedeus worker status liste les ouvriers. La planification repose sur cron, la surveillance de fichiers et des déclencheurs événementiels, avec filtrage, déduplication et file différée. Notez que Redis devient alors une dépendance d'infrastructure à part entière : sa disponibilité conditionne l'exécution distribuée, et le README ne décrit pas de mode de repli si le courtier tombe. C'est un choix d'architecture classique, mais il déplace le point de défaillance du workflow vers un service externe.

Les étapes LLM agentiques, entre promesse et flou

Osmedeus intègre des étapes dites agentiques : boucles d'agent avec appel d'outils, orchestration de sous-agents, gestion de mémoire et sortie structurée. Le projet mentionne aussi des agents ACP en sous-processus, avec Claude Code, Codex, OpenCode et Gemini, lancés via osmedeus agent "analyze this codebase" ou osmedeus agent --agent codex "explain main.go". Le README ne précise pas quel fournisseur de modèle est utilisé par défaut, ni comment les clés d'API sont fournies, ni ce qui se passe quand un agent échoue en cours de boucle. Ces questions ne sont pas anecdotiques pour un outil de sécurité : une étape agentique qui consomme un budget d'appels sans plafond visible dans la documentation publique est difficile à intégrer dans un pipeline facturé à l'usage. À traiter comme une fonctionnalité à valider soi-même sur la documentation en ligne avant de la mettre en production.

Installation et mise en route

Deux voies sont documentées. La première est un script d'installation : curl -sSL http://www.osmedeus.org/install.sh | bash. La seconde passe par npm, avec npm install -g @j3ssie/osmedeus, qui livre des binaires précompilés pour linux et macOS en x64 et arm64. Les workflows et les réglages s'installent depuis des dépôts prédéfinis : osmedeus install base --preset, avec l'option --keep-setting pour conserver un osm-settings.yaml existant, puis osmedeus install workflow --preset. Une fois en place, osmedeus run -m recon -t example.com lance un module, osmedeus run -f general -t example.com un flow, et --dry-run affiche un aperçu sans exécuter. Le serveur d'API démarre avec osmedeus serve, qui expose aussi une interface web et des déclencheurs webhook. Côté interrogation des résultats, osmedeus assets -w example.com liste les actifs d'un espace de travail, osmedeus query vulns --severity high --workspace example.com filtre les vulnérabilités, et osmedeus db list --table runs parcourt les tables. La commande osmedeus workflow list reste le point de départ le plus sûr pour savoir ce qui est réellement disponible après installation.

Ce que le README ne dit pas

Le README annonce une gestion chiffrée des données et des identifiants sécurisés, mais ne détaille ni l'algorithme, ni le format de stockage, ni la procédure de rotation des clés. Pour un outil qui manipule des identifiants d'accès à des cibles et à des fournisseurs cloud, c'est l'information la plus importante à obtenir avant tout déploiement, et elle n'est pas dans le matériel fourni. Même remarque sur le provisionnement cloud : osmedeus cloud create --instances 3 et osmedeus cloud setup 1 sont documentés, avec mention de contrôles de coût et de nettoyage automatique, sans que le mécanisme de plafonnement soit décrit. Un outil qui crée des machines chez DigitalOcean, AWS, GCP, Linode ou Azure engage une facture réelle ; savoir ce qui arrête une campagne oubliée n'est pas un détail. Enfin, rien n'indique dans le README comment se comporte le moteur quand une fonction utilitaire échoue au milieu d'un flow : reprise, arrêt, ou poursuite silencieuse. C'est une lacune de documentation, pas nécessairement un défaut du logiciel, mais elle conditionne la confiance qu'on peut accorder à un pipeline non surveillé.

Face à un simple Makefile ou à un orchestrateur généraliste

L'alternative la plus directe n'est pas un autre outil de sécurité : c'est un Makefile ou un script shell avec des cibles nommées. La différence tient au modèle d'exécution. Un Makefile décrit des dépendances entre fichiers et s'arrête là ; Osmedeus décrit des étapes avec hooks, routage conditionnel, exécution distante et file d'attente persistante, et conserve les résultats dans une base interrogeable via osmedeus query et osmedeus db list. En contrepartie, un Makefile n'exige ni Redis, ni base de données, ni installation de workflows prédéfinis. Si votre pipeline tient en cinq commandes enchaînées sur une seule machine, Osmedeus ajoute une couche de configuration dont vous ne tirerez pas parti. Un orchestrateur généraliste comme Airflow ou Argo Workflows se situe à l'autre extrémité : il excelle sur la planification et l'observabilité de tâches hétérogènes, mais n'apporte ni bibliothèque de fonctions orientées sécurité, ni classification CDN ou WAF, ni étapes agentiques. Le choix se joue donc sur une question précise : avez-vous besoin des fonctions intégrées et du modèle maître-ouvrier, ou seulement d'un ordonnanceur ?

Maintenance, licence et coût de mise à jour

Le projet est publié sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de copyright et le texte de la licence. Aucune clause de copyleft ne contraint donc vos workflows propriétaires. Le rythme de publication observé sur les releases récentes montre des versions rapprochées entre v5.0.2, v5.0.3 et v5.1.0, ce qui suggère un projet actif, sans que cela dise quoi que ce soit de la stabilité des interfaces. C'est justement le coût à anticiper : les workflows YAML et le fichier osm-settings.yaml sont des artefacts que vous allez versionner, et une montée de version majeure peut les rendre incompatibles. L'option --keep-setting de osmedeus install base --preset existe précisément parce que l'installation écrase les réglages par défaut. La bonne pratique ici est de garder vos définitions dans un dépôt Git séparé de l'installation, et de tester une montée de version avec osmedeus run -f <flow> -t <cible> --dry-run avant de l'appliquer à vos cibles réelles. Le README ne publie pas de politique de compatibilité entre versions majeures ; considérez que la charge de vérification vous revient.

Conclusion éditoriale

Osmedeus convient aux équipes qui veulent décrire un pipeline de recon ou de scan en YAML versionné, avec exécution locale, Docker ou SSH, et qui acceptent de lire la documentation en ligne avant de s'engager. Il ne convient pas à qui cherche un scanner clé en main : Osmedeus orchestre des outils, il n'en embarque pas la logique de détection. Avant adoption, vérifier le contenu réel de osm-settings.yaml et la façon dont les secrets sont gérés, car le README les mentionne sans détailler le mécanisme.

Sources officielles

1. j3ssie/osmedeus on GitHub
2. License: MIT
3. Project website
4. README
5. Releases