Nebula 3.0.0-alpha.5 レビュー: 承認ゲートと OCI 隔離を前提にしたペンテスト作業台

Nebula が埋めようとしている作業の断絶

ペネトレーションテストの現場では、調査、ターミナル操作、得られた出力の保存、所見への整理、レポート作成が別々の道具に散らばりやすい。ブラウザで調べ、ターミナルで実行し、テキストエディタに貼り付け、最後にレポートを書き直す。この往復のたびに文脈が失われ、どの出力がどの結論の根拠だったのかを後から追えなくなる。Nebula はこの断絶を 1 つのデスクトップ面に畳もうとする。README が並べる構成要素は terminal、code、browser、assistant、files、notes、missions、findings、reports で、単体のスキャナではなく作業台として提示されている。対象読者は、スコープと権限を自分で定義できる立場のオペレータだ。README は「The operator defines the scope, grants authority, and decides what runs」と明記しており、AI に調査、整理、執筆を委ねても、何を実行するかの決定は人間側に残すという役割分担を最初に置いている。

intent から evidence までの流れと、途中に置かれた承認

README が示すデータフローは intent、assistance、approval、execution、evidence の 5 段階である。オペレータの意図から始まり、AI の支援を経て、承認を挟んでから実行され、最後に証跡として残る。この並びで重要なのは approval が execution の前に置かれている点で、AI の提案がそのまま実行に流れ込む経路を想定していない。実行側の境界としては、スコープ強制、承認による一時停止、ハードな予算上限、OCI による隔離実行が挙げられている。予算上限が「hard budgets」と表現されている以上、消費量に対して何らかの打ち切りが働く前提で設計されていると読める。証跡側は content-addressed artifacts、append-only events、execution provenance、integrity-manifested exports という 4 つの要素で説明される。追記専用のイベントとハッシュで内容を特定する成果物、実行の来歴、完全性マニフェスト付きのエクスポートが組み合わさり、結論に至った経路を後から再現できるようにする狙いだ。ただし、これらの機構が具体的にどのファイル形式でどこに保存されるのかは、提示された README からは読み取れない。設計意図は明確だが、運用に必要な保存先やスキーマは docs/NEBULA3.md や docs/AUTOMATION-RUNTIME.md を参照する必要がある。

モデルは必須ではないという設計判断

README は hosted、local、OpenAI-compatible の 3 種類のモデルランタイムに対応するとし、そのうえで「A model provider is optional」と述べている。モデルを接続しなくても、人間が操作するターミナル、証跡ワークフロー、ノート、所見、レポートは利用できる。この判断は、外部のモデル API にエンゲージメントの内容を送れない案件にとって実務上の意味を持つ。モデルを外しても作業台として成立するなら、機密性の高い対象では AI 支援だけを切って運用できる。逆に、AI 支援を前提にワークフローを組むと、モデルの応答品質がそのまま調査の質に影響する。どのランタイムを選ぶかは、対象の機密レベルと、ローカル推論に割ける計算資源の両方で決まる。README はモデルごとの得意不得意や推論速度には触れていないため、そこは自分の環境で確かめるしかない。

APT リポジトリからの導入手順と、確認すべき鍵

現行のリリース候補は Linux x86_64 向けの Nebula 3.0.0-alpha.5 で、ターミナルと自動化機能には Docker または Podman が必要とされる。推奨される導入経路は署名付き APT リポジトリで、アーカイブ鍵のフィンガープリントは 1D90 1EB3 4C8C 1065 F118 680D 1C5C 924C B4B5 823D と記載されている。手順は鍵の取得と確認、dearmor によるキーリング作成、sources.list.d への登録、apt install nebula、そして nebula の起動という流れだ。登録するチャネルは prerelease main で、これは Nebula 3 がプレビュー段階であることに対応する。DEB は Debian、Ubuntu、Kali と互換システムを対象とする。手動導入の場合は GitHub Releases から DEB と SHA256SUMS-linux-x64.txt を取得し、sha256sum --check --ignore-missing で検証してから apt install ./Nebula-3.0.0-alpha.5-linux-x86_64.deb を実行する。システム全体へのインストールを避けたい場合は AppImage も用意され、chmod +x の後に直接実行する。起動後は nebula-core doctor --json で Core とローカルランタイムの境界を確認する。初回起動では公式 Kali イメージのダウンロード、準備、検証が必要になり、回線とコンテナランタイムの速度によっては数分かかる点が明記されている。また README は pip install nebula-ai を Nebula 3 の導入に使わないよう警告している。

ソースからの実行と、パッケージ版との差

