ndaal SBOM Auditor

Eine Single-Binary-Offline-Webanwendung zur Untersuchung von SBOM-Dateien (Software Bill of Materials). Laden Sie ein SBOM hoch oder importieren Sie einen Ordner mit solchen, analysieren Sie jedes mit einem Ensemble unabhängiger Werkzeuge, prüfen Sie die normalisierten Befunde in einer lokalen Benutzeroberfläche und exportieren Sie das Ergebnis in acht Formaten. Keine Installation, kein Netzwerkzugriff, keine Telemetrie.

English · Deutsch · Français · Español · Italiano

Was es tut

1. Einlesen — laden Sie ein SBOM im Browser hoch oder importieren Sie jedes SBOM in einem konfigurierbaren Ordner. CycloneDX (JSON/XML), SPDX (JSON/tag-value und 3.0 JSON-LD) und syft-json werden erkannt; Dateien werden inhaltsgehasht und dedupliziert.
2. Analysieren — führen Sie die aktivierten Werkzeuge gegen das SBOM aus, jedes als isolierter Subprozess unter einer Frist und einem Nebenläufigkeitslimit. Ein fehlendes Werkzeug ist ein sichtbar unterscheidbarer Skip; ein installiertes Werkzeug, das nicht startet oder nicht innerhalb von 15 Sekunden antwortet, ist ein Fehler, der den Grund nennt. Keines von beiden wird jemals als sauberes Ergebnis gemeldet.
3. Befunde — die Ausgabe jedes Werkzeugs wird auf eine gemeinsame Form normalisiert, wobei der CVE-Alias aus dem GHSA/OSV-Bezeichner des Werkzeugs aufgelöst wird, und pro Werkzeug mit Schweregrad-Badges angezeigt.
4. Bewerten — benoten Sie das SBOM anhand aller siebzehn CISA-2026-Mindestelemente und unterscheiden Sie dabei ein explizites NOASSERTION eines Lieferanten von einem schlicht fehlenden Feld.
5. Suchen — finden Sie heraus, welche Ihrer SBOMs eine bestimmte Komponente deklarieren, über den gesamten Korpus hinweg, nach Name oder Paket-URL.
6. Exportieren — schreiben Sie die Analyse als SARIF 2.1, SARIF 2.2, Markdown, ODT, DOCX, PDF und CSAF 2.1 / 2.2-Advisories. Export persistiert die ausgewählten Formate in das Exportverzeichnis des Servers, jedes begleitet von fünf kryptografischen Hash-Sidecars; Start download rendert dieselben Formate im Speicher und streamt sie an den Browser — ein Dokument oder ein ZIP-Bundle für mehrere — und schreibt nichts auf die Festplatte.

Dashboard gespeicherter SBOMs

Die Startseite (/) listet jedes gespeicherte SBOM auf und bleibt nutzbar, während der Korpus wächst:

• Seitenweise — 25 Zeilen pro Seite, mit einer Beschriftung „Zeige X–Y von N" und Zurück-/Seite-/Weiter-Steuerelementen.
• Sortierbare Spalten — klicken Sie auf die Kopfzeile Name, Format oder Components, um danach zu sortieren; klicken Sie erneut auf die Kopfzeile, um die Richtung umzukehren.
• Neuester Upload zuerst — die Liste öffnet mit dem zuletzt hochgeladenen SBOM, dessen Zeit in der Spalte Last uploaded steht. Das Hochladen eines bereits gespeicherten SBOMs verschiebt es zurück an die Spitze; seine Detailseite behält die ursprüngliche Ingested-Zeit neben Last uploaded.
• Formatfilter — grenzen Sie die Liste auf ein Format ein (CycloneDX JSON/XML, SPDX JSON, SPDX 3.0 JSON, SPDX tag-value, Syft JSON oder Unknown); eine Reset-Schaltfläche löscht die Filter, während die aktuelle Sortierung erhalten bleibt.
• Severity-Spalte — eine am weitesten rechts stehende Spalte, nach Last uploaded, zeigt den einzelnen höchsten Befund-Schweregrad jedes SBOMs (Critical, High, Medium, Low oder Negligible) oder „—", wenn es noch keine Befunde hat, mit einem passenden Schweregradfilter.
• Volltextsuche — ein Suchfeld, gestützt auf einen tantivy-Volltextindex, gleicht den Namen, das Format und die Spec-Version eines SBOMs sowie die Namen und Paket-URLs der darin enthaltenen Komponenten ab, sodass eine Abfrage wie log4j oder openssl jedes SBOM findet, das diese Komponente enthält. Die Abfrage ist längenbeschränkt und wird nachsichtig geparst.

