Nebula 3.0.0-alpha.5: KI-gestütztes Pentesting mit expliziten Freigabepunkten

Welche Lücke Nebula schließen will

Ein Pentest erzeugt ein Problem, das selten offen benannt wird: Der Weg zu einer Feststellung ist nach ein paar Tagen nicht mehr rekonstruierbar. Rohausgaben liegen in Scrollback-Puffern, Notizen in einer anderen Datei, der Beleg für eine Annahme in einem Screenshot ohne Zeitstempel. Nebula setzt genau dort an. Die README beschreibt den Anspruch mit dem Satz, Nebula bringe "die arbeitenden Teile eines Security Engagements auf eine einzige Desktop-Oberfläche": Terminal, Code, Browser, Assistent, Dateien, Notizen, Missionen, Findings und Berichte. Angesprochen sind Menschen, die bereits Pentests durchführen und die Belegkette als Teil der Arbeit betrachten, nicht als Nachbereitung. Das ist keine Einsteiger-Suite und will es auch nicht sein. Die Zielgruppe sind Auftragnehmer und interne Teams, die gegenüber einem Auftraggeber oder einer Prüfung erklären müssen, wie eine Aussage zustande kam.

Der Ablauf intent, assistance, approval, execution, evidence

Nebula modelliert den Arbeitsablauf als Kette. Die README zeigt sie als Grafik: intent, assistance, approval, execution, evidence. Das Modell darf untersuchen, ordnen und schreiben; der Operator legt den Scope fest, erteilt die Erlaubnis und entscheidet, was ausgeführt wird. Zwischen Modell und Zielsystem stehen laut README vier Mechanismen: Scope-Durchsetzung, Freigabepausen, harte Budgets und isolierte OCI-Ausführung. Der Assistent kann also nicht selbstständig einen Scanner gegen ein Ziel starten, das nicht im Scope liegt, und nicht beliebig lange laufen. Für die Nachvollziehbarkeit nennt die README inhaltsadressierte Artefakte, append-only Events, Ausführungsherkunft und Exporte mit Integritätsmanifest. Das ist die eigentliche Designentscheidung des Projekts: Nicht das Modell wird abgesichert, sondern der Übergang von Vorschlag zu Ausführung. Ein Modellanbieter ist optional. Terminal, Beleg-Workflow, Notizen, Findings und Berichte bleiben laut README auch ohne Modell nutzbar.

Installation über die signierte APT-Quelle

Der bevorzugte Weg führt über das APT-Repository nebula-apt. Zuerst wird der Schlüssel geprüft, nicht blind importiert. Der Fingerabdruck lautet 1D90 1EB3 4C8C 1065 F118 680D 1C5C 924C B4B5 823D. Die README zeigt den Ablauf in zwei Schritten: curl -fsSL https://berylliumsec.github.io/nebula-apt/nebula-archive-keyring.asc | gpg --show-keys --fingerprint zum Anzeigen, danach dieselbe Quelle mit sudo gpg --dearmor --batch --yes -o /usr/share/keyrings/nebula-archive-keyring.gpg in das Schlüsselbundformat bringen. Anschließend wird die Quelle mit dem Kanal prerelease und dem Architekturfilter amd64 in /etc/apt/sources.list.d/nebula.list eingetragen, sudo apt update ausgeführt und mit sudo apt install nebula installiert. Der Kanal prerelease ist bewusst gewählt, solange Nebula 3 Vorschau ist. Das DEB wird für Debian, Ubuntu, Kali und kompatible Systeme angeboten. Alternativ nennt die README eine manuelle DEB-Installation nach Prüfung von SHA256SUMS-linux-x64.txt sowie eine portable AppImage. Nach dem Start lässt sich die Laufzeitgrenze mit nebula-core doctor --json inspizieren. Beim ersten Start kann der Download und die Verifikation des Kali-Images mehrere Minuten dauern.

Aus dem Quelltext bauen und was Playwright damit zu tun hat

Der Quelltextweg verlangt Python 3.11 bis 3.13, Poetry 2.1.3, Node.js 20 mit npm, die stabile Rust-Toolchain und die Tauri-Voraussetzungen des jeweiligen Betriebssystems. Nach git clone und cd nebula folgen poetry install --with dev, poetry run playwright install chromium, npm --prefix ui ci und schließlich npm --prefix ui run dev:desktop. Der Playwright-Schritt ist nicht optional, wenn URL-Wissensquellen genutzt werden, deren Inhalt per JavaScript gerendert wird. Signierte Linux-Installer bringen laut README eine festgeschriebene Chromium-Headless-Laufzeit mit; ein Quelltext-Checkout muss sie explizit nachinstallieren. Nebula kann alternativ einen bereits vorhandenen Chrome oder Chromium verwenden. Für Prüfungen vor dem Merge nennt die README vier Befehle: python scripts/nebula3_version.py check, poetry run pytest -q tests/v3, npm --prefix ui test und npm --prefix ui run build. Wer aus einer älteren Version umsteigt, importiert das Engagement-Verzeichnis mit nebula-core import-2x "/path/to/nebula-2-engagement", ohne die Quelle zu verändern, und prüft das importierte Projekt samt Belegen, bevor die Originaldaten gelöscht werden.

Wo die Preview an ihre Grenzen stößt

Die Versionslage ist der erste Punkt. Die jüngste Veröffentlichung ist nebula-v3.0.0-alpha.5 vom 22. Juli 2026, davor liegen 2.0.1b2 und 2.0.1b1. Alpha bedeutet hier nicht nur ein Etikett: Die README verlangt ausdrücklich, Engagement-Daten vor der Nutzung zu sichern und vor jedem Einsatz die Release Notes und Prüfsummen zu lesen. Die Plattformmatrix ist eng. macOS-, Windows- und Linux-arm64-Installer sind laut README nicht Teil der aktuellen Release-Matrix. Terminal- und Automatisierungsfunktionen setzen Docker oder Podman voraus; ohne Container ist der Funktionsumfang kleiner als der Name vermuten lässt. Ein weiterer Punkt betrifft die Modellabhängigkeit: Zwar bleibt der Kern ohne Modell nutzbar, doch die Fähigkeit, Befunde zu ordnen und zu formulieren, hängt dann am Anbieter, und die README lässt offen, wie stark sich Ergebnisse zwischen Modellen unterscheiden. Schließlich warnt die README ausdrücklich davor, pip install nebula-ai für Nebula 3 zu verwenden. Wer diesen Befehl aus alten Anleitungen übernimmt, installiert nicht die aktuelle Version. Das ist ein Fall, in dem ein veralteter Installationsweg still zum falschen Ergebnis führt.

Wie sich Nebula von Metasploit und reinen Scannern unterscheidet

Der naheliegende Vergleich ist Metasploit. Metasploit ist eine Exploit- und Payload-Bibliothek mit eigener Konsole; sein Zweck ist die Ausführung von Modulen gegen Ziele, und die Dokumentation eines Laufs entsteht daneben, nicht darin. Nebula enthält nach der README keinen Exploit-Katalog. Es ist eine Arbeitsfläche, die Terminal, Notizen, Findings und Berichte verbindet und die Ausführung über Freigabepausen und Scope-Regeln steuert. Der Unterschied liegt also nicht im Umfang der Angriffsmodule, sondern darin, dass der Belegpfad Teil der Anwendung ist. Gegenüber einem reinen Scanner wie einem eigenständigen Schwachstellenwerkzeug ist die Richtung umgekehrt: Dort ist der Scan das Produkt, hier ist er eine Station in einer Kette. Für ein Team, das bereits eine eigene Werkzeugkette und ein Berichtstemplate hat, ersetzt Nebula nichts davon, sondern verlangt, die Kette in die Anwendung zu holen. Das ist eine bewusste Einschränkung und kein Mangel: Wer Belege außerhalb der Anwendung führt, gewinnt durch Nebula wenig.

Pflegeaufwand, Update-Kanal und Lizenz

Updates laufen laut README über den normalen APT-Workflow und bleiben unter Kontrolle des Administrators. Der Kanal prerelease bedeutet, dass Vorabversionen in die Paketverwaltung gelangen; das ist während der Vorschau gewollt, verlangt aber eine Entscheidung darüber, ob ein Arbeitsrechner diesen Kanal überhaupt erhalten soll. Die AppImage-Variante nutzt einen signierten direkten Update-Kanal, was die Pflege vereinfacht, aber eine zweite Update-Mechanik neben APT einführt. Für den Quelltextweg kommen Poetry, npm und die Rust-Toolchain als zusätzliche Abhängigkeiten hinzu, die regelmäßig aktualisiert werden müssen. Nebula steht unter BSD-2-Clause. Das ist eine permissive Lizenz mit wenigen Bedingungen; sie erlaubt Weitergabe und Änderung, verlangt aber die Beibehaltung des Urheberrechtshinweises. Ob und wie die Lizenz den Einsatz in einem kommerziellen Beratungsprojekt beeinflusst, hängt von der Organisation ab und ist keine technische Frage. Diese Einordnung ist keine Rechtsberatung; wer den Code weitergeben oder in ein Produkt einbetten will, muss den Lizenztext selbst prüfen.

Redaktionelles Fazit

Wer auf Linux x86_64 arbeitet, Docker oder Podman ohnehin betreibt und eine nachvollziehbare Kette von der Absicht bis zum Beleg braucht, kann die Preview auf einem isolierten Rechner testen. Wer Windows oder macOS braucht, keine Container einsetzen will oder reproduzierbare Ergebnisse über Versionen hinweg erwartet, sollte warten. Prüfe zuerst die Fingerabdrücke des APT-Schlüsselrings, den Inhalt der Datei docs/releases/3.0.0-alpha.5.md und den Befehl nebula-core doctor --json auf dem Zielsystem, bevor du echte Engagement-Daten importierst.

Offizielle Quellen

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