Osmedeus: Workflow-Orchestrierung für Recon, mit YAML statt Shell-Skripten

Welche Lücke Osmedeus im Recon-Alltag schließt

Recon läuft in der Praxis selten als ein Skript. Subdomain-Enumeration, Portscan, HTTP-Probing und Schwachstellenprüfung greifen aufeinander zu, jedes Werkzeug liefert eigene Ausgabeformate, und irgendwann liegt der Zustand über mehrere Verzeichnisse und Rechner verteilt. Osmedeus setzt genau dort an und beschreibt Pipelines deklarativ als YAML statt als Bash-Kette. Die README nennt Hooks, Entscheidungsrouting, Modulausschluss und bedingte Verzweigungen als Bestandteile dieser Definitionen. Der Adressat ist damit ein Team, das dieselbe Abfolge wiederholt fahren und nachvollziehbar halten will, nicht jemand, der einmalig einen Host prüft. Die Themenliste des Repositories (attack-surface-management, reconnaissance, pentesting) deckt sich mit dieser Ausrichtung. Ein Punkt, den die README offen lässt: wie ein konkreter Workflow im YAML aussieht. Wer die Syntax sehen will, muss in die Dokumentation unter docs.osmedeus.org wechseln.

Module, Flows und die Frage, was der Unterschied ist

Die CLI trennt zwei Ausführungsarten. Der Aufruf osmedeus run -m recon -t example.com startet ein Modul, osmedeus run -f general -t example.com einen Flow. Die README erklärt nicht, wodurch sich beide unterscheiden, und das ist keine Kleinigkeit: Wer Pipelines baut, muss wissen, ob ein Modul eine einzelne Stufe oder eine ganze Kette bezeichnet. Aus den Beispielen lässt sich nur ableiten, dass Module sich aus einem Flow ausschließen lassen, und zwar exakt per -x portscan oder unscharf per Substring mit -X vuln. Das legt nahe, dass Flows Module zusammenfassen und Module die kleinere Einheit sind. Bestätigen lässt sich das aus dem vorliegenden Material nicht. Wer Osmedeus einführt, sollte diese Frage vor dem ersten eigenen Workflow klären, weil davon abhängt, wo Wiederverwendung sinnvoll ist und wo nicht.

Verteilte Ausführung: Redis, Queue und Worker

Für mehr als einen Rechner nennt die README ein Master-Worker-Muster auf Redis-Basis mit Queue, Webhook-Triggern und Dateisynchronisation zwischen Workern. Der Ablauf in der Praxis beginnt mit dem Einreihen: osmedeus worker queue new -f general -t example.com legt eine Aufgabe an, osmedeus worker queue run --concurrency 5 arbeitet sie ab. osmedeus worker status zeigt die vorhandenen Worker. Das ist ein Muster mit spürbaren Konsequenzen: Redis wird zur kritischen Komponente, und die Dateisynchronisation zwischen Workern bedeutet, dass Zwischenergebnisse über das Netz wandern. Die README spricht außerdem von verschlüsselter Datenhaltung und sicherem Umgang mit Zugangsdaten, ohne zu sagen, welche Verschlüsselung gemeint ist oder wo Schlüssel liegen. Wer Schwachstellen-Scans über gemietete Infrastruktur fährt, sollte das vor dem Produktivbetrieb selbst prüfen, weil die Aussage allein keine Auskunft über das Bedrohungsmodell gibt.

Funktionen, Agenten und Cloud: die breite Flanke

