De Software Bill of Materials (SBOM) is een lijst met alle componenten, bibliotheken en andere afhankelijkheden die in een softwareapplicatie worden gebruikt. Standaardformaten voor SBOM's zijn SPDX, CycloneDX en CPE (Common Platform Enumeration). Deze formaten bieden een gestructureerde manier om de componenten en afhankelijkheden in een softwareapplicatie weer te geven, waardoor het gemakkelijker wordt om de beveiligingsrisico's die aan deze componenten verbonden zijn, te begrijpen en te beheren.
In dit artikel gaan we in detail uitleggen wat de verschillende SBOM-formaten en standaarden zijn, wat een SBOM moet omvatten en waarom alle organisaties deze moeten gebruiken.
Wat is een SBOM-standaard?
De complexiteit en het dynamische karakter van de toeleveringsketens van moderne softwaresystemen vormen een aanzienlijke uitdaging voor de transparantie. Dit gebrek aan transparantie draagt bij aan de cyberveiligheidsrisico’s en verhoogt de kosten die gepaard gaan met ontwikkeling, aanschaf en onderhoud. De gevolgen hiervan zijn verstrekkend en treffen niet alleen bedrijven, maar ook collectieve zaken zoals de openbare veiligheid en de nationale veiligheid in onze onderling verbonden wereld.
Een grotere transparantie in de toeleveringsketens van software kan leiden tot een vermindering van de cyberbeveiligingsrisico's en -kosten door:
- Het verbeteren van de identificatie van kwetsbare systemen en het identificeren van de hoofdoorzaak van incidenten
- Het verminderen van ongepland en onproductief werk
- Dit maakt een beter geïnformeerde marktdifferentiatie en componentselectie mogelijk
- Het standaardiseren van formaten in meerdere sectoren, wat leidt tot een vermindering van dubbel werk
- Het detecteren van verdachte of nagemaakte softwarecomponenten
Het verzamelen en delen van deze informatie in een duidelijk en consistent formaat kan helpen de kosten te verlagen, de betrouwbaarheid te verbeteren en het vertrouwen in onze digitale infrastructuur te vergroten.
Met dat doel, de NTIA Software Transparency Working Group on Standards and Formats werd in 2018 opgericht om de huidige formaten voor softwarestuklijsten te evalueren en potentieel toekomstig gebruik te identificeren. De groep onderzocht bestaande standaarden en initiatieven met betrekking tot het identificeren van externe componenten en gedeelde bibliotheken die in softwareproducten worden gebruikt en het communiceren van deze informatie in een machinaal leesbaar formaat. De groep hield geen rekening met eigen formaten. Het oorspronkelijke onderzoek werd eind 2019 vrijgegeven en in 2021 bijgewerkt, met de nadruk op het benadrukken van de voordelen van het SBOM-tooling-ecosysteem en het belang van coördinatie en harmonisatie in de technische SBOM-wereld. De belangrijkste conclusie is dat SBOM-gegevens in verschillende formaten kunnen worden overgedragen en dat het ecosysteem de interoperabiliteit daartussen moet ondersteunen.
De werkgroep ontdekte dat drie formaten vaak worden gebruikt:
- Software Package Data Exchange (SPDX®), een open-source, machinaal leesbaar formaat ontwikkeld door de Linux Foundation en nu een ISO/IEC-standaard
- CycloneDX (CDX), een open-source, machinaal leesbaar formaat ontwikkeld door de OWASP-gemeenschap
- Software Identificatie (SWID), een ISO/IEC-industriestandaard die door verschillende commerciële software-uitgevers wordt gebruikt
Het is vermeldenswaard dat deze drie formaten een aantal gemeenschappelijke informatie delen. Ze worden echter traditioneel in verschillende stadia van het softwareontwikkelingsproces gebruikt en zijn bedoeld voor verschillende doelgroepen. We zullen elk van deze formaten in dit artikel gedetailleerd bespreken.
Wat moet er in een SBOM staan?
De minimale componenten van de NTIA van een SBOM, ook wel elementen genoemd, bestaat uit drie brede en onderling verbonden gebieden. Deze elementen maken een flexibele benadering van softwaretransparantie mogelijk, waarbij zowel de technologie als de functionele werking worden aangepakt. In de toekomst kunnen meer details of technische verbeteringen worden toegevoegd. Zoals eerder vermeld zijn dit momenteel de minimale componenten, en organisaties hebben mogelijk meer nodig. Het vermogen tot transparantie in de softwaretoeleveringsketen kan in de loop van de tijd verbeteren en evolueren.
Deze minimaal vereiste elementen voor SBOM worden doorgaans in drie categorieën onderverdeeld:
- Data velden: Een SBOM moet belangrijke gegevens over softwarecomponenten bevatten, zoals de componentnaam, de naam van de leverancier, de versie en unieke identificatiegegevens. Het moet ook informatie bevatten over de afhankelijkheden tussen componenten, waardoor een nauwkeurige identificatie en tracking van alle softwarecomponenten in de hele toeleveringsketen mogelijk wordt.
- Praktijken en processen: De SBOM-documentatie moet ook standaardpraktijken en -procedures schetsen voor het maken en bijwerken van de SBOM, het distribueren en openen ervan, en voor het afhandelen van fouten.
- Automatiseringsondersteuning: De softwarestuklijst moet zowel machineleesbaar zijn als automatisch kunnen worden gegenereerd voor het continu volgen van gegevens. Het is meestal in standaardformaten zoals SPDX-, CycloneDX- en SWID-tags, waardoor ze ook leesbaar zijn voor mensen.
SPDX SBOM standaardformaat
De SPDX®-specificatie (Software Package Data Exchange) is een ISO/IEC-standaard voor het delen van informatie over softwarecomponenten, licenties, auteursrechten en beveiligingsdetails in meerdere bestandsformaten. Dit project heeft een reeks standaarden voor gegevensuitwisseling ontwikkeld en blijft deze verbeteren waarmee bedrijven en organisaties softwaremetadata kunnen delen in een formaat dat zowel door mensen als machines kan worden begrepen, waardoor processen in de softwaretoeleveringsketen worden vereenvoudigd.
SPDX-informatie kan worden gekoppeld aan specifieke softwareproducten, componenten of sets van componenten, individuele bestanden of zelfs kleine codefragmenten. Het SPDX-project is gericht op het creëren en verfijnen van een taal om de gegevens te beschrijven die kunnen worden uitgewisseld als onderdeel van een SBOM, en de mogelijkheid om deze gegevens in meerdere bestandsformaten te presenteren (RDF/XML, XLSX, tag-value, JSON, YAML en XML) om het eenvoudig te maken informatie over softwarepakketten en gerelateerde inhoud te verzamelen en te delen, wat resulteert in verbeteringen in tijd en nauwkeurigheid.
De SPDX-specificatie schetst de velden en secties die nodig zijn voor een geldig document, maar het is belangrijk op te merken dat niet alle secties verplicht zijn; alleen de sectie met aanmaakinformatie is vereist. De maker van het document kan kiezen welke secties en velden hij wil opnemen, waarin de software- en metadata-informatie wordt beschreven die hij wil delen.
SPDX kan op effectieve wijze Software Bill of Material-gegevens vastleggen door alle componenten te vertegenwoordigen die voorkomen in de ontwikkeling en implementatie van software. Het wordt gebruikt voor het documenteren van distro .iso-afbeeldingen, containers, softwarepakketten, binaire bestanden, bronbestanden, patches en zelfs kleine codefragmenten die in andere bestanden zijn ingebed. SPDX biedt een uitgebreide set relaties om software-elementen binnen documenten en tussen SBOM-documenten met elkaar te verbinden. Een SPDX SBOM-document kan ook verwijzen naar externe bronnen, zoals de National Vulnerability Database en andere metagegevens van het verpakkingssysteem.
Een SPDX-document bestaat uit verschillende componenten: creatie-informatie, pakketinformatie, bestandsinformatie, fragmentinformatie, andere licentie-informatie, relaties en annotaties.
Elk SPDX-document kan worden weergegeven door een volledige datamodelimplementatie en identificatiesyntaxis, waardoor uitwisseling tussen verschillende data-uitvoerformaten (RDF/XML, tag-waarde, XLSX) en formele validatie van de nauwkeurigheid van het document mogelijk is. Versie 2.2 van de SPDX-specificatie bevat aanvullende uitvoerformaten zoals JSON, YAML en XML, en behandelt ook “bekende onbekenden” zoals geïdentificeerd in het originele SBOM-document. Meer informatie over het onderliggende datamodel van SPDX is te vinden in bijlage III van de SPDX-specificatie en op de SPDX-website.
CycloneDX SBOM standaardformaat
Het CycloneDX-project werd in 2017 opgericht met als doel een volledig geautomatiseerde, op beveiliging gerichte SBOM-standaard te ontwikkelen. De kernwerkgroep brengt jaarlijks onveranderlijke en achterwaarts compatibele versies uit, waarbij gebruik wordt gemaakt van een op risico gebaseerd standaardproces. CycloneDX bevat bestaande specificaties zoals pakket-URL, CPE, SWID en SPDX-licentie-ID's en -expressies. De SBOM's kunnen in verschillende formaten worden weergegeven, waaronder XML, JSON en Protocol Buffers (protobuf).
CycloneDX is een lichtgewicht SBOM-specificatie die bedoeld is voor gebruik bij analyse van supply chain-componenten en softwarebeveiliging. Het maakt de communicatie mogelijk van de inventaris van softwarecomponenten, externe services en de relaties daartussen. Het is een open-sourcestandaard ontwikkeld door het OWASP (Open Web Application Security Project).
CycloneDX kan de dynamische aard van open-sourcecomponenten vastleggen waarvan de broncode toegankelijk, aanpasbaar en herdistribueerbaar is. De specificatie kan de stamboom van een component weergeven, inclusief zijn voorouders, afstammelingen en varianten, waarbij de afstamming van de component vanuit elk perspectief wordt beschreven, evenals de commits, patches en diffs die het uniek maken.
Het CycloneDX-project houdt een lijst bij van bekende open-source en propriëtaire tools die de standaard ondersteunen of ermee compatibel zijn, die door de gemeenschap wordt ondersteund.
De CycloneDX-specificatie bevat een gedetailleerd objectmodel dat consistentie tussen alle implementaties garandeert. Het kan worden gevalideerd met behulp van XML Schema en JSON Schema, of met behulp van de CycloneDX-opdrachtregelinterface. Er zijn ook mediatypen voor XML en JSON beschikbaar voor automatische levering en consumptie van ondersteunde formaten.
CycloneDX SBOM's kunnen de volgende informatie bevatten: BOM Metadata, componenten, services, afhankelijkheden, samenstellingen en extensies
CycloneDX is een uitgebreide SBOM-standaard die verschillende soorten software kan karakteriseren, waaronder applicaties, componenten, services, firmware en apparaten. Het wordt veel gebruikt in alle sectoren om softwarepakketten, bibliotheken, frameworks, applicaties en containerimages te beschrijven. Het project is compatibel met grote ontwikkelingsecosystemen en biedt implementaties voor softwarefabrieken zoals GitHub-acties, waardoor organisaties de creatie van SBOM volledig kunnen automatiseren.
SWID-tag
SWID Tags, of Software Identification Tags, zijn gemaakt om organisaties in staat te stellen op transparante wijze de software te volgen die op hun beheerde apparaten is geïnstalleerd. De standaard is in 2012 door ISO opgesteld en in 19770 herzien als ISO/IEC 2-2015:2015. Deze tags bevatten gedetailleerde informatie over een specifieke release van een softwareproduct.
De SWID-standaard schetst een levenscyclus voor het volgen van software: een SWID-tag wordt aan een eindpunt toegevoegd tijdens de installatie van een softwareproduct en verwijderd tijdens het verwijderingsproces van het product. Het bestaan van een specifieke SWID-tag komt rechtstreeks overeen met de aanwezigheid van de software die deze beschrijft. Meerdere standaardisatieorganisaties, zoals de Trusted Computing Group (TCG) en de Internet Engineering Task Force (IETF), nemen SWID-tags op in hun standaarden.
Om de levenscyclus van een softwarecomponent bij te houden, heeft de SWID-specificatie vier soorten tags: primair, patch, corpus en aanvullend. Corpus-, primaire en patch-tags dienen soortgelijke doeleinden in die zin dat ze het bestaan en de aanwezigheid van verschillende soorten software beschrijven, zoals software-installatieprogramma's, software-installaties en softwarepatches, en de mogelijke status van softwareproducten. Aan de andere kant bieden aanvullende tags aanvullende details die niet voorkomen in corpus-, primaire of patch-tags.
Aanvullende tags kunnen aan elke andere tag worden gekoppeld om extra metagegevens te verschaffen die nuttig kunnen zijn. Samen kunnen SWID-tags een verscheidenheid aan functies uitvoeren, zoals softwaredetectie, configuratiebeheer en kwetsbaarheidsbeheer.
SWID-tags kunnen functioneren als een SBOM, omdat ze identificerende informatie leveren voor een softwarecomponent, een lijst met bestanden en cryptografische hashes voor de artefacten van de component, en herkomstinformatie over de maker van de SBOM (tag) en de maker van de softwarecomponent. De tags kunnen ook linken naar andere tags, waardoor een afhankelijkheidsboom kan worden weergegeven.
SWID-tags kunnen worden gegenereerd tijdens het bouw- en verpakkingsproces, waardoor automatisch een op SWID-tags gebaseerde SBOM kan worden gemaakt wanneer de bijbehorende softwarecomponent wordt verpakt.
Waarom zijn softwarestuklijsten belangrijk?
Software Bill of Materials (SBOM's) worden steeds belangrijker voor organisaties omdat ze de software die ze gebruiken willen beheren en beveiligen. Er is geen kort antwoord op de vraag wat is een SBOM. SBOM's bieden een uitgebreide lijst van alle componenten en afhankelijkheden waaruit een softwarepakket bestaat, inclusief informatie zoals versienummers, auteurs en licentie-informatie. Deze informatie is van cruciaal belang voor de beveiliging en compliance, maar ook voor het volgen van de herkomst van softwarecomponenten.
Veel organisaties, waaronder die in gereguleerde sectoren, gebruiken SBOM's om naleving van regelgeving zoals de Algemene Verordening Gegevensbescherming (AVG) en de Payment Card Industry Data Security Standard (PCI DSS) te garanderen. SBOM's kunnen ook helpen bij het identificeren en beheren van kwetsbaarheden in software, en bij het volgen van de herkomst van softwarecomponenten. Daarnaast kunnen SBOM's helpen bij het beheer van softwarelicenties, zodat organisaties de software gebruiken in overeenstemming met de voorwaarden van hun licenties.
SBOM's kunnen ook worden gebruikt om het gebruik van open-sourcesoftware te volgen, wat steeds gebruikelijker wordt bij softwareontwikkeling. Door gedetailleerde informatie te verstrekken over de open-sourcecomponenten die in een softwarepakket worden gebruikt, kunnen SBOM's organisaties helpen bij het waarborgen van de naleving van open-sourcelicenties.
Bovendien kunnen SBOM's worden gebruikt ter ondersteuning van de ontwikkeling en het onderhoud van software. Door gedetailleerde informatie te verstrekken over de componenten die in een softwarepakket worden gebruikt, kunnen SBOM's ontwikkelaars helpen de afhankelijkheden van een softwarepakket te begrijpen, wat hen kan helpen potentiële compatibiliteitsproblemen te identificeren en weloverwogen beslissingen te nemen over het gebruik van nieuwe componenten.