Reicht ein SBOM für die Lizenzprüfung?

Ein SBOM ist ein maschinenlesbarer Komponentenbestand für Sicherheits- und Lieferkettenwerkzeuge, keine Lizenzoffenlegung. Die NTIA-Mindestelemente definieren Lieferant, Komponentenname, Version, eindeutige Kennungen, Abhängigkeitsbeziehungen und Autor. Das sind Identitätsdaten für den Schwachstellenabgleich, keine geprüften Lizenztexte.

Sicherheitswerkzeuge gleichen CVEs mit Komponentenidentitäten ab. Die CRA-Dokumentation nach Anhang I erwartet Komponentenlisten in gängigen Formaten. Teams für die Reaktion auf Sicherheitsvorfälle verfolgen den Wirkungsradius über Abhängigkeitsgraphen.

SBOM-Lizenzfelder sind Ausgangspunkte, keine Freigaben. SPDX-Kennungen in CycloneDX stammen oft aus npm-Registry-Metadaten, die häufig falsch, unvollständig oder mit NOASSERTION markiert sind. AppSec-Teams fügen einem SBOM-Export selten den vollständigen GPL- oder proprietären SDK-Lizenztext bei.

• Komponentenidentität (Name, Version, PURL, Hash) für den Schwachstellenabgleich.
• Lieferanten- und Autoren-Metadaten für Lieferketten-Rückverfolgbarkeit.
• Maschinenlesbares Format (CycloneDX, SPDX) für Tools und regulatorische Dokumentation.
• Input für CRA-Komponentendokumentation und Produktsicherheitsprogramme.
• Drift-Erkennung, wenn die CI bei jedem Build ein neues SBOM erzeugt.
• Nicht: menschenlesbare Drittanbieter-Lizenz-Offenlegung für die rechtliche Prüfung.
• Nicht: vollständiger Lizenztext, Hinweis oder Namensnennungsblöcke pro Komponente.
• Nicht: Freigabekontrollen, die bestätigen, dass ein Mensch jede Pflicht geprüft hat.

Die Offenlegung von Drittanbieterlizenzen enthält geprüfte, gut lesbare Lizenztexte, Namensnennungen und Lizenzhinweise für eine bestimmte ausgelieferte Version. Ein SBOM leistet das nicht. Für Sicherheitswerkzeuge beantwortet ein SBOM die Frage: „Welche Komponenten sind enthalten?“ Die Offenlegung beantwortet für Beschaffung und Rechtsabteilung die Frage: „Was müssen wir bei der Auslieferung rechtlich wiedergeben?“

Die Offenlegung von Drittanbieterlizenzen beantwortet Fragen von Beschaffung und Rechtsabteilung: Welche Open-Source- und Drittanbietersoftware enthält dieses Produkt? Unter welchen Lizenzen steht sie? Welche Lizenzhinweise und Namensnennungen gehören dazu? Auf welche geprüfte Version bezieht sich der Stand?

In Entwicklungsteams mit mehreren Personen ändern sich Abhängigkeiten ständig. Eine Person spielt eine Korrektur ein, eine andere fügt ein SDK hinzu, und transitive Pakete ändern sich. Ein Offenlegungsnachweis funktioniert nur, wenn er bei jeder Änderung an der Codebasis erneut importiert, geprüft und veröffentlicht wird, unabhängig davon, ob Sie ihn unter einer URL bereitstellen oder als Export an einen Fragebogen anhängen.

• Geprüfter Bestand pro ausgeliefertem Produkt, nicht rohe Registry-Metadaten.
• Vollständiger Lizenztext für jede relevante Komponente, nicht nur die SPDX-ID.
• Namensnennung und Urheberrechtshinweis, wenn MIT, Apache, BSD oder GPL sie verlangen.
• Copyleft- und individuelle Lizenzzeilen bis zur ausdrücklichen Prüfung gesperrt.
• Klarer Produktumfang: für welche SKU oder Version der Nachweis gilt.
• Veröffentlichungsfreigabe: jemand Verantwortliches vor der externen Weitergabe.
• Pflegeprozess: Aktualisierung, wenn sich Lockfiles oder SBOMs ändern.