Die README beziffert die Funktionsbibliothek mit über 80 Hilfsfunktionen, darunter nmap-Integration, tmux-Sitzungen, SSH-Ausführung, TypeScript- und Python-Skripting, SARIF-Parsing sowie CDN- und WAF-Klassifizierung. Einzelne Funktionen lassen sich direkt auswerten: osmedeus func eval 'log_info("hello")' oder mit Eingabeliste osmedeus func eval -e 'http_get("https://example.com")' -T targets.txt -c 10. In der Auswertung stehen Plattformvariablen wie PlatformOS und PlatformArch zur Verfügung, was den Beispielaufruf osmedeus func eval 'log_info("OS: " + PlatformOS + ", Arch: " + PlatformArch)' erklärt. Daneben stehen Agentenschritte mit Werkzeugaufrufen und Sub-Agenten sowie ACP-Subprozess-Agenten für Claude Code, Codex, OpenCode und Gemini, aufrufbar über osmedeus agent "analyze this codebase" oder osmedeus agent --agent codex "explain main.go". Für Cloud-Umgebungen nennt die README DigitalOcean, AWS, GCP, Linode und Azure mit Kostenkontrollen und automatischer Aufräumung, sichtbar an osmedeus cloud create --instances 3 und osmedeus cloud setup 1. Das ist eine ungewöhnlich breite Fläche für ein einzelnes Werkzeug. Ob die Agentenschritte deterministisch genug für wiederholbare Prüfungen sind, sagt die README nicht, und genau das wäre für einen Audit-Trail die entscheidende Frage.

Installation und die erste Ausführung

Der schnellste Weg laut README ist das Skript: curl -sSL http://www.osmedeus.org/install.sh | bash. Alternativ gibt es ein npm-Paket, npm install -g @j3ssie/osmedeus, das vorgebaute Binärdateien für Linux und macOS auf x64 und arm64 mitbringt. Für den Einstieg nennt die README osmedeus install base --preset und osmedeus install workflow --preset, wobei --keep-setting eine vorhandene osm-settings.yaml erhält. Dieser Schalter ist wichtig, sobald man eigene Anpassungen in der Konfigurationsdatei vorgenommen hat, weil ein erneutes Installieren sie sonst überschreiben kann. Vor dem ersten echten Lauf lässt sich mit --dry-run eine Vorschau erzeugen: osmedeus run -f general -t example.com --dry-run. Mehrere Ziele gehen über eine Datei, osmedeus run -m recon -T targets.txt -c 5, wobei -c die Nebenläufigkeit setzt. Wer den Server startet, bekommt REST-API, Webhook-Trigger und ein eingebettetes Dashboard über osmedeus serve. Auffällig ist, dass das Installationsskript über HTTP statt HTTPS geladen wird. Das ist ein Detail, das man beim eigenen Rollout ersetzen sollte.

Abfragen: die Datenbank als eigentliches Produkt

Osmedeus sammelt Ergebnisse in einer Datenbank und macht sie über die CLI zugänglich. osmedeus assets -w example.com listet Assets eines Workspace, osmedeus assets --stats zeigt eindeutige Technologien, Quellen und Typen, und mit --source httpx --type web --json kommt gefilterte Ausgabe im JSON-Format. Für Befunde gibt es osmedeus query vulns --severity high --workspace example.com, für Läufe osmedeus query runs --status running, für einzelne Schritte osmedeus query steps --run <run-uuid>. Direkt in Tabellen liest osmedeus db list --table runs oder mit Suche osmedeus db list --table event_logs --search "nuclei". Dass Tabellen wie runs und event_logs namentlich auftauchen, zeigt, worauf Osmedeus seinen Zustand ablegt: in einer eigenen Datenbank, nicht in Dateien im Workspace-Verzeichnis. Das ist der eigentliche Unterschied zu einer Skriptsammlung. Es bedeutet aber auch, dass der Zustand an diese Datenbank gebunden ist. Wer Workspaces zwischen Rechnern teilt oder Sicherungen plant, muss die Datenbank mitnehmen, nicht nur das Ausgabeverzeichnis. Wie Migrationen zwischen Versionen ablaufen, steht in der README nicht.

Grenzen und der Fall, in dem Osmedeus zu groß ist

