Das SBOM in einem Absatz
Eine Software Bill of Materials (SBOM) ist ein Inventar jeder Drittanbieter-Komponente, von der eine Software abhängt — Name, Version und ein Identifikator, der präzise genug ist, damit Beschaffungs- oder Sicherheitsteams ihn nachschlagen können. CycloneDX ist einer der beiden dominierenden SBOM-Standards (der andere ist SPDX), gepflegt von OWASP, aktuell in Spezifikationsversion 1.5. Anders als ein SARIF-Bericht beschreibt ein SBOM keine Schwachstellen — es beschreibt, woraus Ihre Software besteht. Beide ergänzen sich: SARIF beantwortet „was wurde gefunden", ein SBOM beantwortet „wovon hängt es ab".
Das SBOM erzeugen
Ein einziges Flag, dieselbe CLI wie alles andere:
./staticcodeaudit-linux-x86_64 /path/to/project --sbomDies schreibt SCA-SBOM-<timestamp>.json neben den gewohnten HTML-Bericht. Der Scanner erkennt automatisch Abhängigkeits-Manifeste im Projekt-Root und den eingeschlossenen Pfaden — keine zusätzliche Konfiguration nötig.
Gelesene Manifest-Dateien
Sechs Abhängigkeits-Manifestformate werden direkt geparst, die die Sprachen abdecken, die dieser Scanner auf Schwachstellen prüft:
| Manifest | Ecosystem |
|---|---|
requirements.txt / pyproject.toml |
PyPI (Python) |
package.json |
npm (JavaScript/TypeScript) |
pom.xml |
Maven (Java) |
build.gradle |
Gradle (Java) |
*.csproj |
NuGet (C#) |
composer.json |
Packagist (PHP) |
Jedes Manifest wird einmal pro Scan gelesen (Projekt-Root plus konfigurierte Include-Pfade, dedupliziert nach normalisiertem Pfad) — ein Projekt mit sowohl requirements.txt als auch package.json erhält Komponenten aus beiden im selben SBOM.
Was die Datei tatsächlich enthält
Ein reales Beispiel — zwei fixierte Abhängigkeiten in einer requirements.txt:
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"version": 1,
"metadata": {
"timestamp": "2026-08-07T18:30:12.104Z",
"tools": [{ "name": "StaticCodeAudit", "version": "1.0.0" }],
"component": {
"type": "application",
"name": "your-project",
"version": "1.0.0"
}
},
"components": [
{
"type": "library",
"name": "requests",
"version": "2.31.0",
"purl": "pkg:pypi/requests@2.31.0"
},
{
"type": "library",
"name": "flask",
"version": "3.0.0",
"purl": "pkg:pypi/flask@3.0.0"
}
]
}Jede Komponente trägt eine Package URL (purl) — einen standardisierten Identifikator (pkg:pypi/requests@2.31.0), den Beschaffungstools und Schwachstellendatenbanken eindeutig zuordnen können. Der Export listet Name, Version und purl; er berechnet oder enthält keine Datei-Hashes pro Abhängigkeit.
SBOM oder SARIF — nie beides im selben Lauf
SBOM- und SARIF-Exporte schließen sich pro Aufruf gegenseitig aus — sie bedienen unterschiedliche Konsumenten (Beschaffung/Inventar vs. Schwachstellen-Triage), und sie zu kombinieren würde beides nachgelagert schwerer korrekt verarbeitbar machen:
$ ./staticcodeaudit-linux-x86_64 /path/to/project --sarif --sbom
❌ --sarif and --sbom are mutually exclusive. Use one or the other.Führen Sie den Scan in der CI zweimal aus, wenn eine Pipeline beide Artefakte vom selben Commit benötigt — jeder Lauf dauert bei einer kleinen bis mittleren Codebasis deutlich unter einer Sekunde. Siehe den SARIF-Export-Leitfaden für die Schwachstellenseite.
Wo das für regulierte Einrichtungen passt
Für Organisationen im Anwendungsbereich der EU-NIS2-Richtlinie fordert Artikel 21(2)(d) „Maßnahmen", die die Sicherheit der Lieferkette abdecken. Ein CycloneDX-SBOM — kombiniert mit SARIF-Schwachstellenfunden aus demselben Code — ist genau die Art konkreter, maschinenlesbarer Nachweis, auf dem ein Prüfer oder Beschaffungs-Reviewer aufbauen kann: exakt welche Abhängigkeiten in einem gegebenen Release stecken, in welcher Version, abgeglichen mit bekannten Schwachstellen. Mehr Details auf der Seite für regulierte Branchen.
Häufig gestellte Fragen
Sendet die Erzeugung eines SBOM meine Abhängigkeitsliste irgendwohin?
Nein. Das SBOM wird vollständig aus lokalen Dateien erstellt (Ihre requirements.txt, package.json usw.) und lokal auf die Festplatte geschrieben. StaticCodeAudit macht während eines Scans keine ausgehenden Netzwerkaufrufe — die Erzeugung eines SBOM ändert daran nichts, da keine externe Datenbankabfrage beteiligt ist.
Enthält das SBOM bekannte Schwachstellen für jede Abhängigkeit?
Nein — dafür gibt es das Flag --with-deps und den SARIF-Export. Das SBOM selbst ist ein reines Inventar (CycloneDX-components-Array): Name, Version, purl. Der Abgleich von Komponenten mit Schwachstellendatenbanken ist ein separater Schritt, der typischerweise von dem System durchgeführt wird, das das SBOM nachgelagert konsumiert.
Was, wenn mein Projekt kein erkanntes Abhängigkeits-Manifest hat?
Das SBOM wird trotzdem erzeugt, mit einem leeren components-Array — gültiges CycloneDX 1.5, das einfach eine Anwendung ohne deklarierte Drittanbieter-Abhängigkeiten beschreibt. Zu erwarten z. B. bei einem reinen HTML- oder Infrastructure-as-Code-Projekt ohne requirements.txt/package.json-Äquivalent.
Kann ich ein SBOM für ein Monorepo mit mehreren Manifesten erhalten?
Ja — der Scanner durchläuft das Projekt-Root plus jeden unter include in audit.config.json gelisteten Pfad und führt Komponenten aus jedem gefundenen Manifest zusammen (z. B. tragen eine package.json im Root und eine verschachtelte backend/requirements.txt im selben Repo beide zu einem einzigen SBOM bei).
Ein vollständiges SBOM an echtem Code sehen
Öffnen Sie den Live-Demo-Bericht — keine Installation, keine Anmeldung — oder führen Sie die Binary gegen Ihr eigenes Projekt aus und prüfen Sie das erzeugte SBOM direkt.
Live-Bericht öffnen Demo-Binary herunterladen