Halten Sie diese Tabelle griffbereit, wenn ein Fragebogen sowohl nach einer „SBOM“ als auch nach „Open-Source-Lizenzkonformität“ fragt. Beide überschneiden sich beim Bestand, aber nicht beim Ergebnis.

Nein. Sie können für jede Version einwandfreie CycloneDX-Dateien erzeugen und trotzdem eine Beschaffungsprüfung zur Lizenzkonformität nicht bestehen. Ein SBOM listet Komponenten auf, gibt aber nicht die Lizenztexte, Lizenzhinweise und Namensnennungen wieder, die bei der Verbreitung erforderlich sind.

Der Käufer öffnet Ihren Anhang, sieht Komponentennamen und „MIT“-Einträge und fragt, wo der Lizenztext ist.

Der CRA fördert die Dokumentation von Komponenten und beschleunigt so die Einführung von SBOMs. Er ersetzt nicht die seit Jahrzehnten bestehende Erwartung von Käufern, dass Anbieter die Offenlegung von Drittanbieterlizenzen pflegen. EU-Produktsicherheitsdokumentation und Lizenzabschnitte in Ausschreibungen von Großkunden bleiben getrennte Aufgaben.

Sicherheitsteams verantworten die Bewertung von Schwachstellen, Sicherheitskorrekturen und Vorfallsmeldungen. Lizenzpflichten (Lizenzhinweise, Namensnennungen und Copyleft-Bedingungen) brauchen eine verantwortliche Person, die sie vor der externen Weitergabe prüft. Das ist selten dieselbe Person, die Dependabot-PRs einspielt.

Das effiziente Modell importiert dasselbe SBOM oder dasselbe Lockfile in beide Arbeitsabläufe. Das Sicherheitsteam nutzt das SBOM für CVEs und die CRA-Dokumentation. Compliance importiert dieselbe Datei in eine Prüfliste: Jede Komponente muss geprüft, mit vollständigem Text versehen, freigegeben und anschließend in einem Offenlegungsnachweis veröffentlicht werden.

Ändert sich das SBOM bei der nächsten Version, reagieren beide Teams. Das Sicherheitsteam prüft erneut auf Schwachstellen. Compliance prüft neue oder geänderte Lizenzeinträge. Eine Bestandsquelle liefert zwei Ergebnisse. Keines ersetzt das andere.

• Importieren Sie CycloneDX, SPDX oder Lockfiles einmal für jede zur Freigabe vorgesehene Version.
• Sicherheit: Prüfung auf Schwachstellen, CRA-Dokumentation, Rückverfolgbarkeit von Vorfällen.
• Compliance: Lizenzen abgleichen, vollständige Texte anfügen, Copyleft-Fälle eskalieren und das Publish-Gate durchlaufen.
• Den Offenlegungsnachweis aus einem freigegebenen Stand veröffentlichen (als Seite oder Export, je nach Käuferanforderung).
• Drift-Prüfung: SBOM-Änderungen markieren, für die eine erneute Lizenzfreigabe fehlt.

SBOM-JSON in ein Anbieterportal hochladen und dies Lizenzkonformität nennen. SPDX-IDs ohne Text in eine Tabelle einfügen. Annehmen, ein Lizenzscan von FOSSA oder Snyk entspreche einer geprüften Offenlegung, obwohl Freigabekontrollen fehlen.

Ein PDF einmal mit einem SBOM-Werkzeug erzeugen und über mehrere Versionen hinweg wiederverwenden, während das Entwicklungsteam weiter Änderungen an Abhängigkeiten einarbeitet. Es veraltet wie jeder statische Export, unabhängig vom Format.