dobybaxter127/nimbus-vestigeEine forensische Rekonstruktions-Engine für Cloud- und Identitäts-Incident-Response.
Eine forensische Rekonstruktions-Engine für Incident Response in Cloud und Identität.
Aus fragmentierter Cloud-, SaaS- und Identitätstelemetrie — Control-Plane-Logs, Anmelde- ereignisse, Token- und Consent-Aktivität — rekonstruiert NV, wie sich ein Eindringen höchstwahrscheinlich über Konten und Dienste bewegt hat, zählt die anderen wahrscheinlichsten Pfade auf, die es hätte nehmen können, und berichtet jeden Schritt mit kalibrierter, erklärbarer Konfidenz. Es weigert sich zu behaupten, was die Beweise nicht stützen können.
Erkennung sagt dir, dass etwas passiert ist. Nimbus Vestige sagt dir, wie — und was noch.
Moderne Eindringlinge „brechen nicht ein." Sie melden sich an. Identität ist heute das primäre Angriffs- vehikel, an der großen Mehrheit der Cloud-IR-Untersuchungen beteiligt, und die meisten Eindringlinge erstrecken sich über mehrere Oberflächen — Identität plus Cloud plus SaaS plus Endpoint. Die Telemetrie, die sie aufzeichnet, ist fragmentiert und inkonsistent, was Responder bereits dazu zwingt, die Geschichte von Hand aus unvollständigen Daten zu rekonstruieren.
Diese manuelle Rekonstruktion ist langsam und scheitert auf vorhersehbare Weise: Der Responder verankert sich an der ersten plausiblen Erzählung und verpasst die echte. NV automatisiert die Rekonstruktion und greift diesen Fehlermodus direkt an, indem es stets den bewerteten Raum plausibler Pfade präsentiert, nicht eine einzige Geschichte.
Entscheidend ist, dass NV dies mit Ehrlichkeit als Produkt tut. Der erklärte Feind des Marktes ist Black-Box-Konfidenz — ein Werkzeug, das eine Schlussfolgerung behauptet, ohne seine Arbeit zu zeigen. Jede Zahl, die NV produziert, ist auf die spezifischen Beweise zurückführbar, die sie verdient haben, und alles, was es nicht stützen kann, wird zurückgehalten statt geraten.
NV ist kein Detektor, kein Scanner, kein Auditor und kein Attack-Runner. Diese Werkzeuge sagen dir, dass etwas passiert ist, und messen es. NV arbeitet rückwärts — abduktive Rekonstruktion des Mechanismus aus Mustern, über eine fragmentierte Identitätslandschaft hinweg.
Blue Team regeneriert sich; Red Team wird kommodifiziert. Offensive Tools finden eine endliche, patchbare Menge an Löchern und werden in automatisierte CI/CD-Sicherheitspipelines integriert. Zu rekonstruieren, wie ein Eindringen passiert ist, löst sich nie auf — Angreifer erfinden ständig Neues, also ist der Bedarf dauerhaft und sich selbst erneuernd.
Die Engine ist substratunabhängig. Die Kernlogik — den Mechanismus aus Mustern rekonstruieren, mit kalibrierter Konfidenz und einer Stoppschiene — ist zuerst auf Cloud/Identität ausgerichtet, portiert aber später auf Netzwerk, Endpoint und OT. Das Ziel kann sich ändern, ohne die These neu zu schreiben.
Rekonstruktion ermöglicht Härtung. Sobald du weißt, wie sie hereingekommen sind — und welche anderen Türen offen waren — baust du die Verteidigung. Die nicht gegangenen, aber plausiblen Pfade sind ein Härtungs-Backlog, oft wertvoller als die Rekonstruktion selbst, weil die meisten Einbrüche vermeidbare Exposition ausnutzen, nicht neuartige Taktiken.
Es degradiert elegant beim neuartigen Eindringen — genau dem Vorfall, der am meisten zählt. Eine Signatur-/Regel-Engine wird bei einem Zero-Day blind; NVs abduktiver Kern produziert trotzdem einen wahrscheinlichsten Pfad, ehrlich als niedrigere Konfidenz gekennzeichnet.
Ehrlichkeit ist ein Burggraben. Kalibrierte, fallbasierte Konfidenz mit bewerteten Alternativen ist genau das, was der Markt zu wollen sagt und was Black-Box-Konkurrenten strukturell nicht bieten können, ohne Neuentwurf.
Roh-Provider-Logs → normalisierter Ereignis-/Entitätsgraph → Rekonstruktions-Engine → JSON → GUI.``` O365 / Entra audit logs nv_extract_identity_events.py AWS CloudTrail (IAM/STS/S3) nv_extract_cloudtrail_events.py (ingest + normalize) ▼ normalized identity events (JSONL) ← one event model, any substrate │ nv/graph.py (typed per-actor timelines) ▼ reconstruction engine ├─ nv/patterns.py known layer: ATT&CK identity pattern library ├─ nv/providers.py provider packs: per-substrate op→ATT&CK vocab (Entra + AWS) ├─ nv/validation.py Phase 3: provenance + integrity gate on every pattern ├─ nv/feeds.py live ATT&CK STIX / TAXII / Sigma clients + scheduler ├─ nv/confidence.py evidence-corroboration scorer (calibratable weights) ├─ nv/calibration.py fit + measure confidence against labeled ground truth ├─ nv/reconstruct.py most-likely chain + ranked competing paths + trust floor └─ nv/scope.py authorized-scope gate (refuses unauthorized tenants/accounts) │ run_nv.py ▼ reconstruction.json ──► nv_gui.html (embedding canvas + two-column view + trust slider)
Die GUI ist eine **reine Darstellungsschicht** — sie rendert die Engine-Ausgabe und ermöglicht es dem Analysten, die Vertrauensuntergrenze
zu verschieben. Sie enthält keinerlei eigene Rekonstruktionslogik.
---
## Das Konfidenzmodell (die Glaubwürdigkeit des gesamten Produkts)
Jeder Schritt trägt eine Konfidenz in [0, 1], aufgebaut durch **Evidenz-Korrobation**:```
confidence = per-technique base rate
+ bonus for each independent corroborating signal
(source IP, device, successful outcome, temporal adjacency, broad-consent flags)
− penalty for missing signals (e.g. no source IP to corroborate origin)
Pfad-Scores setzen ihre Verknüpfungen über das geometrische Mittel zusammen, sodass ein schwaches Glied einen Pfad ehrlich nach unten zieht, anstatt weggemittelt zu werden.
Jede Gewichtung oben — die Basisraten pro Technik, die Boni pro Signal, die Strafen für
fehlende Werte — lebt in einer einzigen PARAMS-Tabelle in nv/confidence.py. Das sind
die v1-Priors von NV, und sie sind kalibrierbar: nv/calibration.py kann sie gegen
gelabelte Ground-Truth neu anpassen, und die Engine lädt das Ergebnis, wobei sie auf die
v1-Priors zurückfällt, wenn keine Kalibrierung bereitgestellt wird (siehe unten).
Die Zurückhaltungsregel, fest im Ausgabevertrag der Engine verankert — nicht nur in der UI. Unterhalb der Untergrenze wird ein Schritt zurückgehalten. Die Untergrenze zu verschieben ist der greifbar gemachte Kompromiss zwischen Ehrlichkeit und Abdeckung: hoch für streng/hohes Vertrauen, runter für permissiv/hohe Abdeckung. Die Standard-Untergrenze ist eine redaktionelle Entscheidung darüber, wo NV steht, bevor der Analyst es anfasst.
Die v1-Gewichte sind vertretbar, aber sie sind Priors. nv/calibration.py passt sie
gegen gelabelte Ground-Truth an — Ereignisse, bei denen wir wissen, welche Teil des
Einbruchs waren und welche harmlos — und misst entscheidenderweise, ob die Anpassung
tatsächlich geholfen hat, sodass eine Kalibrierung nur übernommen wird, wenn sie den
Kalibrierungsfehler senkt und nicht nur Zahlen verschiebt.
Kalibrierte Konfidenz bedeutet eines: Die Konfidenz von NV für einen Schritt sollte der Wahrscheinlichkeit entsprechen, dass der Schritt tatsächlich auf dem Angriffspfad lag. Daher wird die Konfidenz jedes gelabelten Ereignisses als vorhergesagte Wahrscheinlichkeit behandelt, und das Harness passt Folgendes an:
Die verified/withheld-Schwellen sind Policy, keine Kalibrierung, und bleiben unangetastet.
Es berichtet Brier-Score, Log-Loss, ECE, AUC, eine Zuverlässigkeitstabelle und einen Sweep über die Vertrauensuntergrenze (True-Step-Recall vs. Benign-False-Positive-Rate auf jeder Untergrenze), vorher und nachher — so ist der Kompromiss zwischen Ehrlichkeit und Abdeckung nachvollziehbar und nicht bloß eine einzelne Zahl.```bash
python3 calibrate.py --labeled run_labeled.jsonl --origin live
--run-label "badzure-2026-07 tenant-x" --out calibration.json
python3 calibrate.py --out calibration.json
python3 run_nv.py events.jsonl out.json --authorize t.onmicrosoft.com
--calibration calibration.json
**Ground-Truth-Quelle.** Der echte Input ist Telemetrie aus einem BadZure / MAAD-AF-Lauf in einem echten Mandanten, gelabelt durch die Verknüpfung des einheitlichen Audit-Logs mit dem eigenen Aktivitätsprotokoll des Angriffstools (jedes Ereignis, das das Tool verursacht hat, ist im Log; alles andere ist gutartig — siehe `LABELED_SCHEMA` in `nv/calibration.py`). Bis du es auf einen echten Lauf richtest, liefert `eval/calibration_cases.py` einen **Proxy**-Korpus mit dokumentierter Form, und jedes daraus angepasste Artefakt ist in seiner Provenienz mit `source="proxy"` gekennzeichnet, sodass ein Proxy-Fit niemals mit einem Live-Fit verwechselt werden kann. `calibration.proxy.json` ist dieses gebündelte Proxy-Artefakt.
Auf dem gebündelten Proxy-Korpus ist der Fit eine klare Verbesserung — Brier 0.398 → 0.045, ECE 0.576 → 0.081, AUC 0.81 → 0.91, und die gutartige Falsch-Positiv-Rate an der 0.60-Untergrenze fällt von 0.69 auf 0.00 (die v1-Priors waren bei gutartiger Aktivität stark überkonfident). Der Proxy ist bewusst konservativ; erst ein Live-Mandanten-Lauf erzeugt die Gewichte, die du tatsächlich einsetzen solltest.
## Vertrauensintegrität (Phase 3)
Zwei erstklassige Kontrollen schützen die Rekonstruktion vor schlechten Eingaben:
- **Autorisierungsbereichs-Gate** (`nv/scope.py`) — NV weigert sich, auf einer Umgebung zu laufen, die nicht auf der autorisierten Liste steht. Führe es mit `--authorize <tenant-domain>` pro Umgebung aus, die du untersuchen darfst.
- **Musterquellen-Validierung** (`nv/validation.py`) — kein Muster gelangt in die Bibliothek, ohne Folgendes zu bestehen: (1) Allowlist vertrauenswürdiger Quellen, (2) Inhalts-Checksumme / Manipulationsprüfung, (3) Wohlgeformtheit des Schemas, (4) gültige Technik-ID im ATT&CK-Stil. Zu jedem zugelassenen Muster wird ein Audit-Datensatz geführt; Ablehnungen werden mit Angabe des Grunds protokolliert. Ein vergifteter oder fehlerhafter Feed wird vorgelagert gestoppt, bevor er eine falsche Rekonstruktion erzeugen kann. Dies ist dieselbe Skepsis, die die Engine gegenüber Beweisen anwendet, übertragen auf die Muster selbst.
---
## Das Wissen aktuell halten (der Weiterentwicklung von Angreifern voraus sein)
Eine Rekonstruktions-Engine ist nur so aktuell wie ihre Musterbibliothek plus ihre Fähigkeit, mit dem umzugehen, was die Bibliothek noch nie gesehen hat. NV geht Veraltung konstruktionsbedingt auf **zwei unabhängigen Fronten** an:
### 1. Die bekannte Schicht bleibt durch eine validierte Update-Pipeline aktuell
Die Bibliothek ist nicht hartcodiert — `nv/patterns.py` lädt jedes Muster (einschließlich des eingebauten Satzes) über `nv/validation.py`, sodass externe Feeds denselben vertrauenswürdigen Pfad nehmen. Die Live-Netzwerk-Clients, die diese Feeds planmäßig abrufen, sind in `nv/feeds.py` implementiert und werden von `update_feeds.py` gesteuert. Quellen, nach Vertrauensstufen:
- **MITRE ATT&CK (STIX)** — die maßgebliche Technik-Taxonomie. Der Connector liest den ATT&CK-STIX-Index, zieht die neueste Enterprise-Version und aktualisiert den maßgeblichen Techniknamen und die Taktik für jede Operation, über die NV Schlüsse zieht — und verwirft jede, deren Technik ATT&CK inzwischen zurückgezogen oder als veraltet gekennzeichnet hat. NV behält die Kontrolle über die Operation→Technik-Verknüpfung und den Basisraten-Prior; ATT&CK besitzt die Taxonomie.
- **Geprüfte CTI über TAXII 2.1** — ein vollständiger Client für Discovery → api-root → Collection → Objects. Er zieht STIX-Angriffsmuster-Objekte aus einer geprüften CTI-Collection und aktualisiert die Techniken, die NV verfolgt. Geringer gewichtet als ATT&CK.
- **Sigma-Community-Regelsatz** — wird als Git-Archiv abgerufen; jede Cloud-/Identitätsregel, die eine O365/Entra-Operation benennt und ein `attack.tXXXX`-Tag trägt, wird zu einem Operation→Technik-Kandidaten, mit einer Basisrate, die aus dem eigenen Schweregrad `level` der Regel abgeleitet und dann durch das Gewicht der Community-Quelle herunterskaliert wird. Regeln, die sich nicht zuordnen lassen, werden mit einem Grund übersprungen, nie erraten.
Bei einer Operationskollision wird die Vereinigung vor dem Commit nach aufsteigendem Vertrauen sortiert, sodass eine maßgebliche ATT&CK-Verknüpfung immer gegenüber einer Community-Verknüpfung gewinnt; Inhalte niedrigerer Stufen werden weiterhin zugelassen und als Bestätigung im Audit protokolliert. `update_library(candidates)` führt den gesamten Satz erneut durch die Validierung und baut die Bibliothek atomar neu auf, sodass ein vergifteter Feed die Bibliothek niemals halb aktualisiert hinterlassen kann.
**Zwei Allowlists, nicht eine.** Die Validierung macht den Zugang bereits vom Quellen-Tag abhängig; die Connectors fügen eine *Host*-Allowlist auf Netzwerkebene hinzu, sodass ein Connector nur von einem vertrauenswürdigen Host über TLS abrufen kann — das Transport-Pendant zur Quellen-Allowlist und ein Schutz gegen eine gekaperte oder falsch getippte Feed-URL. Jeder Abruf protokolliert den SHA256-Hash des Roh-Payloads, die URL und die Zeit als Provenienz, sodass ein späterer erneuter Abruf eine Änderung auf der Quellseite erkennen kann.
**Warum die Validierungsschicht umso wichtiger wird, je mehr die Feeds wachsen:** Je mehr du Updates automatisierst, desto mehr wird eine Auto-Update-Pipeline zu einem getarnten Vertrauensrisiko — ein falscher oder vergifteter Feed injiziert falsche Muster und erzeugt falsche Rekonstruktionen. NV behandelt die Aufnahme als potenziell feindlich: Allowlist, Checksumme, Schema und Audit-Trail für jedes Muster, bei jedem Update.
### 2. Die abduktive Schicht deckt ab, was noch kein Feed benannt hat
Feeds hinken der neuesten Angriffstechnik immer hinterher. Der abduktive Kern ist die Absicherung: Wenn eine beobachtete Operation mit **keinem** Bibliotheksmuster übereinstimmt, verwirft NV sie nicht — es rekonstruiert den wahrscheinlichsten Pfad aus ersten Prinzipien und kennzeichnet ihn mit `no known match` bei reduzierter Konfidenz. Dies wird in der Evaluations-Suite (`eval/ground_truth_cases.py`) validiert, wo ein absichtlich unbekannter Schritt des Token-Diebstahls einer verwalteten Identität erkannt, korrekt sequenziert und ehrlich unter die Vertrauensuntergrenze heruntergewichtet wird.
Zusammengenommen bedeuten diese, dass NV nie vollständig veraltet: Die bekannte Schicht verfolgt die veröffentlichte Front durch eine gegen Vergiftung resistente Pipeline, und die abduktive Schicht bewahrt das Tool davor, für die Eindringung blind zu werden, die die Front noch nicht eingeholt hat.
### Vorgeschlagene Update-Kadenz
`nv/feeds.py` enthält eine Kadenz pro Feed und `update_feeds.py` zieht nur, was fällig ist, sodass es direkt in cron oder einen systemd-Timer eingehängt werden kann:
- ATT&CK STIX — 90 Tage (einige offizielle Veröffentlichungen pro Jahr).
- CTI/TAXII — 7 Tage (sobald der Feed veröffentlicht wird), immer durch die Validierung.
- Sigma — 30 Tage.```bash
# run whatever is due, keeping state under ./.nv_feeds (cron-friendly)
python3 update_feeds.py
# force all feeds now but only report what would change
python3 update_feeds.py --force --dry-run
# run fully offline against captured fixtures (no network)
python3 update_feeds.py --offline eval/fixtures --force
Nach jeder Bibliotheksänderung eval/run_eval.py erneut ausführen, um zu bestätigen, dass bekannte Angriffsformen weiterhin
rekonstruiert werden, eval/validation_cases.py, um zu bestätigen, dass das Gate weiterhin fehlerhafte Eingaben ablehnt, und
eval/feeds_offline_test.py, um zu bestätigen, dass der Feed-Pfad Ende-zu-Ende intakt ist.
Die in nv_gui.html gezeigte Rekonstruktion basiert auf einem öffentlichen Forschungsdatensatz
— dem invictus-ir Office 365 unified audit log Corpus — nicht aus dem Live-Mandanten eines
Unternehmens. Er existiert, damit die Engine Ende-zu-Ende demonstriert und dogfooded werden kann, ohne dass
jemand mitwirken muss. Um NV wirklich zu nutzen, bindet eine Organisation ihre eigenen Entra/M365-
Auditdaten ein, wie unten beschrieben. In diesem Projekt sind keinerlei proprietäre oder Kundendaten enthalten.
NV läuft dort, wo Sie es ausführen; Ihre Logs müssen Ihre Umgebung nie verlassen. Vier Schritte:
1 — Auditprotokolle exportieren. NV liest das Microsoft 365 unified audit log. Beziehen Sie es
aus Microsoft Purview (Audit-Suche → CSV exportieren), dem Search-UnifiedAuditLog
Exchange Online PowerShell-Cmdlet, den Microsoft Graph auditLogs / signIns-
Endpunkten oder einem Sentinel/SIEM-Export von OfficeActivity und SigninLogs.
2 — Normalisieren Sie es in das Ereignismodell, über das NV nachdenkt:```bash python3 nv_extract_identity_events.py your_audit_export.csv your_events.jsonl
Dies behält Anmeldungen, Zustimmungserteilungen, Dienstprinzipal- und Rollenänderungen sowie
Postfachzugriffe bei — einschließlich Identitätsvorgängen, die NV nie benannt hat, sodass sie
weiterhin die abduktive Ebene erreichen — und verwirft den Rest. Es liest eine CSV mit der
standardmäßigen `AuditData`-Spalte oder JSON/JSONL, wobei jeder Datensatz ein `AuditData`-Objekt ist
(die Form, in der das invictus-ir-Forschungskorpus ausgeliefert wird).
**3 — Rekonstruktion, bereichsbegrenzt.** Die Engine weigert sich, auf einem Mandanten zu laufen, den du nicht
explizit autorisiert hast:```bash
python3 run_nv.py your_events.jsonl reconstruction.json \
--authorize yourtenant.onmicrosoft.com
4 — Ansicht. Öffnen Sie nv_gui.html und klicken Sie auf ⤒ load reconstruction.json, um auf die Datei zu verweisen, die die Engine gerade erzeugt hat — derselbe Bildschirm zeigt dann Ihren Vorfall, Ihre Entitäten und Ihre Konfidenzbänder. Jeder Punkt auf der Embedding-Canvas führt beim Klicken die Rekonstruktion für diese Entität erneut aus.
Die Engine ist substratunabhängig — nur das Operationsvokabular ist anbieterabhängig
(nv/providers.py). Der AWS-Pfad umfasst dieselben drei Schritte gegen CloudTrail:```bash
python3 nv_extract_cloudtrail_events.py cloudtrail.json aws_events.jsonl
python3 run_nv.py aws_events.jsonl reconstruction.json --authorize aws:123456789012
Der Ingest erfasst weiterhin IAM-/STS-/Anmeldeereignisse (einschließlich neuartiger IAM-Operationen, sodass sie die
abduktive Ebene erreichen) sowie S3-Objektabrufe und begrenzt den Gültigkeitsbereich auf das AWS-**Konto** statt auf eine
Mandantendomäne. Derselbe abduktive Kern, dasselbe Konfidenzmodell und dieselbe Vertrauensuntergrenze gelten unverändert.
Die GUI enthält außerdem ein **Demo-Daten-Banner** und einen In-App-Leitfaden "Connecting your own data",
damit jeder, der sie öffnet, versteht, dass die Rekonstruktion auf öffentlichen Beispieldaten basiert, bis
eigene Daten angebunden werden.
## Projektstruktur```
run_nv.py reconstruction engine entrypoint (scope-gated)
nv_extract_identity_events.py ingest: M365/Entra unified audit log -> event model
nv_extract_cloudtrail_events.py ingest: AWS CloudTrail -> event model [iteration 3]
update_feeds.py pull + validate threat-intel feeds on a cadence [iteration 1]
calibrate.py fit confidence weights from labeled ground truth [iteration 2]
nv/ the engine package
graph.py patterns.py validation.py confidence.py reconstruct.py scope.py
providers.py per-substrate op->ATT&CK vocabulary packs (Entra + AWS) [iteration 3]
feeds.py ATT&CK STIX / TAXII 2.1 / Sigma clients + scheduler [iteration 1]
calibration.py metrics + parameter fit [iteration 2]
eval/ evals + offline fixtures (no network, no tenant)
nv_gui.html pure view layer (loads engine reconstruction.json)
calibration.proxy.json bundled proxy calibration artifact [iteration 2]
Führen Sie alles vom Projektstamm aus, damit das nv-Paket importierbar ist.
python3 nv_extract_identity_events.py auditrecords.csv nv_identity_events.jsonl
python3 run_nv.py nv_identity_events.jsonl reconstruction.json
--trust-floor 0.6 --authorize your-tenant.onmicrosoft.com
Halten Sie die Pattern-Bibliothek aktuell und passen Sie die Konfidenz an:```bash
python3 update_feeds.py # pull + validate feeds that are due
python3 calibrate.py --labeled run.jsonl --origin live --out calibration.json
python3 eval/run_eval.py # attack shapes reconstruct correctly python3 eval/validation_cases.py # poisoned patterns are rejected python3 eval/feeds_offline_test.py # feed connectors + scheduler (offline) python3 eval/providers_aws_test.py # AWS chain reconstructs through the same engine python3 calibrate.py # calibration harness on the bundled proxy corpus
---
## Status
**Durchgängig funktionsfähig mit echten Daten** (invictus-ir O365-Datensatz), über den gesamten Plan hinweg:
| Phase | Element | Status |
|---|---|---|
| 1 | Normalisiertes Ereignis-/Entitätsmodell | erledigt |
| 1 | Ingest + Normalisierung (Entra/M365-Brückenkopf) | erledigt |
| 2 | Bekannte Ebene (ATT&CK-Musterbibliothek) | erledigt |
| 2 | Konfidenzmodell zur Beweisbekräftigung | erledigt |
| 2 | Vertrauensuntergrenze im Output-Vertrag | erledigt |
| 2 | Abduktiver Kern (unbekannte Ebene) | erledigt, eval-belegt |
| 2 | Rangfolge konkurrierender Hypothesen | erledigt |
| 3 | Validierungsebene für Musterquellen | erledigt |
| 3 | Kontrolle des autorisierten Umfangs | erledigt |
| 3 | Live-Feed-Konnektoren (ATT&CK STIX / TAXII / Sigma) + Scheduler | erledigt |
| 4 | Zweispaltige Ansicht auf realer Engine-Ausgabe | erledigt |
| 4 | Embedding-/Ähnlichkeits-Canvas | erledigt |
| 4 | Canvas-gesteuerte Rekonstruktion pro Entität (Klick führt die Kette erneut aus) | erledigt |
| 4 | GUI lädt `reconstruction.json` der Engine (weisen Sie sie auf Ihre Datei) | erledigt |
| 4 | Multi-Provider-Substrat (AWS CloudTrail, eval-belegt) | erledigt |
| 5 | Ästhetik / Theming | erledigt |
| 5 | Konfidenzkalibrierungs-Harness + Engine-Integration | erledigt |
### Ehrlich benannte bekannte Lücken (nächste Iterationen)
- **Kalibrierungswerte für Live-Mandanten.** Die Kalibrierungs-*Harness* ist vollständig und die
Schnittstelle ist erprobt, aber die mitgelieferte `calibration.proxy.json` ist an Proxy-Daten mit
dokumentierter Form angepasst. Einsetzbare Gewichte erfordern, die Harness gegen einen echten
BadZure / MAAD-AF-Lauf auszuführen – ein operativer Schritt für den Anwender.
- **Feed-getriebenes Vokabularwachstum.** Die Konnektoren aktualisieren die Operationen, über die NV bereits
Schlussfolgerungen zieht; einen Feed eine neue Operation *einführen* zu lassen (und sie in die
initial/pivot/collection-Klassifizierung einzubinden) ist zukünftige Arbeit.
- **Tiefe des zweiten Providers.** AWS ist als Beleg für die Substratunabhängigkeit enthalten (Paket +
Ingest + Evaluierung), aber nur IAM/STS/S3. Die Erweiterung des AWS-Pakets, das Hinzufügen providerspezifischer
Feed-Konnektoren und ein drittes Substrat (GCP, Okta) sind die nächsten Schritte.
---
## Lizenz
Nimbus Vestige ist **quelltextverfügbar** unter der **PolyForm Noncommercial License
1.0.0** (siehe [LICENSE](https://gitlab.com/dobybaxter127/nimbus-vestige/-/blob/main/LICENSE)). Das gesamte Tool – Rekonstruktions-Engine, beide
Provider-Ingests, GUI und Evaluierungs-Harness – kann frei eingesehen, ausgeführt und
für jeden **nichtkommerziellen** Zweck verwendet werden: private Projekte, Forschung, Bildung,
gemeinnützige Organisationen und Evaluierung. Lesen Sie jede Zeile, bevor Sie sich entscheiden.
**Kommerzielle Nutzung erfordert eine kostenpflichtige Lizenz** – die Verwendung in einem Produkt oder Dienst, den Sie
verkaufen oder hosten, in Produktions- oder internen Systemen eines gewinnorientierten Unternehmens oder bei
bezahlten Incident-Response- oder Kundenaufträgen. Siehe
[COMMERCIAL-LICENSE.md](https://gitlab.com/dobybaxter127/nimbus-vestige/-/blob/main/COMMERCIAL-LICENSE.md).
---
### Autor
Doby Baxter 2026