Wat is een Software Bill of Materials (SBOM)?

SBOM helpt bij het inzichtelijk maken van de toeleveringsketens door de componenten te vermelden waarmee deze processen te maken hebben. Om een strategie voor risicobeheer in de softwaretoeleveringsketen te kunnen ontwikkelen, moeten we daarom SBOM begrijpen.

Rond deze tijd vorig jaar, in 2023, bracht de Security and Exchange Commission een persbericht uit over een rechtszaak tegen een in Austin, Texas, gevestigd softwarebedrijf. De rechtszaak weerspiegelde een zorg die softwarebedrijven over de hele wereld bezighoudt: de veiligheid van de softwaretoeleveringsketen. Cyber bedreigers richten zich al enige tijd op softwaretoeleveringsketens en maken daarbij gebruik van kwetsbaarheden, zoals die in het Log4j-framework, om malware te installeren.

Deze toenemende bezorgdheid over de beveiliging van de toeleveringsketen is een belangrijke reden waarom de Software Bill Of Materials (SBOM) zijn plaats vindt in officiële administratieve voorschriften voor cyberbeveiliging. Softwaretoeleveringsketens zijn vaak ingewikkeld en omvatten meerdere processen. SBOM helpt bij het inzichtelijk maken van de toeleveringsketens door de verschillende componenten en afhankelijkheden op te sommen waarmee deze processen rechtstreeks te maken hebben. Om een efficiënte strategie voor het risicobeheer van de softwaretoeleveringsketen te kunnen ontwikkelen, moeten we SBOM en de reikwijdte ervan begrijpen.

Inleiding tot SBOM (Software Bill of Materials)

Een Software Bill Of Materials (SBOM) is een gedetailleerde lijst van de verschillende onderdelen van software, inclusief de open-sourcecomponenten, bibliotheken en hun onderlinge relaties. Het idee is om belanghebbenden een grondig inzicht te geven in alles wat de software te bieden heeft, waardoor transparantie in de context van cyberbeveiliging wordt gewaarborgd. Door de veranderingen in de manier waarop software wordt ontwikkeld en geleverd, zijn er complexiteiten ontstaan die cyberaanvallers in staat stellen creatieve manieren te bedenken om te handelen. SBOM is daarom een essentieel vangnet dat inzicht geeft in onze applicaties.

Waarom is SBOM essentieel voor cyberbeveiliging?

Toen president Biden in zijn uitvoeringsbesluit over verbetering van de cyberbeveiliging de nadruk legde op SBOM, was dat omdat hij zich bewust was van de kwetsbaarheden in de toeleveringsketen waarop kwaadwillende campagnes zich richten. Een geneste lijst zoals SBOM splitst de software in wezen op in zijn bestanddelen en helpt deze kwetsbaarheden te identificeren. Hier zijn drie redenen waarom SBOM essentieel is voor cyberbeveiliging:

• Transparantie in software: SBOM helpt belanghebbenden te identificeren of er verouderde of risicovolle componenten in de software zitten. Als er bijvoorbeeld een verouderde encryptiebibliotheek of een loggingframework zoals Log4j is, kunnen de beveiligingsexperts het bijbehorende risico gemakkelijk identificeren.
• Open-sourcecomponenten volgen: Veel moderne softwareoplossingen stimuleren de integratie van open-sourcecomponenten en -bibliotheken. Deze worden niet altijd gecontroleerd op hun beveiligingsaspect en SBOM helpt daarom bij het opsporen van mogelijke risico's.
• Afhankelijkheidsbeoordeling: Hoewel sommige componenten op het eerste gezicht geen cyberbeveiligingsrisico vormen, kan hun afhankelijkheid van andere componenten of bibliotheken dat wel doen. Daarom helpt SBOM beveiligingsexperts ook om deze afhankelijkheden te onderzoeken en eventuele beveiligingslacunes te identificeren.
• Beveiliging van de toeleveringsketen: Transparantie binnen de toeleveringsketen met betrekking tot de beveiligingsstatus van verschillende softwarecomponenten helpt bij het waarborgen van proactieve beveiligingsstrategieën tegen mogelijke misbruik. SBOM biedt kopers alle benodigde informatie om deze strategieën voor beveiliging van de toeleveringsketen mogelijk te maken.
• Compliancebeheer: SBOM helpt belanghebbenden ook bij het beoordelen van softwareoplossingen en hun componenten op naleving van regelgeving. Met strenge regelgeving in sectoren als de gezondheidszorg, fintech, defensie en meer, kan non-compliance door een softwarecomponent gemakkelijk worden opgespoord.

