Was macht SBOM-Analyse für Lieferketten-Sicherheitslücken?
Wann verwenden
- Neue regulatorische Anforderungen (EO 14028, EU CRA) schreiben eine SBOM-Analyse für Softwarelieferungen vor
- Das Sicherheitsteam muss Drittanbieterrisiken durch Scannen von SBOMs der Anbieter bewerten
- CI/CD-Pipeline erfordert automatisierte Sicherheitsüberprüfungen der generierten SBOMs
- Vorfallreaktion muss feststellen, ob eine neu offengelegte CVE die eingesetzte Software betrifft
- Das Beschaffungsteam benötigt eine Risikobewertung der Lieferkette für einen Softwarekauf
Nicht verwenden für das Laufzeit-Scannen von Live-Systemen; verwenden Sie stattdessen Container-Scanning-Tools (Trivy, Grype CLI) oder hostbasierte Schwachstellenscanner (Nessus, Qualys).
Voraussetzungen
- SBOM-Datei im CycloneDX JSON (v1.4+) oder SPDX JSON (v2.3+) Format
- Python 3.9+ mit installierten Bibliotheken requests, networkx und packaging
- NVD API-Key (kostenlos, abrufbar unter https://nvd.nist.gov/developers/request-an-api-key) für höhere Ratenlimits
- Netzwerkzugriff auf NVD API (https://services.nvd.nist.gov/rest/json/cves/2.0)
- Optional: syft zur SBOM-Erstellung, grype zur Kreuzvalidierung
Workflow
Schritt 1: SBOM generieren (falls nicht vorhanden)
Verwenden Sie syft, um eine SBOM aus einem Container-Image oder Projektverzeichnis zu erstellen:
# CycloneDX JSON aus einem Container-Image generieren
syft alpine:latest -o cyclonedx-json > sbom-cyclonedx.json
# SPDX JSON aus einem Projektverzeichnis generieren
syft dir:/pfad/zum/projekt -o spdx-json > sbom-spdx.json
# Aus einem laufenden Container generieren
syft docker:mein-app-container -o cyclonedx-json > sbom.json
Syft unterstützt über 30 Paket-Ökosysteme, darunter npm, PyPI, Maven, Go-Module, apt, apk und RPM. Die generierte SBOM enthält Paketnamen, Versionen, Lizenzen, CPE-Identifikatoren und PURL-Referenzen (Package URL).
Schritt 2: SBOM parsen und Komponenten extrahieren
Analysieren Sie die SBOM, um alle Softwarekomponenten mit ihren Identifikatoren zu extrahieren:
CycloneDX JSON Struktur:
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"components": [
{
"type": "library",
"name": "lodash",
"version": "4.17.20",
"purl": "pkg:npm/[email protected]",
"cpe": "cpe:2.3:a:lodash:lodash:4.17.20:*:*:*:*:*:*:*",
"licenses": [{"license": {"id": "MIT"}}]
}
],
"dependencies": [
{"ref": "pkg:npm/[email protected]", "dependsOn": ["pkg:npm/[email protected]"]}
]
}
SPDX JSON Struktur:
{
"spdxVersion": "SPDX-2.3",
"packages": [
{
"name": "lodash",
"versionInfo": "4.17.20",
"externalRefs": [
{"referenceType": "purl", "referenceLocator": "pkg:npm/[email protected]"},
{"referenceType": "cpe23Type", "referenceLocator": "cpe:2.3:a:lodash:lodash:4.17.20:*:*:*:*:*:*:*"}
],
"licenseConcluded": "MIT"
}
],
"relationships": [
{"spdxElementId": "SPDXRef-express", "relatedSpdxElement": "SPDXRef-lodash",
"relationshipType": "DEPENDS_ON"}
]
}
Schritt 3: Komponenten mit der NVD CVE-Datenbank korrelieren
Fragen Sie die NVD 2.0 API ab, um bekannte Sicherheitslücken für jede Komponente zu finden:
import requests
NVD_API = "https://services.nvd.nist.gov/rest/json/cves/2.0"
def search_cves_by_cpe(cpe_name, api_key=None):
params = {"cpeName": cpe_name, "resultsPerPage": 50}
headers = {"apiKey": api_key} if api_key else {}
resp = requests.get(NVD_API, params=params, headers=headers, timeout=30)
resp.raise_for_status()
return resp.json().get("vulnerabilities", [])
def search_cves_by_keyword(keyword, version=None, api_key=None):
params = {"keywordSearch": keyword, "resultsPerPage": 50}
headers = {"apiKey": api_key} if api_key else {}
resp = requests.get(NVD_API, params=params, headers=headers, timeout=30)
resp.raise_for_status()
return resp.json().get("vulnerabilities", [])
Die NVD API unterstützt die Suche nach CPE-Namen (am genauesten), Stichwort, CVE-ID und Datumsbereichen. Ratenlimits: 5 Anfragen/30 Sekunden ohne API-Key, 50 Anfragen/30 Sekunden mit Key.
Schritt 4: Abhängigkeitsgraph erstellen und transitive Risiken identifizieren
Erstellen Sie einen gerichteten Graphen der Abhängigkeiten, um die Ausbreitung von Sicherheitslücken zu verfolgen:
import networkx as nx
def build_dependency_graph(sbom):
G = nx.DiGraph()
# Knoten für jede Komponente hinzufügen
for comp in sbom["components"]:
G.add_node(comp["purl"], name=comp["name"], version=comp["version"])
# Kanten aus Abhängigkeitsbeziehungen hinzufügen
for dep in sbom.get("dependencies", []):
for child in dep.get("dependsOn", []):
G.add_edge(dep["ref"], child)
return G
Die Analyse transitiver Abhängigkeiten identifiziert Komponenten, die nicht direkt eingebunden sind, aber über Abhängigkeitsketten mitgezogen werden. Eine Schwachstelle in einer tief verschachtelten transitiven Abhängigkeit (z. B. 4 Ebenen tief) stellt immer noch ein Risiko dar, kann aber schwieriger zu beheben sein.
Wichtige Graphmetriken für die Risikobewertung:
- Eingangsgrad: Wie viele Komponenten hängen von dieser ab (hoher Eingangsgrad = hohe Auswirkungsbreite)
- Kürzester Pfad zur Wurzel: Entfernung vom Anwendungseinstiegspunkt (näher = leichter ausnutzbar)
- Betweenness-Zentralität: Komponenten, die auf vielen Abhängigkeitspfaden liegen (Engpassrisiko)
Schritt 5: Risikowerte berechnen
Fassen Sie die Schwachstellendaten zu Komponenten- und Gesamtrisikowerten zusammen:
Risikoberechnung:
━━━━━━━━━━━━━━━━━━━━━━
Komponentenrisiko = max(CVSS-Scores aller CVEs, die die Komponente betreffen)
Gewichtetes Risiko = Komponentenrisiko * Abhängigkeitsfaktor
wobei Abhängigkeitsfaktor = 1.0 + (0.1 * Eingangsgrad)
(mehr Abhängige = höhere organisatorische Auswirkung)
Gesamt-SBOM-Risiko = gewichteter Durchschnitt aller Komponentenrisiken
gewichtet nach Abhängigkeitszentralität
Risikostufen:
KRITISCH: CVSS >= 9.0 oder bekanntermaßen ausgenutzt (CISA KEV)
HOCH: CVSS >= 7.0
MITTEL: CVSS >= 4.0
NIEDRIG: CVSS < 4.0
Schritt 6: Mit Grype kreuzvalidieren
Verwenden Sie grype, um die SBOM unabhängig zu scannen und die Ergebnisse zu vergleichen:
# CycloneDX SBOM mit grype scannen
grype sbom:sbom-cyclonedx.json -o json > grype-ergebnise.json
# SPDX SBOM scannen
grype sbom:sbom-spdx.json -o table
# Nach Schweregrad filtern
grype sbom:sbom-cyclonedx.json --only-fixed --fail-on critical
Grype bezieht Schwachstellendaten von NVD, GitHub Security Advisories, Alpine SecDB, Red Hat, Debian, Ubuntu, Amazon Linux und Oracle Sicherheitsdatenbanken und bietet eine breitere Abdeckung als NVD allein.
Schritt 7: Compliance-Bericht erstellen
Erstellen Sie einen strukturierten Bericht für die regulatorische Compliance:
SBOM SCHWACHSTELLEN ANALYSE BERICHT
====================================
SBOM-Datei: app-sbom-cyclonedx.json
Format: CycloneDX v1.5
Analysedatum: 2026-03-19
Gesamtkomponenten: 247
Gesamtabhängigkeiten: 1.842 (direkt: 34, transitiv: 213)
SCHWACHSTELLEN-ZUSAMMENFASSUNG
Kritisch: 3 Komponenten / 5 CVEs
Hoch: 11 Komponenten / 18 CVEs
Mittel: 27 Komponenten / 41 CVEs
Niedrig: 8 Komponenten / 12 CVEs
KRITISCHE ERKENNTNISSE
1. [email protected]
CVE-2021-23337 (CVSS 7.2) - Befehlseinschleusung via Vorlage
CVE-2020-28500 (CVSS 5.3) - ReDoS in trimEnd
Abhängige: 14 Komponenten (hohe Auswirkungsbreite)
Fix: Upgrade auf 4.17.21+
2. [email protected]
CVE-2021-44228 (CVSS 10.0) - Log4Shell RCE [CISA KEV]
CVE-2021-45046 (CVSS 9.0) - Unvollständige Fix-Umgehung
Abhängige: 8 Komponenten
Fix: Upgrade auf 2.17.1+
ABHÄNGIGKEITSGRAPH-RISIKEN
Meistabhängig: [email protected] (47 Abhängige)
Tiefste Kette: app -> framework -> adapter -> codec -> zlib (5 Ebenen)
Engpasskomponenten: 3 Komponenten auf >50% der Abhängigkeitspfade
LIZENZ-COMPLIANCE
Copyleft-Lizenzen gefunden: 2 (GPL-3.0 in libxml2, AGPL-3.0 in mongodb-driver)
Überprüfung für kommerziellen Vertrieb erforderlich
Schlüsselkonzepte
| Begriff | Definition |
|---|---|
| SBOM | Software-Stückliste; formales Inventar aller Komponenten, Bibliotheken und Abhängigkeiten in einem Softwareprodukt |
| CycloneDX | Von OWASP gepflegter SBOM-Standard, der JSON-, XML- und Protobuf-Formate mit Abhängigkeitsgraph und Schwachstellendaten unterstützt |
| SPDX | Linux Foundation SBOM-Standard mit Fokus auf Lizenz-Compliance und Unterstützung für detaillierte Paket-, Datei- und Snippet-Ebene |
| PURL | Package URL; standardisiertes Schema zur Identifizierung von Softwarepaketen über Ökosysteme hinweg (z.B. pkg:npm/[email protected]) |
| CPE | Common Platform Enumeration; NIST-Benennungsschema für IT-Produkte, verwendet zur Korrelation mit NVD CVE-Daten |
| NVD | National Vulnerability Database; US-Regierungsdatenbank für Schwachstellendaten, indexiert nach CVE-Identifikatoren |
| Transitive Abhängigkeit | Eine Abhängigkeit, die nicht direkt deklariert ist, sondern über die Abhängigkeitskette direkter Abhängigkeiten mitgezogen wird |
| CISA KEV | CISA Known Exploited Vulnerabilities-Katalog; CVEs, die bekanntermaßen aktiv in freier Wildbahn ausgenutzt werden |
Werkzeuge & Systeme
- syft (Anchore): Open-Source-SBOM-Generator, der über 30 Paket-Ökosysteme und CycloneDX/SPDX-Ausgabe unterstützt
- grype (Anchore): Schwachstellenscanner, der SBOMs als Eingabe akzeptiert und mit mehreren Advisory-Datenbanken korreliert
- cyclonedx-python-lib: Python-Bibliothek zum programmatischen Erstellen, Parsen und Validieren von CycloneDX-SBOMs
- lib4sbom: Python-Bibliothek zum Parsen von SBOMs sowohl im SPDX- als auch im CycloneDX-Format
- nvdlib: Python-Wrapper für die NVD 2.0 API, der CVE- und CPE-Abfragen mit Ratenlimit-Management unterstützt
- OWASP Dependency-Track: Plattform für kontinuierliche SBOM-Analyse, Schwachstellenverfolgung und Richtliniendurchsetzung
Häufige Szenarien
Szenario: Bewertung von Anbietersoftware nach Log4Shell-Offenlegung
Kontext: Nach der Offenlegung von Log4Shell (CVE-2021-44228) muss das Sicherheitsteam feststellen, welche anbietergelieferten Anwendungen anfällige Versionen von log4j enthalten. Mehrere Anbieter haben vertragsgemäß SBOMs bereitgestellt.
Vorgehen:
- Alle Anbieter-SBOMs sammeln (CycloneDX- oder SPDX-JSON-Format)
- Jede SBOM parsen und nach log4j-core-Komponenten mit Versionen < 2.17.1 suchen
- NVD API nach den spezifischen CVEs abfragen (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105)
- Abhängigkeitsgraphen erstellen, um zu identifizieren, welche Anwendungskomponenten von log4j abhängen
- Auswirkungsbreite berechnen: wie viele Dienste und Endpunkte sind exponiert
- Priorisierten Behebungsbericht erstellen, sortiert nach Exposition und geschäftlicher Kritikalität
- Ergebnisse mit Grype-Scan derselben SBOMs kreuzvalidieren
Fallstricke:
- Anbieter-SBOMs können unvollständig sein und shaded/gebündelte JAR-Dateien fehlen, die log4j einbetten
- Unterschiede in SPDX- und CycloneDX-Versionen können die Parser-Kompatibilität beeinträchtigen
- NVD API-Ratenlimits können die Analyse verlangsamen, wenn Hunderte von Komponenten ohne API-Key gescannt werden
- CPE-Namen in SBOMs können nicht exakt mit NVD-Einträgen übereinstimmen und erfordern unscharfen Abgleich
- Transitive Abhängigkeiten können log4j enthalten, auch wenn es keine direkte Abhängigkeit ist