Ist ein SBOM dasselbe wie eine Lizenz-Compliance-Seite?

Ein SBOM ist ein maschinenlesbarer Komponentenbestand für Security- und Lieferketten-Tools, keine Lizenz-Offenlegung. Die NTIA-Mindestelemente definieren es als Lieferant, Komponentenname, Version, eindeutige Kennungen, Abhängigkeitsbeziehungen und Autor. Das sind Identitätsdaten für den Schwachstellenabgleich, kein geprüfter Lizenztext.

Security-Tools gleichen CVEs mit Komponentenidentitäten ab. Die CRA-Dokumentation nach Anhang I erwartet Komponentenlisten in gängigen Formaten. Incident-Response-Teams 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: Publish-Gates, die bestätigen, dass ein Mensch jede Pflicht geprüft hat.

Lizenz-Offenlegung liefert geprüften, menschenlesbaren Lizenztext, Namensnennung und Hinweise, gebunden an ein bestimmtes ausgeliefertes Release. Das leistet ein SBOM nicht. Ein SBOM beantwortet für Security-Tools die Frage „welche Komponenten sind hier“; Offenlegung beantwortet für Beschaffung und Recht die Frage „wozu sind wir rechtlich verpflichtet, wenn wir das ausliefern“.

Drittanbieter-Lizenz-Offenlegung beantwortet Fragen von Beschaffung und Recht: Welche Open-Source- und Drittanbieter-Software steckt in diesem Produkt, unter welchen Lizenzen, mit welchem Hinweis und welcher Namensnennung, Stand welchem geprüften Release.

In mehrköpfigen Engineering-Teams ändern sich Abhängigkeiten ständig. Ein Engineer merged einen Patch, ein anderer fügt ein SDK hinzu, transitive Pakete verschieben sich. Ein Offenlegungs-Nachweis funktioniert nur, wenn er bei jeder Codebasis-Änderung erneut importiert, erneut geprüft und erneut veröffentlicht wird, egal ob Sie ihn unter einer URL hosten 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 Copyright-Hinweis, wo MIT, Apache, BSD oder GPL sie verlangen.
• Copyleft- und individuelle Lizenzzeilen bis zur ausdrücklichen Prüfung gesperrt.
• Klarer Produktumfang: welche SKU oder welches Release der Nachweis abdeckt.
• 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 „SBOM“ als auch nach „Open-Source-Lizenz-Compliance“ fragt. Sie überschneiden sich beim Bestand, aber nicht beim Ergebnis.

Nein. Sie können bei jedem Release perfekte CycloneDX-Dateien erzeugen und trotzdem an einer Beschaffungsprüfung scheitern, die Lizenz-Compliance verlangt, weil ein SBOM zwar Komponenten auflistet, aber nicht den Lizenztext, die Hinweise und die Namensnennung liefert, die Verbreitungspflichten verlangen.

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

Der CRA drängt Organisationen dazu, Komponenten zu dokumentieren, was die SBOM-Einführung beschleunigt. Er ersetzt nicht jahrzehntealte Käufererwartungen, dass Anbieter Drittanbieter-Lizenz-Offenlegung pflegen. EU-Produktsicherheitsdokumentation und Lizenzabschnitte in Enterprise-Ausschreibungen sind parallele Spuren.

Security-Teams verantworten Schweregrad von Schwachstellen, Patching, Vorfallsmeldung. Lizenzpflichten (Hinweis, Namensnennung, Copyleft-Bedingungen) brauchen einen Verantwortlichen, der vor der externen Weitergabe prüft. Dieser Verantwortliche ist selten dieselbe Person, die Dependabot-PRs merged.

Das effiziente Modell importiert dasselbe SBOM oder Lockfile in beide Pipelines. Security nutzt das SBOM für CVEs und CRA-Dokumentation. Compliance importiert dieselbe Datei in eine Prüfliste: Jede Komponente braucht Prüfung, vollständigen Text, Freigabe und dann Veröffentlichung in einen Offenlegungs-Nachweis.

Ändert sich das SBOM beim nächsten Release, reagieren beide Teams. Security scannt erneut auf Schwachstellen. Compliance prüft neue oder geänderte Lizenzzeilen erneut. Eine Bestandsquelle, zwei Ergebnisse. Keines der beiden Ergebnisse ersetzt das andere.

• CycloneDX, SPDX oder Lockfiles einmal pro Release-Kandidat importieren.
• Security: Schwachstellen-Scan, CRA-Dokumentation, Vorfall-Rückverfolgbarkeit.
• Compliance: Lizenzabgleich, vollständigen Text anfügen, Copyleft-Eskalation, Publish-Gate.
• Offenlegungs-Nachweis aus freigegebenem Snapshot veröffentlichen (Seite oder Export, je nach Käuferanforderung).
• Drift-Prüfung: SBOM-Änderungen markieren, denen die erneute Compliance-Freigabe fehlt.

SBOM-JSON in ein Anbieterportal hochladen und das Lizenz-Compliance nennen. SPDX-IDs ohne Text in eine Tabelle einfügen. Annehmen, ein FOSSA- oder Snyk-Lizenzscan entspreche geprüfter Offenlegung, ganz ohne Publish-Gates.

Einmal ein PDF aus SBOM-Tools erzeugen und über mehrere Releases hinweg wiederverwenden, während Engineers weiter Abhängigkeiten mergen. Dasselbe Problem veralteter Snapshots wie bei jedem statischen Export, unabhängig vom Format.