Komponentensuche

/components beantwortet die umgekehrte Frage — welche meiner SBOMs deklarieren diese Komponente — über den gesamten Korpus auf einmal, nach Komponentennamen oder exakter Paket-URL. Sie liest einen dedizierten Komponentenindex, der beim Einlesen aufgebaut wird, getrennt vom Volltextindex des Dashboards.

Da ein veralteter Index ein tatsächlich betroffenes SBOM als „nicht betroffen" erscheinen ließe, gibt die Seite an, wie viele SBOMs noch nicht indiziert sind, und bietet Rebuild index, was die zurückbehaltenen Bytes für genau diese erneut parst. Eine Suche ist erst vollständig, wenn diese Warnung verschwunden ist.

„Indiziert" bedeutet, dass der Index aufgebaut wurde, was nicht dasselbe ist wie „Zeilen erzeugt": ein reines Metadaten-SBOM deklariert keine Komponenten, trägt also keine bei und ist dennoch vollständig indiziert. Der Store zeichnet die Tatsache der Indizierung pro SBOM auf (Schema v8, components_indexed_at), statt sie aus der Existenz von Zeilen abzuleiten — die Ableitung bedeutete, dass ein komponentenfreies SBOM die Menge „noch nicht indiziert" nie verlassen konnte, sodass die Warnung jeden Rebuild überlebte und die Schaltfläche dieselben SBOMs für immer als frisch indiziert meldete. Ein Upgrade migriert automatisch und füllt alles nach, was bereits Zeilen hatte; ein Rebuild erledigt den Rest.

Analyzer-Ensemble

Jedes Werkzeug ist zur Laufzeit optional und wird auf PATH erkannt (überschreiben Sie das Binary mit SBA_TOOL_<NAME>_BIN). Befunde hängen nie von einem einzelnen Werkzeug ab. Vor jedem Scan wird das Werkzeug einmal mit seinem Versionsargument gestartet: kein Binary bedeutet skip (not found on PATH), während ein Binary, das nicht gestartet werden kann oder innerhalb von 15 Sekunden keine Antwort liefert, fail mit diesem Grund bedeutet.

Werkzeug	Rolle	Verifiziert gegen
syft	SBOM-Normalisierer / CycloneDX-1.6-Konverter	1.52.0
grype	CVE-Matcher	0.119.0
trivy	Schwachstellenscanner	0.74.0
osv-scanner	OSV-Datenbankabfragen	2.4.0, 2.6.0
bomber	Unabhängiger Ensemble-Matcher	0.5.1
bomdrift	Supply-Chain-Drift / Typosquat (SARIF)	0.9.9
inspektr	SBOM-Schwachstellenscanner (JSON)	0.1.9
shieldbom	Offline-Eingebettet/IoT-CVE-Scanner (SARIF)	0.3.0
provenant	Lizenz / Copyright / Provenienz (ScanCode)	1.0.10

„Verifiziert gegen" ist die Version, mit der jeder Aufruf tatsächlich ausgeführt wurde, keine Untergrenze und keine Fixierung: Werkzeuge werden zur Laufzeit auf PATH aufgelöst und jede kompatible Version funktioniert. osv-scanner listet zwei auf, weil 2.6.0 erneut verifiziert wurde, nachdem die 2.x-Linie ihr Logging geändert hatte — die dokumentierte Form scan --lockfile <input> --format json ist unverändert und beendet sich bei Befunden weiterhin mit einem Nicht-Null-Code, sodass keine Codeänderung nötig war.