osmedeus v5.1.0レビュー: YAMLで宣言する偵察ワークフローとその実行基盤

osmedeusが埋めるのは「手順の再現性」という穴

偵察作業は、サブドメイン列挙、ポートスキャン、HTTPプローブ、スクリーンショット、脆弱性スキャンといった工程を、対象ごとに同じ順序で回す必要がある。ところが実際の現場では、シェルスクリプト、履歴、個人のメモが混在し、半年後に同じ手順を再現できないことが多い。osmedeusはこの工程をYAMLのワークフロー定義として固定し、実行そのものはローカル、Docker、SSH、クラウドのいずれかで行う。READMEはこれを「declarative orchestration engine」と表現し、対象は初心者から熟練者までとしている。向いているのは、偵察の型を持ち、それをチームで共有したい個人や小規模チームだ。逆に、対象が1つで済む単発の調査には、この層を挟む価値は薄い。

ワークフローはmoduleとflowに分かれ、実行先を選べる

READMEの例では、実行単位が2種類ある。osmedeus run -m recon -t example.com がmodule、osmedeus run -f general -t example.com がflowである。moduleは個別の処理単位、flowは複数moduleをつなぐ上位の流れと読める。flowにはmoduleの除外指定があり、-x portscan で名前を指定して外し、-X vuln で部分一致によりまとめて外す。つまり、同じflowを対象ごとに調整して回せる。実行先はhost、Docker、SSHの複数runnerに対応すると記載されている。宣言したYAMLと、実際に走る場所を分離するのがこの設計の中心で、ローカルで検証したflowをそのままSSH先やクラウドへ移せる。ただし、どのrunnerを使う場合でも対象側に必要なツールが揃っている必要があり、YAMLを移せば環境も移るわけではない。

Redisを介したmaster-workerと、キューに積む実行モデル

分散実行はRedisベースのmaster-workerパターンで、キュー、Webhookトリガー、worker間のファイル同期を備えるとREADMEは説明している。手元で試す流れとしては、osmedeus worker queue new -f general -t example.com で後から処理するタスクを積み、osmedeus worker queue run --concurrency 5 で並列度を指定して処理する。osmedeus worker status でworkerの状態を確認でき、osmedeus worker eval -e 'ssh_exec("host", "whoami")' のように分散フック付きで関数を評価する例も載っている。キューを挟む利点は、対象の追加と実行を切り離せることだ。大量の対象を夜間に流す、といった運用が成立する。一方で、Redisが単一障害点になる構成である以上、可用性の設計はエンジン側ではなく利用者側の責任になる。

80以上の関数と、ACLエージェントという別系統の実行

関数ライブラリは80以上とされ、nmap連携、tmuxセッション、SSH実行、TypeScript/Pythonスクリプト、SARIF解析、CDN/WAF判定が挙げられている。関数は単体で評価でき、osmedeus func eval 'log_info("hello")' のように確認できる。外部通信を伴うものは osmedeus func eval -e 'http_get("https://example.com")' -T targets.txt -c 10 のように対象ファイルと並列度を渡す。PlatformOSやPlatformArchといった変数もeval内で参照できる。これに加えて、v5系ではエージェント的なLLMステップが入り、ツール呼び出しループ、サブエージェント、メモリ、構造化出力を扱うとされる。ACPサブプロセスエージェントとしてClaude Code、Codex、OpenCode、Geminiを呼べる。osmedeus agent --list で一覧を確認できる。ただし、これらのエージェント実行は外部モデルや外部CLIへの依存を意味し、再現性はモデル側の挙動に左右される。決定的な偵察工程と、確率的な解析工程は、同じflowに混ぜる前に分けて考えたほうがよい。

導入はinstallスクリプトかnpm、設定はpresetで入る

導入経路は2つ示されている。curl -sSL http://www.osmedeus.org/install.sh | bash を実行する方法と、npm install -g @j3ssie/osmedeus で入れる方法である。npm版はlinuxとmacOSのx64/arm64向けビルド済みバイナリを同梱すると記載されている。初期化はpresetから行い、osmedeus install base --preset でbaseを、osmedeus install workflow --preset でworkflowを入れる。既存設定を残したい場合は osmedeus install base --preset --keep-setting を使う。設定ファイルはosm-settings.yamlで、このファイルに認証情報が集まる設計だ。READMEは暗号化されたデータ処理と安全な認証情報管理、サンドボックス実行を特徴として挙げているが、具体的な暗号化方式や鍵の保管場所はこの抜粋からは確認できない。導入手順そのものは短いが、--keep-settingの存在が示すとおり、再インストール時に設定を上書きする挙動がある点は把握しておきたい。

