Osmedeus v5：把滲透測試流程變成可稽核的 YAML 管線

它解決的是流程混亂，不是單一工具缺口

多數滲透測試工具鏈的問題不在於少一個掃描器，而在於流程難以重現。跑完 subdomain 列舉、埠掃描、HTTP 探測之後，中間的參數、順序、結果存放位置往往散落在 shell history 裡。Osmedeus 把這個問題定義為編排問題，而非掃描問題。它用宣告式 YAML 描述整個 pipeline，從 hooks、決策路由到模組排除都寫在設定檔裡。這意味著同樣的 recon 流程可以在不同目標上重跑，而且每次的執行細節都有紀錄可查。對需要向客戶或主管證明「我們確實做了哪些測試」的團隊來說，這種可稽核性比任何單一工具的輸出都更有價值。文件稱它同時服務初學者和專家，但從 CLI 的複雜度來看，初學者恐怕得先花時間理解 workflow 概念，而非直接獲得簡化操作。

核心機制：YAML 工作流、分散執行與事件觸發

Osmedeus 的架構可以拆成三層。最底層是 runner，支援 host、Docker 與 SSH，這決定每個步驟在哪裡執行。上一層是 workflow 引擎，它讀取 YAML 定義，處理條件分支、模組排除與 hooks。最上層是佇列與排程系統，以 Redis 為基礎，採用 master-worker 模式。文件提到的功能包括 cron、file-watch 與事件觸發，配合過濾、去重與延遲佇列。這代表你不只能手動下指令，還能讓流程在特定事件發生時自動啟動。例如監看某個目錄的新檔案，一旦出現就觸發掃描。分散執行不是把單一掃描拆散，而是把多個目標或流程分配給不同 worker，透過佇列管理。worker 之間有檔案同步機制，但文件沒有詳細說明同步的衝突處理，這在大型團隊使用時可能是個隱憂。

實際跑起來：從安裝到第一個掃描

安裝方式有兩種。官方推薦的是一行指令：curl -sSL http://www.osmedeus.org/install.sh | bash。另一種是透過 npm：npm install -g @j3ssie/osmedeus，這會提供 linux 與 macOS 的 x64/arm64 預編譯二進位。安裝後，最基礎的執行是 osmedeus run -m recon -t example.com，這會跑一個模組工作流。若要跑完整流程，改用 osmedeus run -f general -t example.com。多目標並行可以用 -T targets.txt -c 5，其中 -c 指定並行數。在正式執行前，建議先跑 osmedeus run -f general -t example.com --dry-run，這會預覽工作流而不實際執行，是驗證 YAML 設定是否正確的關鍵步驟。查詢結果的指令也值得注意：osmedeus assets -w example.com 列出資產，osmedeus query vulns --severity high --workspace example.com 過濾漏洞。這些指令顯示 Osmedeus 不只是執行引擎，也內建了結果查詢介面，讓使用者不必手動翻閱輸出檔。

LLM 代理與 ACP 整合：是加分還是風險

Osmedeus v5 的賣點之一是 agentic LLM steps，它支援 tool-calling agent loop，具備子代理編排、記憶體管理與結構化輸出。另外還能掛上 ACP 子程序代理，例如 Claude Code、Codex、OpenCode 與 Gemini。實際使用方式是 osmedeus agent "analyze this codebase"，或指定代理 osmedeus agent --agent codex "explain main.go"。這個設計把 LLM 當成工作流裡的一個步驟，而非取代整個流程。文件提到記憶體管理與結構化輸出，但沒有說明 LLM 步驟如何與既有 YAML 工作流互動，例如 LLM 的輸出能否直接餵給下一個掃描模組。對安全工具來說，讓 LLM 決定下一步動作有雙面性：它能處理非結構化輸入，但也可能產生無法預期的指令。若你的環境對執行內容有嚴格控管，這類功能需要先在小範圍測試。

雲端供應與成本控制：自動化擴展的另一面

Osmedeus 內建雲端供應功能，支援 DigitalOcean、AWS、GCP、Linode 與 Azure。指令 osmedeus cloud create --instances 3 會建立三台機器，osmedeus cloud setup 1 則設定第一台。文件強調成本控制與自動清理，這對需要大量掃描的人來說是實際需求，因為雲端帳單不會等你掃完才結算。但自動清理機制的可靠性是關鍵，若清理失敗或設定錯誤，可能留下持續計費的資源。文件沒有提供成本控制的具體參數，例如每台機器的規格上限或執行時間上限，這需要查閱完整文件。另外，分散執行的 worker 也可以透過 osmedeus worker queue new 與 osmedeus worker queue run --concurrency 5 管理，這與雲端供應是兩條獨立路徑，但可以組合使用。

限制與不適合的場景

Osmedeus 不是輕量工具。它的安裝檔會拉取大量依賴，工作流概念需要學習曲線。若你只是想快速掃一個網站的子域名，直接執行 subfinder 或 amass 會更直接。另一個限制是執行環境的隔離依賴於 runner 設定。host runner 直接在你的機器上執行，Docker runner 提供隔離，但 sandboxed execution 的宣稱實際上取決於你怎麼寫 YAML。若 workflow 裡有 ssh_exec 這類函式，而 SSH 目標沒有做好權限控管，等於開啟遠端執行的大門。此外，LLM 代理步驟的引入讓工具的行為更難預測，這對需要穩定重現結果的 CI/CD 整合可能是阻礙。最後，Redis 依賴代表你必須維護一個佇列服務，若 Redis 掛掉，整個分散執行會停擺。

替代方案：與其他自動化工具的實際差異

與 Osmedeus 最接近的替代品是 ProjectDiscovery 系列的組合，例如 nuclei 搭配 httpx 與 subfinder，再透過簡單的 shell script 串接。差異在於 ProjectDiscovery 工具是單一用途，每個工具專注一項任務，串接邏輯由使用者自行撰寫，沒有內建佇列、事件觸發或 LLM 代理。Osmedeus 把這些整合進一個 declarative 框架，讓流程定義與執行分離。另一個方向是使用如 Autorecon 這類單一腳本工具，它預先定義好掃描順序，但缺乏 YAML 的擴充性，也無法分散執行。若你的需求是跨多台機器、多個目標、且要整合排程與查詢，Osmedeus 的 master-worker 架構是實質差異。若你的需求只是固定幾條指令，手寫 script 的維護成本反而更低。

維護成本與授權考量

Osmedeus 以 Go 撰寫，授權為 MIT，這表示你可以自由修改與商業使用，但沒有提供任何擔保。專案最近更新頻繁，v5.1.0 在 2026 年 8 月釋出，顯示開發仍持續。但頻繁更新也代表 API 或 workflow 格式可能變動，升級前需要檢查 changelog。安裝方式支援 npm 全域安裝，這對版本管理有幫助，因為你可以指定版本號。但 npm 套件是否與 GitHub release 同步，文件沒有明確說明。升級成本主要來自兩方面：一是自訂 YAML workflow 可能需要調整以符合新版語法，二是 worker 節點需要同步更新，否則 master 與 worker 版本不一致可能導致協定不相容。文件提到 install base --preset --keep-setting 可以保留現有 osm-settings.yaml，這暗示升級時設定檔可能被覆寫，需要特別注意。

編輯結論

Osmedeus 適合需要把多階段偵察與掃描流程標準化、且願意用 YAML 描述管線的團隊或個人。它不適合只想跑單一工具、不想要額外抽象層的人，也不適合對執行環境隔離要求極高的場域，因為 Docker 與 SSH runner 的沙箱邊界仍由你的設定決定。採用前應先確認三件事：你的目標資產是否允許這種規模的主動掃描、你的 Redis 與 worker 節點是否能承受佇列負載、以及你能否接受 LLM 代理步驟可能帶來的非預期指令執行風險。若你只需要簡單的 subdomain 列舉，直接使用 httpx 或 subfinder 更輕量；若你需要可追蹤、可重跑的完整攻擊面流程，Osmedeus 的 declarative 設計與內建查詢介面確實值得一試，但請從 dry-run 模式開始驗證每個 workflow 的真實行為。

官方來源

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