Die README ist eine Funktionsliste mit Beispielaufrufen. Sie beschreibt kein Fehlerverhalten. Was passiert, wenn ein Worker mitten im Lauf ausfällt, ob die Queue Aufgaben wiederholt oder verwirft, wie sich ein abgebrochener Lauf fortsetzen lässt: dazu findet sich im vorliegenden Material nichts. Auch zur Laufzeit einzelner Schritte oder zum Ressourcenbedarf der Datenbank macht die README keine Angaben. Ein zweiter Punkt betrifft die Zielgruppe. Wer einmal pro Woche einen Host prüft, zahlt mit Osmedeus für Datenbank, Worker-Konfiguration, Modul-Repository und Konfigurationsdatei osm-settings.yaml einen laufenden Betriebsaufwand, der in keinem Verhältnis zum Nutzen steht. Ein einzelnes Skript plus die aufgerufenen Werkzeuge ist dort die bessere Wahl. Und wer ausschließlich mit einem festen Satz von Werkzeugen arbeitet, die bereits eine eigene Pipeline mitbringen, gewinnt durch die YAML-Schicht wenig, weil die Integration selbst gebaut werden muss.

Der Vergleich mit einem reinen Skript-Orchestrator

Der naheliegende Gegenentwurf ist ein generischer Workflow-Runner, der beliebige Shell-Schritte in einem DAG ausführt. Der Unterschied liegt weniger in der Ausführung als in der Umgebung: Osmedeus bringt eine Datenbank für Assets, Läufe und Schritte mit, dazu 80+ sicherheitsspezifische Funktionen wie nmap-Integration, SARIF-Parsing und CDN/WAF-Klassifizierung. Ein generischer Runner müsste diese Auswertung selbst bekommen, und die Ergebnisse müssten in ein eigenes Schema geschrieben werden. Umgekehrt ist der generische Runner nicht auf Sicherheits-Recon festgelegt und kennt keine Worker-Queue mit Dateisynchronisation. Die Entscheidung hängt damit an einer Frage: Soll der Zustand in einer mitgelieferten Sicherheits-Datenbank liegen, die man abfragen kann, oder in Artefakten, die man selbst auswertet? Osmedeus beantwortet das zugunsten der Datenbank, und das prägt den gesamten Betrieb.

Wartung, Versionen und Lizenz

Das Repository ist nicht archiviert, und die letzten drei Veröffentlichungen liegen bei v5.0.2, v5.0.3 und v5.1.0, wobei v5.1.0 und v5.0.3 rund zweieinhalb Monate auseinanderliegen. Das deutet auf eine gepflegte Codebasis hin, mehr lässt sich daraus nicht ableiten. Für die Wartung relevant ist die Struktur: Workflows, Module und Einstellungen liegen außerhalb des Binaries und werden über osmedeus install workflow --preset bezogen. Ein Upgrade des Binaries aktualisiert diese Bestandteile nicht automatisch, und ein erneutes --preset-Installieren kann lokale Anpassungen überschreiben, sofern --keep-setting fehlt. Wer eigene Workflows pflegt, sollte deshalb versionieren, was in den Presets steckt, und nach jedem Upgrade prüfen, ob die eigenen Definitionen noch greifen. Die Lizenz ist MIT. Das erlaubt Weitergabe und Änderung, verlangt aber, den Urheberrechts- und Lizenzhinweis beizubehalten. Wer Osmedeus in ein eigenes Produkt einbettet, sollte den Hinweis sichtbar platzieren. Das ist eine technische Einordnung, keine Rechtsberatung; für den eigenen Fall gehört sie ohnehin vor die Freigabe.

Redaktionelles Fazit

Für Teams, die Recon-Schritte reproduzierbar in YAML festschreiben und über mehrere Maschinen verteilen wollen, ist Osmedeus eine naheliegende Wahl, sofern die Lizenz MIT für die eigene Weitergabe passt. Wer nur ein einzelnes Skript gelegentlich startet, trägt mit Datenbank, Worker-Queue und Modul-Repository mehr Betriebslast als Nutzen. Vor dem produktiven Einsatz sollte man klären, welche Daten Osmedeus in seiner Datenbank ablegt, wie ein Upgrade von v5.0.3 auf v5.1.0 mit bestehenden Workspaces umgeht und ob die Standard-Workflows fachlich zu den eigenen Zielen passen.

Offizielle Quellen

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