Wat is een softwarestuklijst (SBOM)?

SBOM's in de softwaretoeleveringsketen: lessen die zijn geleerd uit de XZ Utils Backdoor

De achterdeurzaak van XZ Utils, geïdentificeerd als CVE-2024-3094, betrof een kwaadaardige achterdeur die was ingevoegd in een veelgebruikt Linux-hulpprogramma. Deze kwetsbaarheid werd ontdekt door Andres Freund vlak vóór de integratie ervan in de belangrijkste Linux-distributies, waardoor miljoenen servers in gevaar kwamen. De onderzoeker ontdekte deze kwetsbaarheid voordat deze in productie ging, waardoor daadwerkelijke schade werd voorkomen. Hoewel SBOM's in dit specifieke geval geen rol speelden, zouden ze van cruciaal belang zijn als de kwetsbaarheid zich had verspreid, zoals te zien was bij Log4j in 2021. Bij een wijdverbreide kwetsbaarheid als Log4j zouden SBOM-platforms effectief kunnen helpen bij het begrijpen van de explosieradius. en het uitvoeren van impactanalyses. Als de XZ Utils-kwetsbaarheid was ingezet, hadden tools als Scribe Hub een belangrijke rol kunnen spelen bij het waarschuwen van bedrijven, waardoor ze hun software-inventaris konden doorzoeken, de implementatie van gecompromitteerde versies konden blokkeren en hun algehele beveiligingspositie konden verbeteren.

Definitie van softwarestuklijst

De Software Bill of Materials (SBOM) vermeldt alle onderdelen en softwareafhankelijkheden die betrokken zijn bij de ontwikkeling en levering van een applicatie. SBOM's zijn vergelijkbaar met stuklijsten (BOM's) die worden gebruikt in toeleveringsketens en productie. Er bestaat geen gemeenschappelijk kenmerk voor alle leveranciers in de IT-industrie om de fundamentele codecomponenten waarop een applicatie is gebouwd nauwkeurig te beschrijven.

Typische SBOM omvat licentie-informatie, versienummers, componentdetails en leveranciers. Een formele lijst van alle feiten verkleint de risico's voor zowel de fabrikant als de gebruiker, doordat anderen kunnen begrijpen wat er in hun software zit en dienovereenkomstig kunnen handelen. SBOM's zijn niet nieuw in de software-industrie, maar worden steeds belangrijker naarmate de ontwikkeling geavanceerder en duurder wordt. In een aantal bedrijven zijn ze de laatste tijd een basisvereiste geworden.

Cloud-native apps beveiligen: de kracht van verbeterde SBOM's

De opkomst van cloud-native applicaties heeft geleid tot een grotere complexiteit bij het beveiligen van moderne softwareomgevingen. Deze applicaties, gekenmerkt door hun dynamische en gedistribueerde aard, bestaan ​​uit onderling verbonden microservices en externe componenten, waardoor het aanvalsoppervlak groter wordt. Het verbeteren van SBOM's wordt in deze context van cruciaal belang, omdat ze gedetailleerd inzicht bieden in alle componenten en afhankelijkheden binnen een cloud-native architectuur. Een effectieve SBOM helpt kwetsbaarheden te identificeren, zorgt voor naleving van beveiligingsnormen en vergemakkelijkt een snelle reactie op incidenten. Door gebruik te maken van robuuste SBOM's kunnen organisaties een uitgebreide inventaris van hun softwaremiddelen bijhouden, wijzigingen volgen en potentiële beveiligingsrisico's vroegtijdig detecteren. In het tijdperk van cloud-native applicaties is het verbeteren van SBOM-praktijken onmisbaar voor het versterken van de beveiliging en het behouden van de integriteit van complexe software-ecosystemen.

Voordelen van de SBOM

Omgaat met bedreigingen voor de integriteit