確認と可視化のためのCLIとAPI

実行後の確認手段が比較的厚い。osmedeus assets -w example.com でワークスペース単位のアセットを一覧し、--stats で技術、ソース、種別の集計を見る。--source httpx --type web --json のように絞り込みとJSON出力ができる。脆弱性や実行履歴は osmedeus query vulns --severity high --workspace example.com、osmedeus query runs --status running、osmedeus query steps --run <run-uuid> で引く。生のテーブルを見るなら osmedeus db list --table runs、osmedeus db list --table event_logs --search "nuclei" といった形になる。osmedeus serve でAPIサーバーとWeb UIを起動でき、Webhookトリガーとダッシュボードを備える。ここで注意したいのは、これらのクエリがワークスペースという単位に依存していることだ。対象の命名規則が乱れると、後から資産を追う作業が一気に難しくなる。

クラウド調達まで踏み込む代わりに、依存と費用を引き受ける

osmedeus cloud create --instances 3 でDigitalOcean、AWS、GCP、Linode、Azure上にマシンを用意し、osmedeus cloud setup 1 でセットアップする流れが示されている。スキャン基盤の調達と後片付けまでをエンジン側で扱う点は、他ツールとの差別化になっている。ただし、これはクラウド事業者のAPIキーと課金をosmedeusの設定に預けることを意味する。READMEはコスト管理と自動クリーンアップに触れているが、その閾値や失敗時の挙動は抜粋からは読み取れない。クラウド実行を試すなら、まず--instances 1で作成から削除までを一通り確認し、残存リソースが出ないことを自分の目で確かめるのが順当だ。

代替としてのnmap/httpx直叩きと、その使い分け

比較対象として素直なのは、nmapやhttpx、nucleiといった個別ツールをシェルスクリプトで束ねる運用だ。違いは抽象化の層にある。シェルスクリプトは実行環境そのものを前提にするため、SSH先やコンテナへ移すには書き直しが要る。osmedeusは実行先をrunnerとして外に出し、手順はYAMLに残す。ワークフローのlintや--dry-runによる事前確認、実行履歴のDB記録も、この層があるから成立する。逆に、ツールのバージョン差分を吸収するのは利用者の仕事で、YAMLを書いてもnmapのオプション知識が不要になるわけではない。手順がまだ固まっていない段階では、シェルで試してからYAMLに移す順序のほうが無駄が少ない。

MITライセンスと、更新に伴う追従コスト

ライセンスはMITで、リポジトリはアーカイブされていない。直近のリリースはv5.1.0、v5.0.3、v5.0.2で、v5系の更新が続いている。MITであれば改変と再配布の制約は緩いが、同梱する外部ツールやクラウド事業者の規約は別に効く。ここは法的助言ではなく、確認事項として挙げておく。追従コストで見ておきたいのは、v5系でエージェント関連の機能が入った点だ。ワークフロー定義や設定キーの変更が今後も続くなら、osm-settings.yamlと自作YAMLの互換性をリリースごとに確認する作業が発生する。--keep-settingで設定を残しつつbaseを更新し、--dry-runでflowを読み直す、という手順が最小の検証になる。

編集部の結論

osmedeusが向くのは、偵察やアセット列挙の手順をYAMLで固定し、複数ホストやクラウド上で再現したいチームである。逆に、単発のスキャンを数コマンドで済ませたい場合や、ワークフローをYAMLで保守する意思がない場合は、nmapやhttpxを直接叩くほうが速い。導入前に確認すべきは、osmedeus install base --presetで何が入るかを把握すること、osm-settings.yamlの認証情報の扱い、そして--dry-runで対象ワークフローのモジュール構成を先に読むこと。判断は、自分の偵察手順がYAMLに落とせる粒度で言語化できるかどうかにかかっている。

公式情報源

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