ソースから動かす場合は Python 3.11 から 3.13、Poetry 2.1.3、Node.js 20 と npm、安定版 Rust ツールチェーン、そして OS ごとの Tauri 前提条件を揃える。手順は git clone、poetry install --with dev、poetry run playwright install chromium、npm --prefix ui ci、npm --prefix ui run dev:desktop の順である。ここで見落としやすいのが Playwright の Chromium で、JavaScript で描画される URL ナレッジソースを扱うために必要になる。署名済み Linux インストーラには固定された Chromium ヘッドレスランタイムが同梱されるが、ソースチェックアウトではこの明示的なインストール手順が要る。既存のシステム Chrome や Chromium を使うこともできるとされている。最後のコマンドはローカルの Nebula Core サイドカーをビルドし、UI 開発サーバーを起動して、ネイティブデスクトップをチェックアウトから直接開く。ブラウザのみで開発する場合は npm --prefix ui run build の後に poetry run nebula-core ui を実行し、Core に空いているループバックポートを選ばせる。主要なチェックは python scripts/nebula3_version.py check、poetry run pytest -q tests/v3、npm --prefix ui test、npm --prefix ui run build の 4 つ。パッケージ版とソース版では Chromium の扱いが異なるため、検証環境をどちらで組むかによって再現手順が変わる。

Nebula 2 からの移行で守るべき順序

Nebula 2 からの移行は、Nebula 2 を終了し、エンゲージメントディレクトリのバックアップを取ってから、nebula-core import-2x "/path/to/nebula-2-engagement" を実行する。README はソースを変更せずにインポートすると述べており、元データを書き換えない経路が用意されている。手順書は docs/MIGRATING-2-TO-3.md にあり、完全性と復旧の手順がまとまっているとされる。重要なのは順序で、インポート後にプロジェクトとその証跡を検証し、確認が済むまで元データを削除しないよう明記されている。証跡の完全性を扱うツールで移行を急ぐと、後から元の状態に戻せなくなる。alpha 段階のビルドに対して既存案件のデータを移す場合は、検証が終わるまで Nebula 2 側のディレクトリを残す運用が前提になっていると読むべきだ。

この alpha を本番に置けない理由

最大の制約は対応プラットフォームの狭さである。macOS、Windows、Linux arm64 のインストーラは現行のリリースマトリクスに含まれていない。Apple Silicon のノート PC や Windows 端末しか持たない担当者は、このプレビューをそのまま業務に組み込めない。次に、プレビュービルドの存在条件が README で明示されている点がある。ビルドは GitHub Releases に nebula-v3.* のエントリとネイティブ成果物が現れたときにのみ存在する。つまりタグやブランチがあっても配布物がない状態があり得る。加えて README は、使用前にエンゲージメントデータをバックアップし、リリースノートとチェックサムを確認するよう求めている。alpha という位置づけは、データ形式やコマンド体系が変わり得ることを意味する。自動化の予算上限やスコープ強制がどの程度の粒度で効くのか、README の記述からは判断できない。ここは自分の環境で nebula-core doctor --json を実行し、Core とランタイムの境界が想定どおりに見えているかを確認したうえで、影響のない検証用プロジェクトから試すのが現実的だ。

Metasploit や手作業のワークフローとの違い

比較対象として分かりやすいのは Metasploit のようなエクスプロイト実行フレームワークだ。あちらは脆弱性の検証と侵入の実行そのものを中心に据え、モジュールとペイロードの体系で攻撃を組み立てる。Nebula は実行エンジンではなく、調査から証跡、所見、レポートまでの記録と承認の流れを束ねる側に重心がある。スコープ強制、承認による一時停止、OCI 隔離、追記専用イベント、完全性マニフェスト付きエクスポートという要素は、いずれも攻撃の威力ではなく、何をどの権限で実行し、その結果をどう保存したかを示すために並んでいる。だから Metasploit を置き換えるものではなく、その前後の文脈管理を担う位置づけになる。もう一つの比較対象は、ターミナルとノートアプリとレポートツールを手作業でつなぐ従来の進め方だ。こちらは道具の選択自由度が高く、AI の介在もない。Nebula はその自由度と引き換えに、意図と承認と実行と証跡を 1 本の流れに固定する。固定された流れが案件の進め方に合わないなら、導入しても使われなくなる。

編集部の結論

採用を検討すべきなのは、Linux x86_64 上でコンテナランタイムを用意でき、スコープ設定と承認中断を運用フローに組み込めるチームである。逆に macOS、Windows、Linux arm64 しか使えない環境では、現行リリースマトリクスにインストーラが存在しないため、この alpha を業務に組み込む根拠は薄い。導入前に確認すべきは 3 点。APT アーカイブ鍵のフィンガープリント 1D90 1EB3 4C8C 1065 F118 680D 1C5C 924C B4B5 823D が配布物と一致するか、初回起動時の Kali イメージ取得が数分かかることを許容できるか、そして nebula-core doctor --json の出力で Core とローカルランタイムの境界が自分の環境でどう認識されているかである。この 3 点が確認できるまでは、既存のエンゲージメントデータを Nebula 3 側へ移さず、Nebula 2 のディレクトリをバックアップとして残しておくのが妥当だ。

公式情報源

1. berylliumsec/nebula on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases