Nebula 3.0.0-alpha.5 : un poste de travail de pentest sous autorité explicite

Le problème visé : recoller une mission éclatée entre dix fenêtres

Un engagement se déroule rarement dans un seul outil. On cherche une URL dans un navigateur, on colle une sortie dans un terminal, on la recopie dans un carnet, on la retrouve trois jours plus tard sans se rappeler quelle commande l'a produite. Nebula attaque ce point précis : le README annonce vouloir réunir terminal, code, navigateur, assistant, fichiers, notes, missions, findings et rapports dans une seule surface de bureau. Le public visé est l'opérateur offensif qui doit justifier ses conclusions, pas le curieux qui veut lancer un scan. Le projet met en avant trois propriétés : ne pas perdre le contexte entre recherche et exécution, garder l'autorité explicite, et laisser une trace durable. La troisième est la plus intéressante, parce qu'elle est vérifiable dans l'architecture décrite plus bas, alors que la première relève surtout de l'ergonomie.

intent, assistance, approval, execution, evidence : la chaîne réelle

Le README résume le flux en cinq étapes : intent, assistance, approval, execution, evidence. L'IA intervient sur les deux premières et sur la rédaction ; l'opérateur définit la portée, accorde l'autorité et décide ce qui s'exécute. Concrètement, la documentation mentionne des pauses d'approbation, des budgets durs, une application de périmètre et une exécution isolée en OCI. Le terminal et l'automatisation passent donc par un conteneur, ce qui explique l'exigence de Docker ou Podman. La couche de preuve repose sur des artefacts adressés par contenu, des événements en ajout seul, une provenance d'exécution et des exports accompagnés d'un manifeste d'intégrité. C'est une conception de journal d'audit, pas de tableau de bord. Le point à retenir : le modèle de langage n'est pas dans le chemin critique de l'exécution. Le README précise qu'un fournisseur de modèle est optionnel et que le terminal humain, le flux de preuves, les notes, les findings et les rapports restent disponibles sans lui. On peut donc utiliser Nebula comme carnet de mission instrumenté, sans jamais brancher de LLM.

Installer l'aperçu : dépôt APT signé ou paquet local

La méthode recommandée est le dépôt APT signé. Le README donne l'empreinte de la clé d'archive à vérifier avant tout : 1D90 1EB3 4C8C 1065 F118 680D 1C5C 924C B4B5 823D. Ensuite, on ajoute le canal prerelease, ce qui est un choix assumé tant que Nebula 3 reste en aperçu. Les commandes sont classiques : récupération de la clé, conversion en trousseau, écriture de /etc/apt/sources.list.d/nebula.list avec l'option signed-by, puis sudo apt install nebula et lancement par nebula. Le paquet DEB cible Debian, Ubuntu, Kali et systèmes compatibles, en amd64. Deux variantes existent : le DEB téléchargé manuellement, à valider avec sha256sum --check --ignore-missing SHA256SUMS-linux-x64.txt, et l'AppImage, qui se contente d'un chmod +x et d'une exécution directe. Après le lancement, le README recommande d'inspecter la frontière entre le Core embarqué et le runtime local avec nebula-core doctor --json. Attention au premier démarrage : Nebula peut devoir télécharger, préparer et vérifier l'image Kali officielle, ce qui prend plusieurs minutes selon la connexion et le runtime de conteneurs.

Depuis les sources : quatre chaînes d'outils à faire cohabiter

Le build depuis les sources n'est pas léger. Il faut Python 3.11 à 3.13, Poetry 2.1.3, Node.js 20 avec npm, la toolchain Rust stable et les prérequis Tauri du système. Le README enchaîne poetry install --with dev, poetry run playwright install chromium, npm --prefix ui ci, puis npm --prefix ui run dev:desktop. Cette dernière commande construit le sidecar Nebula Core, démarre le serveur de développement de l'interface et ouvre le bureau natif depuis le checkout. L'étape Playwright mérite d'être signalée : elle sert à rendre les sources de connaissance accessibles par URL lorsque le JavaScript est nécessaire. Les installateurs Linux signés embarquent un Chromium headless verrouillé, mais un checkout source exige cette installation explicite. Nebula peut aussi s'appuyer sur un Chrome ou Chromium déjà présent sur le système. Pour le développement sans interface native, npm --prefix ui run build suivi de poetry run nebula-core ui laisse Core choisir un port loopback disponible. Les contrôles principaux sont listés : python scripts/nebula3_version.py check, poetry run pytest -q tests/v3, npm --prefix ui test, npm --prefix ui run build.

Migrer depuis Nebula 2 sans toucher aux données d'origine

La migration est traitée comme une opération à risque. Le README demande de quitter Nebula 2, de conserver une sauvegarde du répertoire d'engagement, puis d'importer sans modifier la source avec nebula-core import-2x "/path/to/nebula-2-engagement". La consigne suivante est explicite : vérifier le projet importé et ses preuves avant de supprimer les données d'origine. Le document docs/MIGRATING-2-TO-3.md contient la procédure complète d'intégrité et de récupération. C'est le bon réflexe, parce qu'un import qui casse la chaîne de provenance rend le journal d'exécution inutile pour justifier une conclusion. Un point pratique : la commande attend un chemin, pas une archive, et l'import ne modifie pas la source. Cela laisse la possibilité de relancer l'opération si le résultat n'est pas conforme. Le README ne détaille pas les cas d'échec partiel, ni ce qui se passe si un artefact référencé manque côté 2.x ; il faut se référer au document de migration pour ces scénarios.

Ce que l'aperçu ne couvre pas encore

La limite la plus nette est dans le README lui-même : macOS, Windows et Linux arm64 ne font pas partie de la matrice de release actuelle. Sur ces plateformes, il n'y a pas d'installeur. Deuxième contrainte : Docker ou Podman est requis pour le terminal et les automatisations, donc une machine sans runtime de conteneurs utilisable perd une partie substantielle du produit. Troisième point, la version 3 est en aperçu et le canal APT s'appelle prerelease. Le README avertit qu'un build n'existe que si une entrée nebula-v3.* et ses artefacts natifs apparaissent dans les releases GitHub, et demande de sauvegarder les données d'engagement et de relire les notes de version et les sommes de contrôle avant usage. Il précise aussi de ne pas utiliser pip install nebula-ai pour installer Nebula 3. Enfin, le projet n'est pas un scanner : les topics mentionnent l'évaluation de vulnérabilités, mais le README décrit un poste de travail où l'IA organise et rédige, pas un moteur qui découvre des failles à votre place. Si vous cherchez un scan automatisé avec rapport prêt à livrer, l'outil est mal choisi.

Face à un simple terminal plus un carnet de notes

L'alternative la plus évidente n'est pas un autre assistant IA, c'est l'assemblage manuel : un terminal, un éditeur de notes, un dépôt Git pour les sorties, et un LLM dans une fenêtre séparée. La différence n'est pas la qualité de l'analyse, elle est dans la traçabilité. Avec l'assemblage manuel, la provenance d'une conclusion dépend de votre discipline : nommer les fichiers, dater les captures, recopier la commande exacte. Nebula impose ce chemin par construction, avec des artefacts adressés par contenu, des événements en ajout seul et des exports à manifeste d'intégrité. Le coût est réel : il faut apprendre un modèle de missions et de findings, accepter les pauses d'approbation et faire tourner un conteneur. Pour une mission courte et informelle, ce coût n'est pas rentabilisé. Pour un engagement avec livrable et obligation de justification, la comparaison penche dans l'autre sens, à condition d'accepter le statut d'aperçu. Un autre angle : le fournisseur de modèle étant optionnel, on peut adopter Nebula pour la partie preuve et notes, et garder son propre outil d'analyse à côté.

Coût de maintenance et cadre de licence

Le projet est publié sous BSD-2-Clause, une licence permissive qui autorise la redistribution et la modification avec conservation de l'avis de copyright. Elle ne donne aucune garantie, ce qui compte pour un outil employé dans un contexte offensif : la responsabilité de l'usage reste entièrement chez l'opérateur. Le README le rappelle sous forme d'avertissement : n'utiliser Nebula que sur des systèmes et réseaux que vous possédez ou êtes explicitement autorisé à tester. Sur la maintenance, le dépôt n'est pas archivé et la dernière poussée indiquée est le 9 septembre 2026, avec une alpha 3.0.0-alpha.5 datée du 22 juillet 2026 et deux bêtas 2.0.1b1 et 2.0.1b2 du 20 juillet 2026. Le rythme est celui d'un aperçu actif, pas d'une branche stable. Les mises à jour restent sous contrôle de l'administrateur via APT, ce qui est un point favorable : on peut figer le canal, vérifier les sommes de contrôle et différer une mise à jour. En revanche, la présence de deux lignes de version en parallèle (2.0.1b et 3.0.0-alpha) signifie qu'il faut décider explicitement sur quelle branche on s'engage, et que la migration 2 vers 3 est un chemin à sens unique tant que la vérification des preuves importées n'est pas terminée.

Conclusion éditoriale

Nebula convient aux équipes offensives qui travaillent déjà sous autorisation écrite et veulent un journal d'exécution unique, sur Linux x86_64 avec Docker ou Podman. Ceux qui cherchent un scanner automatisé, ou qui doivent tourner sur macOS, Windows ou Linux arm64, n'ont rien à faire ici : ces installateurs ne font pas partie de la matrice de release actuelle. Avant tout engagement réel, vérifier l'empreinte de la clé APT, lancer nebula-core doctor --json et contrôler que l'import 2.x a bien conservé les preuves.

Sources officielles

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