Aanvallen kunnen op elk punt in de normale softwaretoeleveringsketen plaatsvinden, en deze aanvallen worden in de wereld van vandaag steeds zichtbaarder, ontwrichtender en duurder. De integriteit kan worden gehandhaafd met behulp van een SBOM, door te verifiëren dat de daarin voorkomende componenten en bestanden dezelfde zijn als de bedoeling was. Een van de componenten van het CycloneDX-formaat is bijvoorbeeld een hash-waarde die kan worden gebruikt bij het exact matchen van bestanden en componenten. Omdat een SBOM geen statisch document is, moet het telkens worden bijgewerkt als er een wijziging optreedt in de beschreven software of de componenten ervan.

Maakt zichtbaarheid van productcomponenten mogelijk

Bedrijven moeten het vertrouwen van klanten creëren om loyaliteit te genereren en herhaalaankopen te bevorderen. In plaats van garanties of beloftes bieden gedeelde SBOM's een beter inzicht in de kwaliteit van de technologieën die zij gebruiken.

Maakt eenvoudiger scannen op kwetsbaarheden mogelijk

Bedrijven kunnen SBOM's gebruiken om kwetsbaarheden te identificeren en te elimineren voordat ze de productie bereiken. Nieuwe kwetsbaarheden in productiesoftware kunnen snel worden verholpen. Uiteindelijk helpen SBOM's ingenieurs bij het sneller ontdekken en oplossen van beveiligingsfouten.

Maakt gebruik van licentiebeheer voor uw product

Het adopteren van software stuklijsten kan het beheer van softwarelicenties helpen verbeteren. Elk stukje software wordt geleverd met een licentie die specificeert hoe het legaal mag worden gebruikt en gedistribueerd. De samenstellende componenten van een toeleveringsketen die samen een volledige applicatie vormen, kunnen over een verscheidenheid aan verschillende licenties beschikken. Elk bedrijf dat het programma gebruikt, is wettelijk verplicht om de licentievoorwaarden te volgen. Het is mogelijk dat er geen manier is om te bepalen wat de licenties nodig hebben of hoe hieraan te voldoen zonder een softwarestuklijst.

Principes van een goed gevormde SBOM

De minimale componenten van een goed gevormde SBOM zijn onderverdeeld in drie categorieën:

Data velden

Het doel van deze velden is om deze componenten adequaat te kunnen identificeren. Hierdoor kunt u ze in de hele softwaretoeleveringsketen monitoren en ze koppelen aan andere nuttige gegevensbronnen, zoals kwetsbaarheids- of licentiedatabases. Enkele voorbeelden van gegevensvelden zijn de naam van de leverancier, de componentnaam, de versie van de component, andere unieke identificatiegegevens, afhankelijkheidsrelatie, auteur van SBOM-gegevens en tijdstempel.

Automatisering Ondersteuning

Organisaties die SBOM-componentgegevens nauwlettend in de gaten willen houden, zullen deze in een consistente en gemakkelijk te begrijpen stijl moeten aanleveren. Dit wordt behandeld in het gedeelte SBOM-basisvereisten onder 'Automatiseringsondersteuning'. Bij het verzenden van SBOM’s over de organisatiegrenzen heen zijn er drie standaarden waaruit u kunt kiezen:

1. Softwarepakket gegevensuitwisseling (SPDX)
2. CycloonDX
3. Software-identificatietags (SWID).

Deze worden verderop in dit artikel verder besproken.

Praktijken en processen

Ten slotte worden in het gedeelte ‘Praktijken en processen’ zes standaarden uiteengezet voor hoe en wanneer SBOM’s moeten worden bijgewerkt en geleverd. Ze zijn als volgt:

• Als de softwarecomponent wordt geüpgraded met een nieuwe build of release, moeten er nieuwe SBOM's worden geproduceerd.
• Auteurs van SBOM's moeten componenten op het hoogste niveau en hun transitieve afhankelijkheden opnemen.
• Als de SBOM geen volledige afhankelijkheidsboom biedt, moet de SBOM-auteur uitleggen of dit komt doordat (a) de component geen afhankelijkheden meer heeft, of (b) het bestaan ​​van afhankelijkheden onbekend en onvolledig is.
• SBOM's moeten op een “tijdige” manier worden gedistribueerd en afgeleverd, met “de juiste toegangsrechten en rollen”.
• Bedrijven die sommige componenten van een SBOM geheim willen houden, moeten toegangscontroleparameters specificeren, die specifieke regels en procedures bevatten voor het opnemen van SBOM-gerelateerde informatie in de gebruikershandleiding en hulpmiddelen. Simpel gezegd: als er iets is dat geheim moet worden gehouden in het belang van de organisatie, dan wordt het proces om het geheim te houden in dit gedeelte beschreven. 
• Omdat de standaarden die het genereren van SBOM beheersen nieuw zijn, wordt SBOM-gebruikers geadviseerd om (onbedoelde) fouten of weglatingen te vergeven.