Belangrijkste componenten van een SBOM (Software Bill of Materials)

Het rapport van NTIA’s, in overeenstemming met het uitvoeringsbesluit van de president, drie onderling samenhangende onderdelen van een SBOM voorgesteld die geacht worden de vereiste transparantie in de software te bieden. Deze “minimale elementen” kunnen een gedetailleerd beeld geven van de technologie en functionele blauwdruk van de software, waardoor deze zichtbaar wordt voor een grondige veiligheidsbeoordeling.

• Gegevensvelden: Dit element bepaalt de details over de softwarecomponenten in een formele SBOM-structuur. Gegevensvelden omvatten onder andere de naam van de leverancier, de versie van de component en de afhankelijkheidsrelatie om potentiële beveiligingskwetsbaarheden op te sporen.

• Ondersteuning voor automatisering: Automatiseringsondersteuning biedt de vereiste gegevensformaten die eenvoudige navigatie van SBOM-gegevens en machine-leesbaarheid van softwarecomponenten mogelijk maken. Dit is een essentieel element om snellere en autonome auditing van de software te garanderen. CycloneDX, SPDX en SWID-tags zijn de drie aanvaardbare formaten volgens het rapport.

• Processen: Dit zijn de noodzakelijke praktijken die zouden helpen om het genereren en beheren van SBOM's te integreren in de veilige ontwikkelingscyclus van de software. Deze praktijken bepalen verschillende aspecten van SBOM's, waaronder de frequentie waarmee ze worden gegenereerd, de diepgang van de componenten en afhankelijkheden die erin zijn opgenomen, en bekende/onbekende afhankelijkheden, onder andere.

Voordelen van de implementatie van SBOM (Software Bill of Materials)

Een onderzoek in 2022 suggereert dat 53% van de bedrijven in verschillende sectoren SBOM's beschouwt als een positief hulpmiddel voor rapportage en naleving. Een dergelijke positieve houding ten opzichte van SBOM kan alleen worden toegeschreven aan de inherente aandacht voor detail die deze rekeningen bieden. Het is deze aandacht voor detail die op zijn beurt leidt tot een groot aantal voordelen van SBOM:

• Transparantie in de hele toeleveringsketen: De gegevensvelden en relaties die door SBOM's worden vermeld, helpen bij het verkrijgen van een gedetailleerd overzicht van de hele softwaretoeleveringsketen. De verschillende versies van softwarecomponenten, hun afhankelijkheden en compatibiliteit binnen de software, en hun veiligheidsrisico's kunnen allemaal gemakkelijk worden geïdentificeerd en geanalyseerd.
• Consistente beveiligingshouding: Zelfs voor software die ondanks de potentiële risico's die uit de SBOM blijken, toch wordt aangeschaft, kunnen beveiligingsbeheerders zich beter voorbereiden op eventuele kwetsbaarheden. Op basis van de SBOM kunnen proactieve maatregelen worden genomen om eventuele beveiligingsrisico's te beperken.
• Compliancebeheer: Hoewel SBOM zelf een wettelijke verplichting is, helpt het belanghebbenden ook om strikt te voldoen aan de regelgeving voor bepaalde componenten van de software. Bovendien kan SBOM met regelmatige audits ook helpen bij het identificeren van eventuele afwijkingen in de naleving.
• Bedreigingen van derden: Alle veiligheidsrisico's die worden gevormd door open-sourcecomponenten van derden in de software kunnen eenvoudig worden opgespoord met behulp van SBOM. Zelfs als de leverancier bewust of onbewust een beveiligingslek over het hoofd ziet, kan SBOM helpen om dit terug te voeren naar de schuldige component van derden.

Hoe maak en beheer je een SBOM?

Er zijn tools beschikbaar om een SBOM met alle benodigde elementen te maken. Dergelijke tools hebben als essentiële functie om hun analyse van de softwarecomponenten te vertalen naar een van de gewenste SBOM-standaarden, zoals SPDX, CycloneDX en meer. Deze tools voor het genereren van SBOM's kunnen belanghebbenden ook helpen bij het opsporen van verouderde afhankelijkheden, licenties en andere aspecten die tot beveiligingsrisico's kunnen leiden. Zo werken deze tools:

• Stap 1 – De SBOM-tool integreren in de CI/CD-pijplijn: Om de verschillende componenten van de softwarecode te registreren, moet de SBOM-tool worden geïntegreerd in de CI/CD-pijplijn. Deze tools kunnen naar keuze op locatie of in een cloudomgeving worden geïnstalleerd.
• Stap 2 – De coderepository scannen: Vervolgens scant de tool de code om de verschillende componenten, bibliotheken, open-source frameworks en meer in de software te identificeren.
• Stap 3 – De codeanalyse vertalen: Zodra de codebase is gescand op alle componenten en afhankelijkheden, worden de gegevens vervolgens naar wens vertaald naar een van de standaard SBOM-formaten.
• Stap 4 – Genereren van SBOM: De vertaalde SBOM-gegevens kunnen uiteindelijk worden geëxporteerd in XML- of JSON-formaat voor verdere beoordeling. De NTIA-rapporten schrijven voor dat er elke keer dat er een update in de softwarecomponent plaatsvindt, een nieuwe SBOM moet worden gegenereerd.

SBOM-normen en -richtlijnen

De normen en richtlijnen voor het genereren van SBOM helpen de uniformiteit in de SBOM-structuur te behouden en dekken tegelijkertijd alle basiselementen in de geneste lijst van softwarecomponenten, bibliotheken en meer. Deze richtlijnen zijn ook nodig om het automatisch genereren en verwerken van SBOM te stimuleren.

• System Package Data Exchange (SPDX): Deze open standaard kan helpen bij het bouwen van een leesbare taal die kan worden vertaald naar bestandsformaten zoals XML, JSON, YAML en meer. De standaard kan de verschillende softwarecomponenten tijdens de ontwikkeling en implementatie efficiënt in kaart brengen door gegevens te verzamelen in de vorm van creatie-informatie, bestandsinformatie, pakketinformatie en meer.
• CycloneDX: Dit formaat is uitgebracht met een speciale focus op beveiliging en geautomatiseerde SBOM-generatie. De lichtgewicht specificatie kan zorgen voor een grondige analyse van softwarecomponenten, hun interactie met externe services en de relaties daartussen. De open-source standaard sluit ook goed aan bij de dynamische open-sourcecomponenten die regelmatig worden aangepast en opnieuw worden gedistribueerd.
• Software Identification Tags (SWID-tags): SWID-tags zijn in 2012 door ISO ingesteld en zijn bedoeld om de softwarecomponent gedurende zijn hele levenscyclus te volgen. Deze tags – namelijk primaire, patch-, corpus- en aanvullende tags – worden toegevoegd zodra de software is geïnstalleerd om details te verstrekken over het installatieprogramma, de installatie, patches en andere aspecten van een softwarecomponent.

Uitdagingen van SBOM (Software Bill of Materials)

De uitdagingen van SBOM hebben vooral betrekking op het genereren ervan, gezien de diep gestructureerde en formele aard ervan. Deze uitdagingen komen als volgt tot uiting:

• Volwassenheid van SBOM-tools: Hoewel de tools voortdurend worden ontwikkeld om te voldoen aan gestandaardiseerde SBOM-formaten en -structuren, zijn er nog steeds enkele hiaten. Bovendien is het gebruik van deze tools ook een gedoe dat verschillende belanghebbenden moeilijk vinden om te navigeren, gezien het gebrek aan goede interfaces, interfaces en interoperabiliteit, naast andere factoren.
• Trage acceptatie en integratie: Er zijn nog steeds externe leveranciers die zich niet aan de SBOM-verplichting houden, waardoor er een achterstand is in de acceptatie en integratie van SBOM-bronnen, met name bij open-source software.
• Continuïteit in SBOM-generatie: Het genereren van SBOM's tot een continu proces maken, zodat dit in verschillende stadia van de SDLC plaatsvindt, is nog steeds niet gerealiseerd door bedrijven. Hoewel dit een ambitie is voor de meeste bedrijven die met SBOM's werken, hebben veel van hen dit nog niet bereikt.
• Extra beveiligingsproblemen: Er zijn beveiligingsexperts die ook beweren dat algemeen kwetsbaarheidsbeheer digitale ecosystemen niet kan beschermen tegen externe bedreigingen. Organisaties moeten prioriteiten stellen voor de kwetsbaarheden die ze willen aanpakken en op basis daarvan een strategie ontwikkelen. Dit is moeilijk te realiseren bij het werken met SBOM's vanwege de extra complexiteit.

