Open-Source-Lizenzen spielen eine entscheidende Rolle bei der Ermöglichung von Zusammenarbeit, Innovation und Transparenz in der Welt der Softwareentwicklung. Da Software-Lieferketten von Tag zu Tag komplexer werden, wird es immer wichtiger, Transparenz bezüglich der Komponenten und Lizenzen der verwendeten Software zu schaffen. Hier kommt die Software-Stückliste (Software Bill of Materials – SBOM) ins Spiel. SBOMs ermöglichen es Unternehmen, Schwachstellen zu identifizieren, die Nutzung von Open-Source-Software zu verfolgen und die Einhaltung zahlreicher Lizenzverpflichtungen zu gewährleisten.
Open-Source-Lizenzen
Open-Source-Lizenzen definieren die Bedingungen, unter denen Software verwendet, geändert und verbreitet werden darf. Bei der Erwägung von Open-Source-Komponenten für Software muss das Verständnis und die Inventarisierung der mit diesen Komponenten verbundenen Lizenzen eine Schlüsselrolle bei den Auswahlkriterien spielen. Verschiedene Lizenzen haben unterschiedliche Anforderungen und Einschränkungen. Freizügige Lizenzen wie MIT und BSD ermöglichen mehr Flexibilität, während Copyleft-Lizenzen wie GPL strengere Verpflichtungen auferlegen, wie z. B. die Freigabe von Änderungen unter derselben Lizenz.
SBOM und Open-Source-Lizenzen
Die Aufnahme von Open-Source-Lizenzen in eine Software-Stückliste (SBOM) hilft Unternehmen, die mit ihren Softwarekomponenten verbundenen Lizenzen genau zu verfolgen. Dies schafft einen offeneren, übersichtlicheren und skalierbareren Weg zur Bewältigung von Lizenzrisiken und -pflichten.
Gewährleistung der Einhaltung von Open-Source-Lizenzen: Durch die Aufnahme von Lizenzen in die SBOM können Unternehmen auf einfache Weise eine Bestandsaufnahme der Lizenzen für die in ihren Softwareprojekten verwendeten Komponenten durchführen. Dies trägt dazu bei, die Einhaltung der Geschäftsbedingungen der Lizenzen sicherzustellen, wodurch rechtliche Konsequenzen oder Verzögerungen bei Verkäufen sowie Fusionen und Übernahmen (M&A) vermieden werden.
Minimierung rechtlicher Risiken: Die Nichteinhaltung von Open-Source-Lizenzen kann zu Rechtsstreitigkeiten und dem potenziellen Verlust von geistigen Eigentumsrechten führen. Die Aufnahme von Lizenzen in die SBOM ermöglicht es Unternehmen, Lizenzierungsprobleme proaktiv anzugehen und rechtliche Risiken im Zusammenhang mit der Nutzung von Open Source zu minimieren.
Förderung von Transparenz und Vertrauen: Open-Source-Lizenzen in einer SBOM fördern Transparenz und Vertrauen innerhalb der Software-Lieferketten. Durch die offene Offenlegung der Lizenzen demonstrieren Unternehmen ihr Engagement für die Einhaltung von Lizenzverpflichtungen und bauen Vertrauen bei Nutzern, Kunden und der breiteren Open-Source-Gemeinschaft auf.
Lizenzplatzierung in SBOMs
CycloneDX und SPDX — zwei der drei am häufigsten verwendeten und von der NTIA empfohlenen SBOM-Spezifikationen — bieten präzise und einfach zu implementierende Lizenzdetails in einer SBOM.
SPDX:
Die SPDX-Lizenzliste ist eine Liste der am häufigsten verwendeten Lizenzen in Open-Source-Software und -Komponenten, Erweiterungen dieser Lizenzen und Ausnahmen davon. Seit der Version 3.20 enthält die Liste 506 Lizenzen und Derivate. Die SPDX-Lizenzliste ist ein entscheidender Bestandteil der SPDX-SBOM-Spezifikation. Die Liste kann verwendet werden, um größere license-expression-Ausdrücke zu bilden, indem die folgenden Regeln befolgt werden:
SPDX: Lizenzausdrücke
Der license-expression-Ausdruck bildet das Rückgrat der Lizenzdeklaration, wie z. B. bei der Deklaration von Lizenzen für Pakete durch die Autoren des Pakets (z. B.
PackageLicenseDeclared: (LGPL-2.0-only AND LicenseRef-3)
und der Festlegung von Lizenzen, wie sie von den Autoren beschlossen wurden (z. B.
PackageLicenseConcluded: (LGPL-2.0-only OR LicenseRef-3)
zusätzlich zur Bereitstellung von Kommentaren oder Analysen als Hintergrundinformationen (z. B.
PackageLicenseComments: <text>The license for this project changed withthe release of version 1.4. The version of the project included herepost-dates the license change.</text>
CycloneDX:
Die CycloneDX-SBOM-Spezifikation verwendet ebenfalls die SPDX-Lizenzliste und SPDX-license-expression-Ausdrücke und bietet zudem Felder zum Einfügen von Links zum Lizenztext (z. B.
CycloneDX: Lizenz-Metadaten
Bekannte Herausforderungen beim Verstehen von Lizenzen aus SBOMs:
Während Spezifikationen die Lizenzdeklaration auf methodische Weise beschrieben haben, mangelte es bei der Implementierung in SBOM-Generatoren an derselben Strenge. Dies hat zu einigen Herausforderungen geführt:
Fehlende Lizenzen: Das Fehlen von Lizenzfeldern in der SBOM ist die häufigste Herausforderung. Obwohl es zutrifft, dass CycloneDX und SPDX Lizenzfelder (für breitere Anwendungsfälle) optional gehalten haben, empfiehlt NTIA Minimum Elements for a SBOM die Aufnahme von Lizenzen, um sie nützlich zu machen.
Ungültiger Standardwert: SDPX stellt zwei Standardwerte bereit:
NONE, wenn keine Lizenz gilt, undNOASSERTION, wenn keine Lizenzermittlung versucht wurde oder die Lizenz absichtlich nicht im Dokument enthalten ist. Eine Reihe von ungültigen Standardwerten —EMPTY,NULL,NOLICENSE,UNKNOWN— ist jedoch in SBOMs zu finden, die von verschiedenen Tools generiert wurden. Dies stellt die Tools zur SBOM-Nutzung vor Herausforderungen.Ungültige Lizenz-Referenzen: Ein einfacher SPDX-
license-expressionkann eine benutzerdefinierte Lizenzreferenz enthalten. Um dies für das SBOM-Nutzungstool brauchbar zu machen, erfordert diese Indirektion jedoch: (a) eine gültige Lizenzreferenz-ID und (b) eine genaue Beschreibung der Lizenzreferenz selbst. Bei Interlynk sehen wir verschiedene Fehler in solchen Lizenzausdrücken, darunter (a) ungültige Zeichen in Lizenzreferenzen, (b) verwaiste Lizenzreferenzen, (c) nicht endende Lizenzreferenzen, (d) Lizenzreferenzen für externe Dokumente, ohne die externen Dokumente selbst bereitzustellen.Ungültige Lizenzausdrücke: Die Aufnahme von Lizenzen in das oben genannte ABNF ist der einzige sichere Weg, um zu gewährleisten, dass automatisierte Prozesse die SBOM präzise parsen und die Lizenzierungsinformationen extrahieren können. Wir haben jedoch eine sehr geringe Einhaltung des ABNFs festgestellt; stattdessen wird auf verschiedene Kurzschreibweisen zurückgegriffen, die Lizenzen für Menschen leicht lesbar machen (und somit die Vermutung von Richtigkeit erwecken), während sie bei Nutzungstools Fehler verursachen. Beispiele für ungültige Lizenzausdrücke sind:
PackageDeclaredLicense: MIT, LGPLv2, BSDPackageConcludedLicense: [MIT, LGPLv2, BSD]PackageConcludedLicense: [MIT, LGPLv2, BSD]LicenseID: MIT/LGPLv2
Um diese Herausforderungen zu bewältigen, ist es von entscheidender Bedeutung, die SBOM mit Qualitäts- (z. B. sbomqs) oder Datenextraktions-Tools (z. B. sbomgr) vorzuverarbeiten, um die Genauigkeit und Vollständigkeit der zugrunde liegenden SBOM sowie den Reifegrad des SBOM-Generators zu verstehen.
Best Practices für die Verwaltung von Open-Source-Lizenzen in SBOMs SBOM:
Etablieren Sie eine klare Richtlinie für die Verwaltung von Open-Source-Lizenzen in Ihrer Organisation. Dies umfasst die Definition akzeptabler Lizenzen, die Durchführung regelmäßiger Lizenzprüfungen und die Aufklärung der Entwickler über Lizenzverpflichtungen.
Führen Sie regelmäßige Lizenz-Audits und -Scans durch: Überprüfen Sie Ihre Softwareprojekte regelmäßig, um die Einhaltung von Open-Source-Lizenzen sicherzustellen. Nutzen Sie Scan-Tools, die automatisch die mit Ihren Softwarekomponenten verknüpften Lizenzen identifizieren und melden können.
Nutzen Sie Tools und Automatisierung: Setzen Sie Software Composition Analysis (SCA)-Tools ein, die automatisch SBOMs generieren und Einblicke in die Lizenzkonformität bieten können. Diese Tools können helfen, den Prozess zu rationalisieren und Genauigkeit bei der Verwaltung von Open-Source-Lizenzen zu gewährleisten.
Ziehen Sie rechtliche Expertise hinzu: Ziehen Sie in komplexen Lizenzierungsszenarien die Einbindung von Rechtsexperten in Betracht, um potenzielle rechtliche Herausforderungen zu bewältigen. Rechtsexperten können Ratschläge zur Lizenzkompatibilität und -verpflichtungen geben und bei der Lösung auftretender Lizenzierungsprobleme helfen.
Da sich Open-Source- und SBOM-Praktiken ständig weiterentwickeln, ist es wichtig, über zukünftige Trends und Entwicklungen informiert zu bleiben. Es gibt Bemühungen zur Standardisierung von SBOM-Formaten, um einen einfacheren Austausch und Interoperabilität zwischen verschiedenen Software-Ökosystemen zu ermöglichen. Es zeichnen sich auch regulatorische Anforderungen in Bezug auf die Transparenz der Software-Lieferkette ab, was die Notwendigkeit einer umfassenden SBOM- und Open-Source-Lizenzverwaltung unterstreicht.
Open-Source-Lizenzen in der Software-Stückliste (Software Bill of Materials, SBOM) sichern die Einhaltung von Vorschriften, mindern rechtliche Risiken und fördern die Transparenz in Software-Lieferketten. Durch die Aufnahme von Open-Source-Lizenzen in die SBOM können Organisationen ihre Softwarekomponenten effektiv verwalten, Lizenzverpflichtungen erfüllen und Vertrauen bei Interessengruppen aufbauen. Bleiben Sie wachsam, übernehmen Sie Best Practices und nutzen Sie die sich entwickelnde Landschaft der Open-Source-Lizenzierung, um die Komplexität der Softwareentwicklung erfolgreich zu meistern.