Open Source Licenties in SBOMs
Interlynk
Open Source-licenties spelen een cruciale rol bij het mogelijk maken van samenwerking, innovatie en transparantie in de wereld van softwareontwikkeling. Nu de softwareleveringsketens dagelijks complexer worden, wordt het steeds essentiëler om zicht te krijgen op de componenten en licenties van de gebruikte software. Dit is waar de Software Bill of Materials (SBOM) om de hoek komt kijken. SBOM's stellen organisaties in staat om kwetsbaarheden te identificeren, het gebruik van open-source te volgen en te zorgen voor naleving van talrijke licentieverplichtingen.
Open Source Licenties
Open Source-licenties definiëren de voorwaarden waaronder software kan worden gebruikt, gewijzigd en verspreid. Bij het overwegen van Open Source-componenten voor software, moet het begrijpen en inventariseren van de licenties die aan die componenten zijn verbonden een belangrijke rol spelen in de selectiecriteria. Verschillende licenties hebben verschillende vereisten en beperkingen. Permissieve licenties zoals MIT en BSD bieden meer flexibiliteit, terwijl copyleft-licenties zoals GPL strengere verplichtingen opleggen, zoals het delen van wijzigingen onder dezelfde licentie.
SBOM en open source-licenties
Het opnemen van Open Source-licenties in SBOM helpt organisaties om nauwkeurig de licenties bij te houden die verband houden met hun softwarecomponenten. Dit creëert een meer open, beheersbare en schaalbare weg voor het beheren van licentierisico's en verplichtingen.
Zorgen voor naleving van Open Source-licenties: Door licenties op te nemen in SBOM kunnen organisaties eenvoudig een inventaris bijhouden van de licenties van de componenten die in hun softwareprojecten worden gebruikt. Dit helpt om te zorgen voor naleving van de voorwaarden en bepalingen van de licenties, waardoor wettelijke gevolgen of vertragingen in de verkoop en fusies en overnames worden vermeden.
Mitigeren van juridische risico's: Het niet naleven van Open Source-licenties kan leiden tot juridische geschillen en potentieel verlies van intellectuele eigendomsrechten. Het opnemen van licenties in SBOM stelt organisaties in staat om proactief licentieproblemen aan te pakken en juridische risico's die verband houden met het gebruik van Open Source te mitigeren.
Transparantie en vertrouwen bevorderen: Open Source-licenties in SBOM bevorderen transparantie en vertrouwen binnen software-supply chains. Door de licenties openlijk te verklaren, tonen organisaties hun inzet voor naleving van licentieverplichtingen en bouwen ze vertrouwen op bij gebruikers, klanten en de bredere Open Source-gemeenschap.
Licentieplaatsing in SBOMs
CycloneDX en SPDX — twee van de drie meest gebruikte en door NTIA aanbevolen SBOM-specificaties — bieden nauwkeurige en eenvoudig te implementeren licentiegegevens in een SBOM.
SPDX:
De SPDX-licentielijst is een lijst van de meest gebruikte licenties in open-source software en componenten, extensies van deze licenties, en uitzonderingen daarop. Vanaf versie 3.20 bevat de lijst 506 licenties en derivaten. De SPDX-licentielijst is een cruciaal onderdeel van de SPDX SBOM-specificatie. De lijst kan worden gebruikt om grotere licentie-uitdrukking te vormen door deze regels te volgen:
SPDX: Licentie-uitdrukkingen
De licentie-uitdrukking vormt de ruggengraat voor het verklaren van licenties, zoals verklaren van licenties voor pakketten door de auteurs van het pakket. (bijv.
PackageLicenseDeclared: (LGPL-2.0-only EN LicenseRef-3)
en regerende licenties zoals afgeleid door de auteurs (bijv.
PackageLicenseConcluded: (LGPL-2.0-only OF LicenseRef-3)
naast het verstrekken van eventuele opmerkingen of analyses als achtergrondinformatie. (bijv.
PackageLicenseComments: <text>De licentie voor dit project wijzigde met de release van versie 1.4. De versie van het project die hier is opgenomen, is later dan de wijziging van de licentie.</text>
CycloneDX:
CycloneDX SBOM-specificatie gebruikt ook de SPDX-licentielijst en SPDX licentie-uitdrukking en biedt ook velden om links naar licentietekst te populeren. (bijv.
CycloneDX: Licentie-metadata
Bekende uitdagingen bij het begrijpen van licenties van SBOM:
Hoewel specificaties licentiedeclaraties op een methodische manier hebben beschreven, heeft de implementatie in SBOM-generatoren dezelfde rigor ontbroken. Dit heeft geleid tot enkele uitdagingen:
Afwezigheid van Licenties: De afwezigheid van licentievvelden in de SBOM is de meest voorkomende uitdaging. Hoewel het waar is dat CycloneDX en SPDX licentievelden optioneel hebben gehouden (voor bredere toepassingsgevallen), heeft NTIA Minimum Elementen voor een SBOM de opname van licenties aanbevolen om ze nuttig te maken.
Ongeldig Standaard: SDPX heeft twee standaarden gegeven:
NONEvoor wanneer er geen licentie van toepassing is enNOASSERTIONvoor wanneer licentievindingspogingen niet zijn gedaan, of de licentie opzettelijk niet in het document is opgenomen. Echter, een aantal ongeldige standaarden —EMPTY,NULL,NOLICENSE,UNKNOWNis te vinden in SBOM die door verschillende tools zijn gegenereerd. Dit vormt een uitdaging voor de SBOM-consumptietools.Ongeldige Licentie-Referenties: Een eenvoudige SPDX
license-expressionkan een door de gebruiker gedefinieerde licentiereferentie bevatten. Echter, om dit nuttig te maken voor de SBOM-consumptietool, vereist deze indirectie: (a) een geldige licentiereferentie id en (b) een nauwkeurige beschrijving van de licentiereferentie zelf. Bij Interlynk zien we verschillende fouten in dergelijke licentie-expressies, waaronder (a) Ongeldige tekens in licentiereferenties, (b) zwervende licentiereferenties, (c) niet-terminerende licentiereferenties, (d) Licentiereferentie voor externe documenten zonder de externe documenten zelf te verstrekken.Ongeldige Licentie-expressies: Het opnemen van licenties in de hierboven genoemde ABNF is de enige zekere manier om ervoor te zorgen dat geautomatiseerde processen SBOM nauwkeurig kunnen parseren en de licentie-informatie kunnen extraheren. We hebben echter zeer weinig naleving opgemerkt van het vasthouden aan de ABNF en in plaats daarvan afhankelijkheid van verschillende verkortingen die licenties gemakkelijk leesbaar maken voor mensen (en daardoor een vermoeden van nauwkeurigheid krijgen) terwijl ze fouten veroorzaken voor consumptietools. Voorbeelden van ongeldige licentie-expressies zijn:
PackageDeclaredLicense: MIT, LGPLv2, BSDPackageConcludedLicense: [MIT, LGPLv2, BSD]PackageConcludedLicense: [MIT, LGPLv2, BSD]LicenseID: MIT/LGPLv2
Om deze uitdagingen te overwinnen, is het cruciaal om SBOM voor te verwerken met kwaliteits- (bijv., sbomqs) of gegevensextractietools (bijv., sbomgr) om de nauwkeurigheid en volledigheid van de onderliggende SBOM en de volwassenheid van de SBOM-generator te begrijpen.
Beste praktijken voor het beheren van open source-licenties in SBOM:
Stel een duidelijk beleid vast voor het beheren van Open Source-licenties binnen uw organisatie. Dit omvat het definiëren van aanvaardbare licenties, het uitvoeren van regelmatige licentiebeoordelingen en het opleiden van ontwikkelaars over licentieverplichtingen.
Voer regelmatige licentie-audits en scans uit: Controleer regelmatig uw softwareprojecten om de naleving van Open Source-licenties te waarborgen. Maak gebruik van scan-tools die automatisch de licenties kunnen identificeren en rapporteren die zijn gekoppeld aan uw softwarecomponenten.
Maak gebruik van tools en automatisering: Maak gebruik van tools voor softwarecompositieanalyse (SCA) die automatisch SBOM's kunnen genereren en inzicht kunnen bieden in de naleving van licenties. Deze tools kunnen helpen het proces te stroomlijnen en de nauwkeurigheid bij het beheren van Open Source-licenties te waarborgen.
Betrek juridische expertise: Overweeg in complexe licentiescenario's juridische expertise in te schakelen om eventuele juridische uitdagingen te navigeren. Juridische professionals kunnen begeleiding bieden over licentiecompatibiliteit en -verplichtingen en helpen om eventuele licentieproblemen op te lossen.
Naarmate Open Source- en SBOM-praktijken blijven evolueren, is het essentieel om geïnformeerd te blijven over toekomstige trends en ontwikkelingen. Er zijn inspanningen gaande om SBOM-formaten te standaardiseren, wat gemakkelijker delen en interoperabiliteit tussen verschillende software-ecosystemen mogelijk maakt. Regelgevende vereisten met betrekking tot transparantie van de softwareleveringsketen komen ook op, wat de noodzaak van uitgebreide SBOM's en Open Source-licentiebeheer benadrukt.
Open Source-licenties in de Software Bill of Materials (SBOM) zorgen voor naleving, verminderen juridische risico's en bevorderen transparantie in softwareleveringsketens. Door Open Source-licenties op te nemen in SBOM, kunnen organisaties hun softwarecomponenten effectief beheren, voldoen aan licentieverplichtingen en vertrouwen opbouwen bij belanghebbenden. Blijf waakzaam, neem beste praktijken aan en omarm het evoluerende landschap van Open Source-licenties om met succes de complexiteit van softwareontwikkeling te navigeren.