Best practices voor effectief gebruik van SBOM

Het genereren van SBOM is al een goede praktijk. De beste praktijk is om dit consistent en gedurende de hele SDLC te doen. Hier zijn enkele andere praktijken die dat mogelijk maken en het nut van SBOM voor de beveiliging van de toeleveringsketen maximaliseren:

• Vroeg genereren en regelmatig bijwerken: Het is essentieel dat SBOM's zo vroeg mogelijk in de SDLC worden gegenereerd, zodat elke toegevoegde afhankelijkheid vanaf het begin kan worden geregistreerd. Door de SBOM regelmatig bij te werken, wordt ervoor gezorgd dat alle builds en releases van de verschillende softwarecomponenten naar behoren in de lijst worden opgenomen.
• Geautomatiseerde generatie van SBOM's: Aangezien automatiseringsondersteuning een essentieel onderdeel is van SBOM, is het logisch om over automatiseringsmiddelen te beschikken om deze te genereren. Automatisering zorgt er ook voor dat er regelmatig facturen worden gegenereerd via de SDLC.
• Gestandaardiseerde formaten: Formaten zoals SPDX of CycloneDX hebben de vereiste diepgang om echt veiligheidsgevoelige SBOM-gegevens vast te leggen. Het gebruik van dergelijke gestandaardiseerde formaten zou de interoperabiliteit en machine-leesbaarheid van de factuur garanderen.
• Versiebeheer: Versiebeheer in SBOM's zorgt ervoor dat alle nieuwe wijzigingen die in de softwarecomponent worden aangebracht of vrijgegeven, gemakkelijk kunnen worden gevolgd voor beveiligingsbeoordeling. Dit maakt de SBOM ook beter controleerbaar bij het beheer van afhankelijkheden.

SBOM-gebruiksscenario's

Hoewel het primaire nut van SBOM ligt in het bieden van cruciale inzichten in softwarekwetsbaarheden, kan SBOM voor veel gebruiksscenario's worden ingezet, waaronder:

• Softwarebeveiliging: SBOM's kunnen beveiligingsteams helpen om kwetsbare delen van de softwarecode nauwkeurig te identificeren. De teams kunnen het gebruiken om delen van software op te sporen en aan te pakken die vatbaar zijn voor misbruik door cyberaanvallers.

• Beveiliging van de toeleveringsketen: Veel overheidsinstellingen, waaronder de Amerikaanse en sommige Europese overheden, hebben het gebruik van SBOM's in de softwaretoeleveringsketens verplicht gesteld. Experts voorspellen dat deze binnenkort ook beschikbaar zullen zijn voor eindklanten.

• Gemakkelijke aanschaf: Nu bedrijven in alle sectoren zich zorgen maken over cyberbeveiligingsincidenten, wekken SBOM's vertrouwen bij inkoopteams die op zoek zijn naar een softwareoplossing. De geboden transparantie heeft bijgedragen aan het opbouwen van vertrouwen tussen beide partijen.

• Gemakkelijke ontwikkeling: Aangezien SBOM's een gedetailleerd overzicht bevatten van de afhankelijkheden en relaties tussen softwarecomponenten, is het voor ontwikkelaars gemakkelijker om aan nieuwe componenten te werken zonder eerdere functies te verstoren.

Verschillen tussen SBOM en SCA

Software Bill of Materials (SBOM) en Software Composition Analysis (SCA) hebben zeker overlappende kenmerken die kunnen helpen om de verschillende onderdelen van software te begrijpen. Een weloverwogen keuze tussen beide hangt daarom af van de reikwijdte van de softwarelevenscyclus waarvoor u ze wilt gebruiken.

Dit is wat bedrijfsleiders moeten weten om die keuze te kunnen maken:

Aspect	SBOM	SCA
Focus	Specifieke focus op het registreren van diverse softwarecomponenten en het genereren van een gedetailleerde lijst.	De focus ligt op het beheren en analyseren van componenten op kwetsbaarheden.
Aanbod	Biedt een hiërarchische inventaris van componenten, bibliotheken en afhankelijkheden	Biedt identificatie en herstel van beveiligingskwetsbaarheden als gevolg van risicovolle componenten.
Bruikbaarheid	De bruikbaarheid is breder en omvat ontwikkelaars, beveiligingsteams, inkoopteams, enz.	Meestal beperkt tot beveiligingsteams die SCA-tools nodig hebben om kwetsbare componenten aan te pakken.

Verschillen tussen BOM en SBOM

BOM en SBOM lijken qua aard zo op elkaar dat ze vaak met elkaar worden verward. Ze behoren echter tot twee heel verschillende domeinen. Terwijl BOM een inventaris is die meer relevant is voor de productiesector, heeft SBOM een zeer specifieke rol binnen de software-engineering. Hieronder volgt hoe besluitvormers de twee kunnen onderscheiden:

Aspect	Bill of Materials (BOM)	Software-stuklijst (SBOM)
Toepassing	Meer van toepassing op fysieke producten zoals hardware of elektronica.	Toepassing speciaal voor softwareproducten en hun toeleveringsketens.
Naleving	Compliance gericht op productie- of bouwvoorschriften.	Compliance gericht op softwarelicenties, beveiligingsbehoeften, enz.
Gebruikers	Fabrikanten, supply chain managers.	Ontwikkelaars, beveiligingsteams en regelgevingsauditors.

Conclusie

Als onderdeel van de administratieve regelgeving voor cyberbeveiliging neemt SBOM al een cruciale plaats in binnen de softwarelevenscyclus. De beveiliging van softwaretoeleveringsketens is een van de vele toepassingen waarvoor het kan worden gebruikt. Met gedistribueerde architecturen, gecodificeerde infrastructuur en wijdverspreide netwerken worden softwareoplossingen nu gebruikt voor complexere zakelijke toepassingen dan ooit tevoren. De belangrijkste componenten en standaardformaten van SBOM maken het een krachtige bondgenoot in het tegengaan van incidenten zoals Uber en Solarwinds.

Op basis van onze bespreking in deze blog kunnen bedrijfsleiders en beveiligingsexperts de best practices volgen om het genereren van SBOM's te automatiseren en deze in te zetten voor de beveiliging van de toeleveringsketen.

SentinelOne kan u helpen bij het gebruik van functies zoals SBOM om uw softwaretoeleveringsketen te beschermen. Lees hier meer over onze expertise hier.

FAQs

Wat is een SBOM en waarom is het belangrijk?

Een software bill of materials, of SBOM, is een gedetailleerd overzicht van de verschillende softwarecomponenten, bibliotheken, afhankelijkheden en meer in de vorm van een hiërarchische lijst. Het is belangrijk om inzicht te hebben in risicovolle delen van de softwarecode, die kunnen worden misbruikt voor cyberaanvallen.

Hoe verbetert een SBOM de beveiliging van de softwaretoeleveringsketen?

Dankzij de diepgaande zichtbaarheid die SBOM biedt, is het voor beveiligingsexperts gemakkelijker om potentiële kwetsbaarheden in de softwaretoeleveringsketen op te sporen en effectief aan te pakken.

Wat zijn de belangrijkste onderdelen van een SBOM?

Volgens de administratieve voorschriften omvatten de belangrijkste elementen van een SBOM gegevensvelden, praktijken en processen, en automatiseringsondersteuning.

Hoe kunnen organisaties een effectieve SBOM-strategie implementeren?

Voor een effectieve SBOM-strategie is het essentieel om best practices te volgen, zoals vroege generatie, regelmatige updates, geautomatiseerde generatie en integratie met CI/CD-pijplijnen.

Welke normen moeten worden gevolgd bij het maken van een SBOM?

De drie normen die het beste werken met SBOM zijn SPDX, CycloneDC en SWID Tags.

Hoe kom ik aan een software-stuklijst?

Om een software-stuklijst te genereren, kunt u gebruikmaken van automatiseringstools die u kunnen helpen met de vereiste formaten en outputs. Onze experts bij SentinelOne kunnen u hierbij helpen.