Verschillende SBOM-formaten

Natuurlijk kunt u handmatig een SBOM-factuur genereren door de vele componenten in de software die u hebt geproduceerd op te sommen. Het onderhouden van enorme codebases met tientallen of zelfs honderden afhankelijkheden en componenten van derden is echter een vermoeiende en tijdrovende taak, vooral voor ontwikkelaars die grote codebases beheren met meerdere componenten en afhankelijkheden van derden. Sommige ontwikkelaars hebben mogelijk componenten van derden in een applicatie opgenomen zonder deze te documenteren. Als gevolg hiervan zijn de huidige ontwikkelaars mogelijk niet bekend met de volledige codebase.

Om adoptie werkelijkheid te maken, moeten SBOM’s zich houden aan door de industrie geaccepteerde normen die interoperabiliteit tussen diverse sectoren en organisaties mogelijk maken. Organisaties beschikken dankzij een aantal standaarden al over de architectuur om gegevens over softwarecomponenten te ontwikkelen, beheren en distribueren.

SPDX: Gegevensuitwisseling softwarepakket

De Softwarepakket gegevensuitwisseling (SPDX) is de belangrijkste open standaard voor Software Bill of Materials-formaten ontwikkeld door de Linux Foundation in 2010. Softwarecomponenten, auteursrechten, licenties en beveiligingsreferenties zijn allemaal opgenomen in SPDX-bestanden. De SPDX-specificatie is compatibel met de voorgestelde NTIA SBOM-minimumnormen en gebruiksscenario's. Organisaties kunnen SPDX Lite gebruiken om gegevens uit te wisselen, aangezien het een verkorte versie is van de SPDX-standaard. De SPDX kreeg in augustus 5962 een officiële norm als ISO/IEC 2021.

spdx-document

SWID: Software-identificatietagging

De Internationale Organisatie voor Standaarden (ISO) begon vóór het einde van het decennium een ​​standaard op te zetten voor het markeren van softwarecomponenten met machinaal leesbare ID's. SWID-tags, zoals ze nu bekend staan, zijn gestructureerde, ingebedde metagegevens in software die informatie verzenden, zoals de naam van het softwareproduct, de versie, ontwikkelaars, relaties en meer. SWID-tags kunnen helpen bij het automatiseren van patchbeheer, validatie van software-integriteit, detectie van kwetsbaarheden en het toestaan ​​of verbieden van software-installaties, vergelijkbaar met het beheer van software-activa. In 2012 werd ISO/IEC 19770-2 bevestigd en in 2015 gewijzigd. Er zijn vier hoofdtypen SWID-tags die in verschillende stadia van de levenscyclus van softwareontwikkeling worden gebruikt:

1. Corpustags: Deze worden gebruikt om softwarecomponenten te identificeren en te karakteriseren die nog niet klaar zijn om te worden geïnstalleerd. Corpus-tags zijn “ontworpen om te worden gebruikt als input voor software-installatietools en -procedures”, aldus het National Institute of Standards and Technology.
2. Primaire tags: Het doel van een primaire tag is het identificeren en contextualiseren van software-items zodra ze zijn geïnstalleerd.
3. Patchtags: Patchtags identificeren en beschrijven de patch (in tegenstelling tot het kernproduct zelf). Patchtags kunnen ook contextuele informatie bevatten over de relatie van de patch met andere goederen of patches, en dat doen ze vaak ook.
4. Aanvullende tags: Met aanvullende tags kunnen softwaregebruikers en softwarebeheertools nuttige contextinformatie over lokale nutsvoorzieningen toevoegen, zoals licentiesleutels en contactgegevens voor relevante partijen.

