Nebula 3 預覽版：把 AI 助手關進 OCI 容器裡的滲透測試工作台
AI-powered penetration testing assistant for automating recon, note-taking, and vulnerability analysis.
秒懂
- 它是什麼？
- Nebula 把終端機、筆記、findings 與報告收進同一個桌面介面，並在 AI 與目標系統之間插入範圍限制、核准暫停與隔離容器。目前 3.0.0-alpha.5 只支援 Linux x86_64，且必須搭配 Docker 或 Podman。
- 適合誰用？
- 如果你已經在用 Kali 或相容的 Debian 系發行版、容器執行環境本來就在手上，而且需要把 AI 輔助與實際執行之間的授權邊界寫成可稽核的紀錄，Nebula 3 的 alpha 通道值得在隔離環境試一輪。反過來說，macOS、Windows 或 arm64 使用者現在沒有安裝路徑，不想讓 engagement 資料經過 alpha 版本的人也不該碰。
- 可以商用嗎？
- 可以。BSD-2-Clause 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Nebula 想解決的是滲透測試過程的散落問題
一次滲透測試的產出很少集中在一個地方。終端機的輸出在一份 shell log，URL 研究在瀏覽器分頁，中間推導出的結論寫在另一個文字檔，最後報告又要重新拼湊一次。Nebula 的定位是把這些環節收進同一個桌面介面：終端機、程式碼、瀏覽器、助手、檔案、筆記、missions、findings 與報告。README 對這件事的說法是「AI can investigate, organize, and write」，同時補上一句界線：範圍由操作者定義，授權由操作者授予，實際要跑什麼也由操作者決定。
目標讀者因此不是想找一鍵掃描器的人。它更接近已經有固定流程、想把 AI 輔助納入流程但不想讓 AI 直接碰目標系統的測試者。這個前提很重要，因為後面所有設計取捨都繞著它轉。
intent 到 evidence 的五段資料流決定了誰能按下執行
README 用一行文字概括 Nebula 的核心流程：intent → assistance → approval → execution → evidence。這不是行銷標語，而是把 AI 能做的事情切在第二段為止。助手負責調查、整理與撰寫，執行前必須經過核准，執行結果才成為證據。
支撐這條流程的是幾項具體機制。範圍限制與核准暫停構成第一層，硬性預算限制單次任務能消耗多少資源，隔離的 OCI 執行環境構成最後一層。證據端則由內容定址的 artifacts、append-only 事件、執行溯源紀錄，以及帶完整性 manifest 的匯出檔組成。內容定址意味著同一份輸出重複產生時不會變成兩筆不同紀錄，append-only 意味著事件寫入後不能被就地改寫。這兩點合起來，讓「這個結論是怎麼來的」在事後仍可追。
模型供應商是可選的。README 明說 hosted、local 與 OpenAI-compatible 三種 runtime 都支援，而且沒有模型時，人工終端機、證據流程、筆記、findings 與報告仍然可用。這個設計判斷很務實：把 AI 當成可插拔層，而不是整個工具的存在理由。
安裝路徑只有一條：APT 預覽通道加容器執行環境
官方建議的安裝方式是簽章過的 Nebula APT 儲存庫。流程先匯入 archive key，驗證指紋，再把 prerelease 通道寫進 sources.list，最後安裝並啟動：
sudo apt update sudo apt install -y ca-certificates curl gnupg curl -fsSL https://berylliumsec.github.io/nebula-apt/nebula-archive-keyring.asc | gpg --show-keys --fingerprint sudo apt install nebula nebula
README 明確指出 prerelease 通道在 Nebula 3 預覽期間是刻意選擇，不是設定失誤。DEB 支援 Debian、Ubuntu、Kali 與相容系統，後續更新走一般 APT 流程，由管理者控制。不想加儲存庫的人可以下載 DEB 或 AppImage，兩者都要先用 SHA256SUMS-linux-x64.txt 做 sha256sum --check 驗證。
啟動後有一個診斷指令值得先跑：nebula-core doctor --json，用來檢視內附 Core 與本機執行環境的邊界。另外 README 提醒首次啟動可能需要下載、準備並驗證官方 Kali 映像，視網路與容器 runtime 而定，可能花上數分鐘。終端機與自動化功能需要 Docker 或 Podman。
從原始碼建置的門檻不低，需要 Python 3.11 至 3.13、Poetry 2.1.3、Node.js 20 加 npm、穩定的 Rust toolchain，以及對應作業系統的 Tauri 前置條件。Playwright 的 chromium 要另外安裝，因為 JavaScript 驅動的 URL 知識來源靠它渲染；簽章過的 Linux 安裝檔則已內含鎖定的 Chromium headless runtime。
平台支援矩陣是這個預覽版最硬的限制
目前的發行矩陣只有 Linux x86_64。README 直接寫明 macOS、Windows 與 Linux arm64 安裝檔不在現行範圍內。這不是「尚未測試」的模糊說法，而是沒有安裝路徑。使用 Mac 筆電做測試工作的人，現階段只能等，或改走原始碼建置路線，而原始碼路線同樣需要自行滿足 Tauri 與 Rust 的相依條件。
第二個限制是版本狀態本身。最新發布是 nebula-v3.0.0-alpha.5，README 對預覽版的說明是：只有當 GitHub Releases 上出現 nebula-v3.* 條目與對應的原生 artifacts 時，才算存在一個可用的 build。它同時提醒備份 engagement 資料、閱讀 release notes 與檢查 checksum。這種措辭在 alpha 階段是合理防禦，但也意味著資料格式與行為仍可能變動。
第三個限制關於安裝指令本身。README 特別註明不要用 pip install nebula-ai 來安裝 Nebula 3，這代表 PyPI 上存在同名或近似名稱的套件，而它對應的是不同世代的東西。照著舊教學走的人會裝到錯的版本。
從 Nebula 2 匯入不是就地升級，而是一次複製
2.x 到 3.x 的遷移指令是：
nebula-core import-2x "/path/to/nebula-2-engagement"
README 的敘述強調「import it without modifying the source」，也就是匯入過程不改動來源目錄。流程要求先退出 Nebula 2、備份 engagement 目錄，匯入後驗證專案與其證據，確認無誤才刪除原始資料。完整的完整性與復原程序放在 docs/MIGRATING-2-TO-3.md。
這個設計的含義是：遷移失敗時原始資料仍在，代價是磁碟佔用與一次人工核對。對於手上有多個歷史 engagement 的人，這是逐個匯入、逐個驗證的工作，不會自動化完成。文件把驗證步驟寫成必要環節而非可選項，這一點在 alpha 階段是對的。
與純掃描器相比，Nebula 把重心放在流程紀錄
常見的替代做法是直接用掃描器加一份 shell log，或是在既有框架上自己串接 LLM API。差別在於紀錄的產生方式。掃描器輸出的是當次掃描的結果，log 輸出的是指令與終端機文字，兩者都不會自動回答「這個 finding 是根據哪一次執行、哪一份輸出推導出來的」。Nebula 用內容定址 artifacts 加 append-only 事件，把執行溯源變成資料結構的一部分，匯出時再附上完整性 manifest。
代價是耦合。要拿到這條溯源鏈，你得接受它的桌面介面、它的 engagement 目錄格式、它的 Core sidecar，以及容器 runtime 這個額外相依。自己串 LLM API 的人可以只保留自己需要的部分，但那些部分不會自動具備防竄改性質。反過來說，如果你要的只是快速跑一輪掃描，Nebula 的核准暫停與範圍限制會拖慢節奏，這些機制是為需要交代過程的委託案設計的。
值得注意的是，模型供應商可選這件事讓 Nebula 在沒有 AI 的情況下仍是一套筆記與證據工具。這個 fallback 讓它在模型不可用或客戶不允許外送資料時還有使用價值。
授權條款與維護成本
專案採用 BSD-2-Clause，屬於寬鬆授權，條文短，主要要求是保留著作權聲明與免責聲明。這對內部工具或商業委託案的採用相對單純，但這不是法律意見，實際使用前仍應由法務確認條文與你所在司法管轄區的搭配。README 另有一句使用限制：只能在你自己擁有或明確獲授權測試的系統與網路上使用 Nebula。
維護成本方面，可從材料推得的有幾項。APT 通道是 prerelease，代表更新會持續進來，也代表行為可能變動，升級前要讀 release notes 並檢查 checksum。終端機與自動化功能依賴 Docker 或 Podman，容器 runtime 的升級與 Kali 映像的下載驗證都在你的維運範圍內。從原始碼建置的人還要同時維護 Python、Node 與 Rust 三套工具鏈。
repository 的 packaging/RELEASING.md 與 docs/releases/ 目錄說明發布流程有文件化，但預覽階段的版本節奏仍由維護者決定，沒有對外承諾的時程可查。
編輯結論
如果你已經在用 Kali 或相容的 Debian 系發行版、容器執行環境本來就在手上，而且需要把 AI 輔助與實際執行之間的授權邊界寫成可稽核的紀錄，Nebula 3 的 alpha 通道值得在隔離環境試一輪。反過來說，macOS、Windows 或 arm64 使用者現在沒有安裝路徑，不想讓 engagement 資料經過 alpha 版本的人也不該碰。動手前先驗證 APT 金鑰指紋 1D90 1EB3 4C8C 1065 F118 680D 1C5C 924C B4B5 823D，跑一次 nebula-core doctor --json 確認 Core 與本機執行環境的邊界，再用 nebula-core import-2x 匯入既有 engagement 並核對證據後才刪除原始資料。
社群筆記