De afgelopen jaren zijn mensen zich steeds meer bewust geworden van de inherente risico's van het gebruik van open source-componenten in hun software. Gezien het feit dat de meeste software een mix is van open source en propriëtaire logica, is het essentieel om te weten welke ingrediënten van buitenaf zijn geïmporteerd, direct of tijdelijk, voor een goed risicobeheer van het uiteindelijke softwareproduct. Omdat de dagen van het bijhouden van ingrediënten met behulp van ingewikkelde spreadsheets al lang voorbij zijn, en bovendien jammerlijk inefficiënt, is de belangrijkste manier om een dergelijke tracking te bewerkstelligen het gebruik van een SBOM – een softwarestuklijst. Net als andere stuklijsten is het in wezen een lijst met de software-ingrediënten waaruit de software is opgebouwd, met toevoeging van de relaties tussen verschillende ingrediënten, met speciale aandacht voor welke componenten van elkaar afhankelijk zijn.
Er zijn momenteel twee belangrijke SBOM-formaten op de markt: SPDX en CycloneDX.
Softwarepakket gegevensuitwisseling (SPDX) is een open-source, machinaal leesbaar SBOM-project van de Linux Foundation. De nieuwste versie van de SPDX is ontworpen in overeenstemming met de NTIA-standaard voor 'Minimale elementen voor een softwarestuklijst.' Het vermeldt de componenten, auteursrechten, licenties en beveiligingsreferenties van een stukje software.
CycloonDX (CDX) is ook een open-source en machineleesbaar SBOM-formaat ontwikkeld door de Open Web Application Security Project (OWASP)-gemeenschap. Als stuklijstformaat heeft CycloneDX andere toepassingen dan het opstellen van softwarestuklijsten. Het kan ook worden gebruikt om componenten, kwetsbaarheden en diensten van hardware en cloudsystemen te compileren.
Waarom is SBOM belangrijk?
De SBOM is uitermate nuttig voor softwareontwikkelteams, inkooporganisaties en eindgebruikers. Het gebruik ervan kan helpen garanderen dat open-sourcecomponenten en componenten van derden up-to-date zijn, en biedt inzicht in welke projectafhankelijkheden bekende kwetsbaarheden hebben die mogelijk misbruikt kunnen worden in uw software. Softwarekopers kunnen daarentegen SBOM's gebruiken om de risico's die inherent zijn aan een product te analyseren door middel van kwetsbaarheidsbeoordelingen.
Organisaties zouden er beter aan doen om samen te werken met hun leveranciers om ervoor te zorgen dat zij toegang hebben tot correcte en actuele informatie over de projectcomponenten die in systemen en/of producten worden geïmplementeerd. Ze moeten hun SBOM's ook regelmatig evalueren om de risico's van het gebruik van open-sourcecomponenten en componenten van derden te helpen minimaliseren.
SBOM-monsters
Afhankelijk van het SBOM-formaat dat u gebruikt, kunnen er verschillen zijn in de componenten van de SBOM. afhankelijk van de grootte en complexiteit van uw project kan een SBOM JSON-bestand gemakkelijk duizenden regels of meer bevatten. Omdat het kijken naar een bestand van duizend regels niet erg informatief is, laten we bestaande, eenvoudigere voorbeelden gebruiken om te zien wat elk SBOM-formaat inhoudt. We zullen voorbeelden van de twee belangrijkste formaten die momenteel op de markt zijn, nader bekijken.
SPDX
Het SPDX SBOM-voorbeeld dat we zullen volgen, is te vinden hier.
De JSON begint met algemene informatie over het bestand zelf – metadata.
Daarna krijgen we de metadata over de software die we onderzoeken:
Let op de controlesom en de waarde ervan. Elke sectie van de SBOM bevat de encryptie en het resultaat van het betreffende onderdeel, zodat mensen die het bestand onderzoeken er zeker van kunnen zijn dat de genoemde software of component identiek is aan degene waarnaar ze kijken.
Zonder die garantie zou je gemakkelijk meerdere exemplaren met dezelfde naam van componenten of software kunnen vinden en zou je geen idee hebben welke van deze versies gecontroleerd of opgenomen was in de software of de SBOM die deze beschrijft.
Na de beschrijving van de gecontroleerde software kunnen we de componenten gaan zien:
U kunt zien dat er meerdere velden zijn opgenomen om de licentie van een component, de startpagina, versie, volledige naam, enz. te beschrijven.
Een ander ding dat je in een SPDX-formaat kunt vinden zijn annotaties: toevoegingen die op een later tijdstip aan een sectie worden toegevoegd en die meer informatie en soms zelfs vrije tekst bevatten:
Voor meer informatie over dit formaat en de mogelijkheden ervan kunt u terecht op de website SPDX-pagina van de Linuxstichting.
CycloonDX
Het CycloneDX SBOM-formaat kan worden beschreven in een JSON-bestand, een XML-bestand of in protocolbuffers. Om de zaken gelijk en eenvoudig te houden, volgen we een vereenvoudigd CycloneDX JSON-voorbeeld. Het beschreven voorbeeld is te vinden hier.
De JSON begint met algemene metadata-informatie over het bestand.
Vervolgens werden de metadata over de software onderzocht:
Daarna de softwarecomponenten en hun afhankelijkheden:
Houd er rekening mee dat dit een vereenvoudigd voorbeeld is en dat het formaat nog veel andere informatie kan bevatten. Voor een uitgebreider overzicht van verschillende gebruiksscenario's kunt u de pagina met OWASP CyclonDX-gebruiksscenario's bekijken hier.
Hier is een voorbeeld van die pagina dat de opbouw van een lijst met afhankelijkheden demonstreert:
En hier is een uitgebreidere beschrijving van de verschillende componenten van dit formaat, afkomstig uit de OWASP BOM-mogelijkheden pagina:
Hoe een SBOM te gebruiken
Voel u niet schuldig als u de hier weergegeven bestandsvoorbeelden niet kunt volgen. Hoewel JSON-bestanden bij uitstek leesbaar zijn voor mensen, zijn ze veel geschikter om machinaal leesbaar te zijn, zodat speciaal gemaakte software de informatie kan opnemen en de resultaten die de analyse oplevert, kan uitspugen.
U kunt een lijst met softwarecomponenten gebruiken om te controleren of deze geen ongewenste open-sourcelicenties bevat (regel GPL3.0 of MPL1.1). U kunt regelmatig een lijst met afhankelijkheden controleren om te zien of er updates beschikbaar zijn, of de pakketnamen controleren in databases met kwetsbaarheden om te weten welke problematische afhankelijkheden uw software bevat.
Het klinkt misschien ingewikkeld om een SBOM op te nemen en al die informatie terug te krijgen, maar onthoud dat u het niet allemaal zelf hoeft te doen. Diensten zoals het Scribe Security-platform kunnen veel kopzorgen wegnemen en veel meer voordelen bieden. Neem gerust een kijkje op ons platform en kijk hoe u nog meer uw risico kunt beheren met behulp van ons continue monitoringsysteem gedurende uw ontwikkelingslevenscyclus en eindproducten.