SBOM-Import

Von SBOM oder Lockfile zur Compliance-Seite

Wenn Sie bereits CycloneDX, npm-Lockfiles oder ähnliche Inputs erzeugen, erfahren Sie hier, wie Sie daraus einen geprüften Offenlegungs-Nachweis machen.

Zuletzt aktualisiert: 2. Juli 2026

Wenn Sie bereits CycloneDX-SBOMs, SPDX-Dateien oder Exporte aus FOSSA, Snyk, Mend oder Syft erzeugen, haben Sie das Rohmaterial für Lizenz-Compliance. Eine Software-Stückliste listet Komponenten auf: Namen, Versionen, Lieferanten, Hashes. Eine Lizenz-Compliance-Seite ergänzt geprüfte Lizenzkennungen, vollständigen Lizenztext, Namensnennung und eine stabile URL für Drittanbieter-Lizenz-Offenlegung.

SBOM-Arbeit unterstützt Security- und regulatorische Programme (einschließlich CRA-Komponentendokumentation). Lizenz-Compliance-Seiten beantworten Fragen von Beschaffung und Recht zu Open-Source-Lizenzpflichten. Die Pipeline von SBOM zur Compliance-Seite lautet: Import, Anreicherung, Prüfung, Veröffentlichung. Nicht unverändert exportieren und hochladen.

Was ist der Unterschied zwischen einem SBOM und einer Lizenz-Compliance-Seite?

Ein SBOM ist ein maschinenlesbarer Bestand, optimiert für Schwachstellenabgleich und Lieferketten-Tools; eine Lizenz-Compliance-Seite ist menschenlesbare Drittanbieter-Lizenz-Offenlegung, optimiert für Beschaffungsprüfer, die während der Anbieter-Due-Diligence einen Browser-Tab öffnen. Sie beantworten unterschiedliche Fragen und ersetzen sich selten gegenseitig.

Käufer fragen in unterschiedlichen Fragebogenabschnitten nach beidem. Wenn Sie nur ein SBOM einreichen, obwohl eine Open-Source-Lizenzseite verlangt wird, zwingen Sie sie, vollständigen Lizenztext manuell nachzujagen, oder Sie fallen bei unvollständiger Offenlegung durch.

	SBOM	Compliance-Seite
Inhalt	Komponentenidentität, Versionen, Hashes, Lieferanten	Geprüfte Lizenzen, vollständiger Lizenztext, Namensnennung, Produktumfang
Format	JSON oder XML, aktualisiert durch die CI	Öffentliche URL mit Publish-Gates, plus Exporte pro Release
Zielgruppe	Security-Tools und CRA-Programme	Beschaffungs- und Rechtsprüfer

Schritt 1: SBOM oder Lockfile importieren

Bringen Sie CycloneDX, SPDX oder Paket-Lockfiles in Ihren Offenlegungs-Workflow. Ordnen Sie SBOM-Komponenten Zeilen in Ihrer Prüfliste zu. Jede Zeile beginnt als prüfungsbedürftig. SBOM-Lizenzfelder sind Hinweise, keine Freigaben.

Ein SBOM pro Produkt pro Release. Führen Sie keine unabhängigen Produkte in einer einzigen Lizenz-Compliance-Seite zusammen, es sei denn, Ihr Offenlegungsmodell grenzt Abschnitte ausdrücklich ab. Die Beschaffung erwartet Klarheit.

Aus CI-Artefakt, Release-Tag oder SBOM-Tool-Export importieren.
Komponentenname, Version und PURL oder gleichwertige Kennung beibehalten.
SBOM-Lizenzfeld als Ausgangspunkt vermerken, nicht als endgültige Antwort.
Komponenten mit fehlenden, widersprüchlichen oder NOASSERTION-Lizenzdaten markieren.
Bei jedem Release erneut importieren. Nicht dauerhaft veraltetes JSON manuell flicken.

Schritt 2: Anreichern und prüfen

SBOMs enthalten oft SPDX-Lizenzkennungen ohne vollständigen Lizenztext. Drittanbieter-Lizenz-Offenlegung verlangt Text, den die Beschaffung lesen kann. Reichern Sie jede freigegebene Komponente mit vollständigem Lizenzinhalt, Namensnennungstexten und Copyleft-Markierungen aus Ihrer Prüfrichtlinie an.

Klären Sie Lizenzkonflikte zwischen Registry und Repository. Eskalieren Sie individuelle und Copyleft-Lizenzen. Compliance scheitert, wenn SBOM-Metadaten ohne menschliche Verifizierung auf eine öffentliche Seite kopiert werden.

Vollständigen Lizenztext für jede freigegebene Komponente beifügen.
Lizenz gegen die LICENSE-Datei im Repository, ein Anbieter-PDF oder rechtliche Vorgaben bestätigen.
Copyleft- und Verbreitungsprüfregeln anwenden, bevor freigegeben wird.
Hinweis- und Namensnennungsblöcke hinzufügen, wo erforderlich.
Ausschlüsse dokumentieren: nicht ausgelieferte Dev-Abhängigkeiten, reine Testpakete usw.
Veröffentlichung sperren, bis keine ungeprüften relevanten Zeilen mehr vorhanden sind.

Schritt 3: Lizenz-Compliance-Seite und Exporte veröffentlichen

Veröffentlichen Sie aus demselben freigegebenen Bestand gepflegte Offenlegung und Release-Exporte. Teilen Sie das Format, das Due-Diligence-Prüfungen verlangen, ob URL, PDF oder Paket. Exporte lassen sich an Tickets, Release Notes oder Anbieterportale anhängen.

Wenn sich das SBOM beim nächsten Release ändert (neue Pakete, Versions-Updates, Lizenzänderungen), erneut importieren, erneut prüfen, erneut veröffentlichen. Drift-Prüfungen automatisieren den Abgleich, damit Sie bei einem Kunden-Audit nicht überrascht werden.

Teilbaren Nachweis pro Produkt veröffentlichen (gehostete Seite und/oder Exporte).
Prüfen, dass die Offenlegung lädt, der vollständige Text angezeigt wird, der Produktumfang klar ist.
JSON, Namensnennungsdateien und Offenlegungspakete aus demselben Snapshot exportieren.
CI so einrichten, dass sie markiert, wenn das SBOM von Ihrer letzten freigegebenen Veröffentlichung abweicht.
Teilen Sie geprüfte Offenlegung mit der Beschaffung, nicht das rohe SBOM, wenn sie nach Lizenz-Compliance-Dokumentation fragt.

Tools, die Sie bereits nutzen

FOSSA, Snyk, Mend, Syft, der GitHub-Abhängigkeitsgraph und interne CI-Pipelines erzeugen SBOMs und Lizenzhinweise. SourceTrust und ähnliche Offenlegungs-Workflows setzen nachgelagert an: geprüfter Veröffentlichungs-Nachweis, Compliance-Seiten-URL, Exporte im Einklang mit dem, was ausgeliefert wird.

Sie ersetzen Ihr SBOM-Tool nicht. Sie verwandeln dessen Ausgabe in Drittanbieter-Lizenz-Offenlegung, die Ihre Kunden und Auditoren nutzen können. Lizenz-Compliance als gepflegtes Produktartefakt, nicht als einmalige Dateiablage.