Open-Source-Lizenzen in SBOMs
29.06.2023
Interlynk
Open-Source-Lizenzen spielen eine entscheidende Rolle bei der Ermöglichung von Zusammenarbeit, Innovation und Transparenz in der Welt der Softwareentwicklung. Da die Lieferketten für Software von Tag zu Tag komplexer werden, ist es zunehmend wichtig, damit zu beginnen, die Sichtbarkeit der Komponenten und Lizenzen der verwendeten Software aufzubauen. Hier kommt das Software Bill of Materials (SBOM) ins Spiel. SBOMs ermöglichen es Organisationen, Schwachstellen zu identifizieren, die Nutzung von Open Source zu verfolgen und die Einhaltung zahlreicher Lizenzverpflichtungen sicherzustellen.
Open Source-Lizenzen
Open-Source-Lizenzen definieren die Bedingungen, unter denen Software verwendet, modifiziert und verteilt werden kann. Bei der Berücksichtigung 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. Unterschiedliche Lizenzen haben unterschiedliche Anforderungen und Einschränkungen. Erlaubende Lizenzen wie MIT und BSD bieten mehr Flexibilität, während Copyleft-Lizenzen wie GPL strengere Verpflichtungen auferlegen, wie z. B. das Teilen von Modifikationen unter derselben Lizenz.
SBOM und Open Source-Lizenzen
Das Einbeziehen von Open Source-Lizenzen in SBOM hilft Organisationen, die mit ihren Softwarekomponenten verbundenen Lizenzen genau zu verfolgen. Dies schafft einen offeneren, verwaltbaren und skalierbaren Weg zur Verwaltung von Lizenzrisiken und -verpflichtungen.
Sicherstellung der Einhaltung von Open Source-Lizenzen: Durch das Einbeziehen von Lizenzen in SBOM können Organisationen leicht ein Inventar der Lizenzen der in ihren Softwareprojekten verwendeten Komponenten führen. Dies hilft, die Einhaltung der Lizenzbedingungen sicherzustellen und rechtliche Folgen oder Verzögerungen im Verkauf und bei M&A zu vermeiden.
Rechtliche Risiken mindern: Die Nichteinhaltung von Open Source-Lizenzen kann zu rechtlichen Auseinandersetzungen und einem potenziellen Verlust von Rechten an geistigem Eigentum führen. Das Einbeziehen von Lizenzen in SBOM ermöglicht es Organisationen, proaktiv Lizenzprobleme anzugehen und rechtliche Risiken im Zusammenhang mit der Nutzung von Open Source zu mindern.
Förderung von Transparenz und Vertrauen: Open Source-Lizenzen in SBOM fördern Transparenz und Vertrauen innerhalb von Software-Lieferketten. Durch die offene Erklärung der Lizenzen zeigen Organisationen ihr Engagement für die Einhaltung ihrer 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 umsetzbare Lizenzdetails in einem 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. Stand Version 3.20 umfasst 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 zu bilden, indem man diese Regeln befolgt:
SPDX: Lizenz-Ausdrücke
Der license-expression bildet das Rückgrat der Lizenzdeklarationen, wie zum Beispiel Deklarationen von Lizenzen für Pakete durch die Autoren des Pakets. (z.B.
PackageLicenseDeclared: (LGPL-2.0-only AND LicenseRef-3)
und regelt Lizenzen, wie sie von den Autoren (z.B.
PackageLicenseConcluded: (LGPL-2.0-only OR LicenseRef-3)
neben der Bereitstellung von Kommentar oder Analysen als Hintergrundinformationen. (z.B.
PackageLicenseComments: <text>Die Lizenz für dieses Projekt hat sich mit der Veröffentlichung von Version 1.4 geändert. Die hier enthaltene Version des Projekts liegt nach der Lizenzänderung.</text>
CycloneDX:
Die CycloneDX SBOM-Spezifikation verwendet ebenfalls die SPDX-Lizenzliste und die SPDX license-expression und bietet auch Felder zur Befüllung von Links zu Lizenztexten. (z.B.
CycloneDX: Lizenzmetadaten
Bekannte Herausforderungen beim Verständnis von Lizenzen aus SBOM:
Während die Spezifikationen die Lizenzdeklaration auf methodische Weise beschrieben haben, fehlte es der Implementierung in SBOM-Generatoren an demselben Maß an Sorgfalt. Dies hat zu einigen Herausforderungen geführt:
Fehlende Lizenzen: Das Fehlen von Lizenzfeldern im SBOM ist die häufigste Herausforderung. Es ist zwar korrekt, dass CycloneDX und SPDX Lizenzfelder optional gehalten haben (für breitere Anwendungsfälle), NTIA-Minimalelemente für ein SBOM haben die Aufnahme von Lizenzen empfohlen, um diese nützlich zu machen.
Ungültiger Standard: SPDX hat zwei Standardwerte bereitgestellt:
NONEfür den Fall, dass keine Lizenz gilt, undNOASSERTIONfür den Fall, dass die Lizenzermittlung nicht versucht wurde, oder die Lizenz absichtlich nicht im Dokument enthalten ist. Allerdings können eine Reihe von ungültigen Standardwerten –EMPTY,NULL,NOLICENSE,UNKNOWNin SBOM gefunden werden, die von verschiedenen Werkzeugen generiert wurden. Dies stellt eine Herausforderung für die SBOM-Konsumwerkzeuge dar.Ungültige Lizenz-Referenzen: Ein einfaches SPDX
license-expressionkann eine benutzerdefinierte Lizenzreferenz enthalten. Um dies für das SBOM-Konsumwerkzeug nützlich zu machen, erfordert diese Indirektion: (a) eine gültige Lizenzreferenz-ID und (b) eine genaue Beschreibung der Lizenzreferenz selbst. Bei Interlynk sehen wir verschiedene Fehler in solchen Lizenzäußerungen, einschließlich (a) Ungültige Zeichen in Lizenzreferenzen, (b) hängende Lizenzreferenzen, (c) nicht-terminierende Lizenzreferenzen, (d) Lizenzreferenzen für externe Dokumente ohne Bereitstellung der externen Dokumente selbst.Ungültige Lizenzäußerungen: Die Aufnahme von Lizenzen in das oben genannte ABNF ist der einzige sichere Weg, um sicherzustellen, dass automatisierte Prozesse SBOM genau analysieren und die Lizenzinformationen extrahieren können. Wir haben jedoch sehr wenig Beachtung dafür bemerkt, sich an das ABNF zu halten und stattdessen auf verschiedene Kurzformen zu setzen, die Lizenzen für Menschen leicht lesbar machen (und somit eine Annahme der Genauigkeit bieten), während sie Fehler für die Konsumwerkzeuge verursachen. Beispiele für ungültige Lizenzäußerungen sind:
PackageDeclaredLicense: MIT, LGPLv2, BSDPackageConcludedLicense: [MIT, LGPLv2, BSD]PackageConcludedLicense: [MIT, LGPLv2, BSD]LicenseID: MIT/LGPLv2
Um diese Herausforderungen zu überwinden, ist es entscheidend, SBOM mit Qualitätswerkzeugen (z. B. sbomqs) oder Datenextraktionswerkzeugen (z. B. sbomgr) vorzubehandeln, um die Genauigkeit und Vollständigkeit des zugrunde liegenden SBOM und die Reife des SBOM-Generators zu verstehen.
Best Practices für das Management von Open-Source-Lizenzen in SBOM:
Eine klare Richtlinie festlegen für das Management von Open Source-Lizenzen innerhalb Ihrer Organisation. Dazu gehört die Definition akzeptabler Lizenzen, die Durchführung regelmäßiger Lizenzüberprüfungen und die Schulung der Entwickler über Lizenzpflichten.
Regelmäßige Lizenzprüfungen und -scans durchführen: Überprüfen Sie regelmäßig Ihre Softwareprojekte, um die Einhaltung der Open Source-Lizenzen sicherzustellen. Nutzen Sie Scan-Tools, die automatisch die Lizenzen identifizieren und berichten können, die mit Ihren Softwarekomponenten verbunden sind.
Tools und Automatisierung nutzen: Setzen Sie Software-Kompositionsanalysatoren (SCA) ein, die automatisch SBOMs erstellen und Einblicke in die Einhaltung von Lizenzen bieten können. Diese Tools können helfen, den Prozess zu optimieren und die Genauigkeit bei der Verwaltung von Open Source-Lizenzen sicherzustellen.
Rechtliche Fachkompetenz einbeziehen: In komplexen Lizenzszenarien sollten Sie rechtliche Fachkompetenz einbeziehen, um mögliche rechtliche Herausforderungen zu meistern. Juristische Fachleute können Anleitung zur Lizenzkompatibilität und zu Verpflichtungen bieten und helfen, Lizenzprobleme zu lösen, die auftreten können.
Da sich die Praktiken von Open Source und SBOM weiterentwickeln, ist es wichtig, über zukünftige Trends und Entwicklungen informiert zu bleiben. Es laufen Bemühungen, SBOM-Formate zu standardisieren, um den einfacheren Austausch und die Interoperabilität über verschiedene Software-Ökosysteme hinweg zu ermöglichen. Auch regulatorische Anforderungen in Bezug auf die Transparenz der Softwarelieferkette entstehen, was die Notwendigkeit umfassender SBOMs und das Management von Open Source-Lizenzen unterstreicht.
Open Source-Lizenzen im Software-Bill of Materials (SBOM) gewährleisten die Einhaltung, mindern rechtliche Risiken und fördern die Transparenz in Softwarelieferketten. Durch die Einbeziehung von Open Source-Lizenzen in SBOM können Organisationen ihre Softwarekomponenten effektiv verwalten, Lizenzpflichten erfüllen und Vertrauen bei den Stakeholdern aufbauen. Bleiben Sie wachsam, übernehmen Sie bewährte Praktiken und nehmen Sie die sich entwickelnde Landschaft der Open Source-Lizenzierung an, um die Komplexität der Softwareentwicklung erfolgreich zu meistern.