Als het gaat om het bepalen welke tags en precieze gegevensstukken ze bij hun producten moeten aanbieden, hebben bedrijven veel speelruimte. Naast de verplichte gegevens specificeert de SWID-standaard een aantal optionele componenten en kenmerken. Ten slotte zijn slechts een paar kenmerken vereist die het softwareproduct kenmerken (zoals naam en tag-ID) en de entiteit die het heeft gegenereerd voor een geldige en compatibele tag.

CycloonDX

In 2017 heeft Stichting OWASP een release uitgebracht CycloonDX als onderdeel van Dependency-Track, een open-source analysetool voor softwarecomponenten. CycloneDX is een lichtgewicht standaard voor gebruik in meerdere sectoren, met gebruiksscenario's zoals detectie van kwetsbaarheden, naleving van licenties en beoordeling van oude componenten. CycloneDX 1.4 werd gelanceerd in januari 2022. Cyclone DX kan vier verschillende soorten gegevens verwerken:

• Metagegevens van het materiaalstroomschema: Het bevat informatie over de applicatie/product zelf, zoals de leverancier, fabrikant en componenten die in de SBOM worden beschreven, evenals eventuele tools die worden gebruikt om een ​​SBOM te maken.
• Componenten: Dit is een uitgebreide lijst van zowel bedrijfseigen als open-sourcecomponenten, samen met licentie-informatie.
• diensten: Eindpunt-URI's, authenticatievereisten en het doorlopen van vertrouwensgrenzen zijn allemaal voorbeelden van externe API's die software kan gebruiken.
• Bijgebouwen: omvatten zowel directe als indirecte verbindingen.

Bron: CycloonDX

Hoe ziet een SBOM eruit?

Voor risico-identificatie is een grondige en nauwkeurige inventarisatie van alle componenten van eigen en derde partijen vereist. Alle directe en transitieve componenten, evenals de afhankelijkheden daartussen, moeten in stuklijsten worden opgenomen. Met CycloneDX kunnen bijvoorbeeld de volgende typen componenten worden beschreven:

{ "bomFormat": "CycloneDX", "specVersion": "1.4", "serialNumber": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79", "version": 1, "components": [ { " type": "bibliotheek", "naam": "nacl-bibliotheek", "versie": "1.0.0" } ] }

XML-formaat:

 nacl-bibliotheek 1.0

Waarom uw SBOM ondertekenen?

Wat is een digitale handtekening?

A digitale handtekening is precies hoe het klinkt: een elektronische versie van de traditionele papieren en penhandtekening. Het controleert de geldigheid en integriteit van digitale communicatie en documenten met behulp van een geavanceerde wiskundige aanpak. Het zorgt ervoor dat er tijdens de verzending niet met de inhoud van een bericht wordt geknoeid, waardoor we het probleem van nabootsing van identiteit en manipulatie in digitale communicatie kunnen overwinnen. Digitale handtekeningen zijn in de loop van de tijd steeds populairder geworden en vormen een cryptografische standaard. 

Hoe digitale handtekeningen werken

Digitale handtekeningen worden gemaakt met behulp van cryptografie met publieke sleutels, ook wel asymmetrische cryptografie genoemd. Een publieke sleutelbenadering zoals RSA (Rivest-Shamir-Adleman) genereert twee sleutels, één privé en één openbaar, wat leidt tot een wiskundig gerelateerd paar sleutels. Een van de belangrijkste mechanismen achter digitale handtekeningen is hashing. Het transformeert gegevens effectief in uitvoer met een vaste grootte, ongeacht de grootte van de invoer. Dit gebeurt via hashfuncties, die in feite algoritmen zijn, en de output die ze produceren wordt een hashwaarde genoemd. Cryptografische hashfuncties genereren een hashwaarde die fungeert als een digitale vingerafdruk, waardoor deze voor iedereen uniek is. Net zoals de vingerafdruk van iedereen anders is, zullen verschillende invoerberichten verschillende hashwaarden genereren. De twee onderling authentiserende cryptografische sleutels van Public Key Cryptography (PKC) worden voornamelijk gebruikt voor digitale handtekeningen. De maker van de digitale handtekening gebruikt een privésleutel om handtekeninggerelateerde gegevens te coderen, en die gegevens kunnen alleen worden gedecodeerd met behulp van de openbare sleutel van de ondertekenaar. Zo weet een ontvanger dat de afzender niet is gecompromitteerd en dat de ontvangen gegevens correct zijn. Momenteel is het omgaan met openbare sleutelinfrastructuur kostbaar en ingewikkeld, omdat mensen dat vaak doen hun privésleutels verliezen alsof iemand zijn fysieke sleutels zou verliezen. Certificaatautoriteiten (CA's) fungeren als vertrouwde derde partijen en geven digitale handtekeningen uit door digitale certificaten te accepteren, verifiëren, uitgeven en onderhouden. CA's helpen voorkomen dat er valse digitale certificaten worden aangemaakt. Het valideert ook de vertrouwensdienstverlener (TSP). Een TSP is een persoon of rechtspersoon die namens een bedrijf digitale handtekeningen valideert en de resultaten van de validatie communiceert.

Voordelen van een digitaal ondertekende SBOM

Een ondertekende SBOM biedt een controlesom, een lange reeks letters en cijfers die de som vertegenwoordigen van de nauwkeurige cijfers van een stuk digitale gegevens en die kunnen worden vergeleken om fouten of wijzigingen te vinden. Een controlesom is vergelijkbaar met een digitale vingerafdruk. Er wordt regelmatig gecontroleerd op redundantie (CRC). Wijzigingen in ruwe gegevens in digitale netwerken en opslagapparaten worden gedetecteerd met behulp van een foutdetectiecode en verificatiefunctie. Omdat een digitale handtekening bedoeld is om te dienen als een gevalideerde en veilige manier om de authenticiteit van transacties te bewijzen – dat wil zeggen dat een persoon, eenmaal ondertekend, niet anders kan beweren – houdt deze alle ondertekenaars vast aan de procedures en acties die in het wetsvoorstel zijn vastgelegd. 

Problemen met een niet-ondertekende SBOM

Omdat verificatie een van de kerndoelen van digitale handtekeningen is, is een niet-ondertekende SBOM niet verifieerbaar. Zie het als een contract: als een contract niet is ondertekend door de deelnemende partijen, is er geen echte manier om het af te dwingen. Op dezelfde manier is een niet-ondertekende SBOM slechts een niet-ondertekend document: uw klant kan u niet ter verantwoording roepen.  Dit kan op termijn ook tot verdere problemen leiden, omdat een niet-ondertekende SBOM ook risico's kan opleveren voor de veiligheid van uw organisatie. Alles wat anders beschermd zou zijn door een ondertekende SBOM, is nu niet beschermd en daarom kunnen gegevens en informatie overal worden verzonden of gerepliceerd. Een van de hoofddoelen van ondertekende SBOM's – verantwoordelijkheid – gaat verloren wanneer een SBOM niet meer wordt ondertekend, omdat er dan wijzigingen in kunnen worden aangebracht zonder gevolgen van de kant van de maker of de klant. 

SBOM gebruiken om de cyberbeveiliging te verbeteren

SBOM’s behoren tot de beste manieren voor organisaties om de veiligheid en authenticiteit van hun gegevens en procedures te behouden. Ze scheppen ook een precedent in de branche door de openheid tussen ontwikkelaars, softwareleveranciers en klanten te vergroten. Organisaties kunnen partners tijdens het contractproces veilig op de hoogte stellen van operationele details als er standaarden zijn. Organisaties zullen succesvoller zijn in het identificeren van fouten, kwetsbaarheden en zero-day-bedreigingen naarmate SBOM’s wijdverspreider worden. De acceptatie van Software Bill of Materials is een duidelijke winst voor de beveiliging van de softwaretoeleveringsketen over de hele wereld.

Gebruik VEX om meer bruikbaarheid uit uw SBOM te halen

Vulnerability Exploitability eXchange (VEX) is een beveiligingsadvies gericht op het blootleggen van de exploiteerbaarheid van kwetsbaarheden in de context van het product waarin ze worden aangetroffen. Bij het uitvoeren van een kwetsbaarheidsscan op de meeste moderne applicaties kunnen de resultaten gemakkelijk in de honderden of duizenden kwetsbaarheden liggen. Van het totale aantal ontdekte kwetsbaarheden kan slechts ongeveer 5% daadwerkelijk worden misbruikt. Het is ook belangrijk om te onthouden dat exploiteerbaarheid bijna nooit een op zichzelf staand probleem is. Vaker wel dan niet is het een complex gebruik van open-sourcebibliotheken, modules en de code die deze gebruikt, die samenwerken en die een kwetsbaarheid omzetten in een feitelijk exploiteerbaar probleem. Totdat u uw applicatie wijzigt en een nieuwe SBOM uitvoert om deze te beschrijven, blijft de inventaris die in een stuklijst wordt beschreven doorgaans statisch. De informatie over kwetsbaarheden is veel dynamischer en aan verandering onderhevig. Als u uw VEX-informatie beschikbaar heeft als een zelfstandige lijst, kunt u VEX-gegevens bijwerken zonder dat u extra stuklijsten hoeft te genereren en beheren. CISA biedt een lijst van de aanbevolen minimale gegevenselementen die in een nuttig VEX-advies of -document moeten worden opgenomen. Dit zijn:

VEX-metagegevens: VEX-formaatidentificatie, identificatiereeks voor het VEX-document, auteur, auteursrol, tijdstempel. 

Productdetails: Product-ID('s) of Productfamilie-ID (bijv. unieke identificatie of een combinatie van de naam van de leverancier, de productnaam en de versiereeks, zoals uiteengezet in de vastgestelde SBOM-richtlijnen3). 

Kwetsbaarheidsdetails: Identificator van de kwetsbaarheid (CVE of andere identificatiegegevens) en beschrijving van de kwetsbaarheid (bijv. CVE-beschrijving). 

product Status Details (dwz statusinformatie over een kwetsbaarheid in dat product): 

• NIET BEÏNVLOED – Er is geen herstel vereist met betrekking tot dit beveiligingslek.
• BEÏNVLOED – Acties worden aanbevolen om deze kwetsbaarheid te herstellen of aan te pakken.
• OPGELOST – Deze productversies bevatten een oplossing voor het beveiligingslek. 
• IN ONDERZOEK – Het is nog niet bekend of deze productversies getroffen zijn door het beveiligingslek. Een update zal in een latere release worden verstrekt.

De uitdagingen van SBOM-adoptie overwinnen

Het integreren van SBOM in de softwareontwikkelingslevenscyclus (SDLC) van een organisatie brengt verschillende uitdagingen met zich mee. Ten eerste kan het genereren en onderhouden van nauwkeurige SBOM's tijdrovend en duur zijn, waardoor aanzienlijke investeringen in tools en processen nodig zijn. De uitdagingen van SBOM omvatten ook de integratie van SBOM-beheer met bestaande CI/CD-pijplijnen, wat mogelijk een stroomlijning van de CI/CD-pijplijnintegratie met zich meebrengt. Bovendien vereist het garanderen van de volledigheid en nauwkeurigheid van SBOM's het nauwgezet volgen van alle softwarecomponenten, inclusief afhankelijkheden van derden. Een andere belangrijke hindernis is het bevorderen van een cultuur van transparantie en veiligheidsbewustzijn onder ontwikkelingsteams, wat cruciaal is voor de succesvolle adoptie van SBOM-praktijken. Het overwinnen van deze SBOM-uitdagingen vereist een strategische aanpak, waarbij robuuste tools, effectieve training en een sterke organisatorische inzet worden gecombineerd om de beveiliging van de softwaretoeleveringsketen te verbeteren.

Samenvatting

Concluderend: hoewel SBOM's voor de meeste organisaties nog steeds een nieuw idee zijn, wordt verwacht dat de mogelijkheid om SBOM's te produceren in de toekomst belangrijker zal worden. Als u nog niet bent begonnen met het integreren van SBOM-creatie in uw softwareleveringsproces, is dit een goed moment om dat te doen.