Als we iets hebben geleerd van enkele van de grote software supply chain-aanvallen van de afgelopen jaren, zoals de SolarWinds en Log4Shell aanval, het is dat dit soort aanvallen behoorlijk verwoestend kunnen zijn. Maar in de huidige onderling verbonden digitale wereld wordt het voor bedrijven steeds moeilijker om ze te vermijden.
Niemand is immuun voor aanvallen op de softwaretoevoerketen. Wat deze nog erger maakt, is dat het binnendringen van een enkel bedrijf potentieel duizenden bedrijven in hun softwaretoeleveringsketen kan blootstellen aan aanvallen. De implicatie hiervan is dat het niet voldoende is om uw eigen interne systemen te beschermen; Een van de manieren waarop uw organisatie de risico's in de toeleveringsketen proactief kan verminderen en aanvallen kan beperken, is het adopteren van een concept dat bekend staat als de Software Bill of Materials (SBOM).
Uw organisatie is waarschijnlijk afhankelijk van verschillende externe systemen om verschillende aspecten van uw dagelijkse activiteiten uit te voeren. U heeft echter waarschijnlijk geen inzicht in de risico’s die deze externe systemen met zich meebrengen, tenzij de aanbieder dit openbaar maakt. De SBOM fungeert als een uitgebreide ingrediëntenlijst die inzicht geeft in de samenstelling van de softwarecomponenten die u gebruikt. Dit document is een sleutelcomponent voor het beheersen van de risico's van aanvallen op de toeleveringsketen.
Wat is de functie van SBOM bij supply chain risicomanagement?
Om het potentieel volledig te begrijpen en de risico's te verminderen van de software van derden die u gebruikt, moet u de samenstelling ervan kennen. De Software Bill of Materials (SBOM) biedt volledige transparantie, waardoor u betere controle krijgt over de beveiliging van uw interne systemen.
Een Software Bill of Materials is een lijst met de componenten, services en afhankelijkheden van derden in een stuk software of applicatie. Het concept van BOM is niet nieuw, maar heeft pas onlangs toepassing gevonden in de softwarewereld. De oorsprong van dit concept is terug te voeren op de productie-industrie, waar fabrikanten doorgaans onderdelen van verschillende leveranciers gebruiken om een product te bouwen. Om de geschiedenis van het product bij te houden en toekomstig onderhoud te vergemakkelijken, wordt een stuklijst opgesteld waarin alle componenten worden beschreven en waar ze allemaal vandaan komen.
SBOM’s werden recentelijk populairder na de Solarwinds-aanval van 2020, waarbij veel Amerikaanse overheidsinstanties werden getroffen. Als reactie hierop heeft President Biden heeft een uitvoerend bevel uitgevaardigd die federale agentschappen de opdracht gaf om hierom te vragen SBOM van softwareontwikkelaars en de leveranciers waarmee ze samenwerken. Hoewel het een supply chain-aanval niet kan voorkomen, zal een nauwkeurige SBOM alle afhankelijkheden binnen een softwareproduct onthullen. Dit maakt het tot een waardevol cyberbeveiligingsinstrument dat transparantie garandeert en kwetsbaarheden in de toeleveringsketen blootlegt, waardoor de risico's in de toeleveringsketen kunnen worden verminderd.
Waarom SBOM van cruciaal belang is voor ontwikkelaars die afhankelijk zijn van open source-code
Hergebruik van code van derden of open source-code is een integraal onderdeel van het moderne softwareontwikkelingsproces. Hoewel ontwikkelaars nog steeds hun eigen code moeten schrijven, integreren ze routinematig open source-componenten van derden in hun software. Dit is heel noodzakelijk geworden om projecten in een hoog tempo te laten verlopen.
In het verleden was de enige reden waarom organisaties en ontwikkelaars die open-sourcesoftware gebruiken meer wilden weten over de componenten ervan, om licentieproblemen te voorkomen. Veel open source-software bevatte componenten met beperkt gebruik en beperkte distributie, en iedereen die er gebruik van wilde maken, moest zich van deze beperkingen bewust zijn. Nu beginnen ontwikkelaars echter in te zien dat het risico van het gebruik van open-sourcesoftware verder gaat dan licentieverlening; het zou ook veiligheidsproblemen kunnen oproepen. Een stuklijst is een integraal onderdeel van het begrijpen van zowel de licentie- als de beveiligingsvereisten van open-sourcesoftware.
Voor ontwikkelaars biedt een Software Bill of Materials beter inzicht in de codebasis van de open-sourcesoftware die ze gebruiken. Dit kan in veel gevallen tijd en moeite besparen. Bijvoorbeeld als er een nieuwe kwetsbaarheid wordt ontdekt. Zonder een stuklijst zullen ontwikkelaars elk stukje software moeten beoordelen om de oorzaak van het probleem te identificeren. Voor complexe projecten is dit een slopende en tijdrovende klus. Met behulp van een SBOM kan de software waarin de kwetsbaarheid zich bevindt eenvoudig worden geïdentificeerd en wordt de benodigde bugfix direct uitgevoerd. Andere redenen waarom SBOM is van cruciaal belang bij softwareontwikkeling:
-
Verminder de opgeblazen code—Voor elke open source-code die u gebruikt, zijn er waarschijnlijk tientallen enigszins verschillende alternatieven die vergelijkbare functies uitvoeren. Met een SBOM kunt u redundanties verminderen door een standaardlijst met componenten voor uw systeem te maken. Omdat elk onderdeel dat u gebruikt zijn eigen unieke defecten of kwetsbaarheden heeft, kan het eenvoudiger worden om kwetsbaarheden op te sporen en te corrigeren als u uw code gestroomlijnd houdt tot precies wat nodig is.
-
Voldoe aan de licentieverplichtingen—We hebben gezegd dat licenties een van de belangrijkste motivaties zijn om alle componenten van uw software te leren kennen. Door de SBOM te verkrijgen, weet u zeker dat u voldoet aan alle licentieverplichtingen voor de componenten die u wilt gebruiken.
-
Risico's proactief evalueren en verhelpen:Het identificeren en verhelpen van nieuw geïdentificeerde risico's kan moeilijk en tijdrovend zijn. Met een duidelijk omschreven lijst met componenten kunt u echter proactief op zoek gaan naar kwetsbaarheden en deze oplossen. Dit verkort de tijd voor het identificeren van problemen en maakt het proces efficiënter.
-
Het maakt testen en codebeoordelingen eenvoudiger:Voordat software wordt uitgerold, moet deze uitgebreid worden getest en beoordeeld. Dit proces is eenvoudiger wanneer de ontwikkelaar een duidelijk inzicht heeft in alle componenten en subcomponenten van die software. De SBOM kan helpen de revisietijd drastisch te verkorten, waardoor u uw code sneller in productie kunt nemen dan u zonder het document zou hebben gedaan.
Met behulp van de SBOM kunt u beveiligingstests starten om schadelijke componenten in een vroeg stadium te detecteren en te voorkomen, terwijl uw code nog wordt geschreven. Het document biedt ook een diepere context voor codes van derden en hun componenten, waardoor het werk en de tijd die nodig is om de codebasis te beoordelen en zelfs te wijzigen worden verminderd.
-
Identificeer end-of-life (EOL) software:Dit is een vrij algemeen verschijnsel bij open-sourcesoftware. Soms bereiken deze componenten het einde van hun levensduur omdat de leverancier, hogerop in de supply chain, het product niet langer ondersteunt. Hoewel het nog steeds werkt, zijn niet-ondersteunde open-sourcesoftware belangrijke knooppunten waarmee kwetsbaarheden kunnen worden uitgebuit. De SBOM maakt het mogelijk om EOL-software te monitoren en proactief stappen te ondernemen om deze waar mogelijk te vervangen.
SBOM-gebruiksscenario's en voordelen
Het verkrijgen van een Software Bill of Materials (SBOM) is niet verplicht voor elke software die u ontwikkelt. Het voorbereiden ervan is echter hard op weg een best practice te worden waar elke digitale productontwikkelaar naar moet kijken. Hieronder volgen enkele SBOM-gebruiksscenario's waarbij dit document zeer waardevol zou zijn.
SBOM-gebruikscasussen
Voldoen aan federale vereisten
Na de grote aanvallen op de softwaretoeleveringsketen van 2020 en 2021 heeft president Biden een bevel uitgevaardigd uitvoerende orde waarin belangrijke aanbevelingen worden geschetst voor instanties en leveranciers die softwareoplossingen voor de overheid leveren. Een van de vereisten in het uitvoeringsbesluit was het voorstel om SBOM's op te nemen voor elke software die door de federale overheid zou worden gebruikt. Hoewel SBOM's niet voor iedereen verplicht zijn, zouden alle organisaties die software leveren voor de Amerikaanse federale overheid SBOM's moeten leveren waarin alle componenten die ze gebruiken en eventuele versiewijzigingen die ze aanbrengen, worden beschreven.
Risico's voor softwareconsumenten verminderen
Een SBOM geeft volledig inzicht in de componenten van een softwaretool van derden. Het volgen van alle componenten en subcomponenten van software is een van de manieren waarop organisaties de beveiligings- en compliancenormen kunnen verifiëren van elke softwareoplossing die ze willen gebruiken of al gebruiken.
Consumenten die software gebruiken zonder een stuklijst zijn zich er waarschijnlijk van bewust dat er open source-componenten zitten in de code die ze van een leverancier krijgen. Omdat deze ingrediënten echter niet bekend zijn, zijn consumenten zich mogelijk niet bewust van mogelijke kwaadaardige code, niet-ondersteunde componenten en andere kwetsbaarheden in de software.
Snelle reactie op crisissituaties
Het gebruik van een SBOM biedt inzicht in de softwarecodebase. Uiteindelijk maakt dit het voor ontwikkelaars gemakkelijker om op crises te reageren als deze zich toch voordoen. Zonder een SBOM zal een software-engineeringteam dat een nieuwe kwetsbaarheid probeert aan te pakken, bijvoorbeeld elk stukje software dat ze gebruiken handmatig moeten beoordelen om het probleem vast te stellen. Als er echter een stuklijst beschikbaar is, is het eenvoudiger om de software die het beveiligingslek kan bevatten te identificeren en de vereiste reparaties binnen zeer korte tijd uit te voeren. Dit helpt tijd te besparen bij het oplossen van crises en minimaliseert de schade die had kunnen optreden.
Problemen met informatieasymmetrie
Er is momenteel sprake van een informatie-asymmetrieprobleem op de softwaremarkt. Door de volledige informatie over de beveiliging van hun app geheim te houden, worden softwareleveranciers of -producenten niet verantwoordelijk gehouden voor de kwaliteit van hun software. SBOM stelt informatie over de beveiliging van een product beschikbaar aan softwareklanten. Dit dwingt producenten om te voldoen aan de beste beveiligingsnormen bij softwareontwikkeling.
Begeleiden van fusies en overnames
Een Software Bill of Materials is een van de documenten die nodig kunnen zijn voor de overname van een bedrijf. Bij onderdelen van het proces van een bedrijfsovername gaat het om due diligence om de potentiële risico's van de aankoop in te schatten. SBOM's bieden diepgaande inzichten in het beveiligingskader van het bedrijf en het potentiële risico van de overname.
Voordelen van SBOM's
Een van de belangrijkste beveiligingspraktijken van de moderne organisatie is het toegang krijgen tot de risico's van de softwaretoeleveringsketen. Dit houdt in dat we moeten weten of de softwarestack van een organisatie onderdelen van derden bevat die een risico voor de toeleveringsketen kunnen vormen. Deze softwarekwetsbaarheden worden vaak aangetroffen in componenten die afhankelijk zijn van andere softwareapplicaties. Dit is de reden waarom de Software Bill of Materials een belangrijk onderdeel is van een productbeveiligingsframework. Hieronder staan enkele van de belangrijkste voordelen van SBOM.
- Ga proactief om met kwetsbaarheden-Het uiteindelijke voordeel van een SBOM is het doorlichten van het beveiligingsframework van de software die een organisatie gebruikt, het identificeren van kwetsbaarheden en het vinden van manieren om deze proactief te elimineren. Door dit te doen, kunnen organisaties de risico's in de toeleveringsketen verminderen.
- Verbeter het proces van het beheersen van veiligheidscrises:Het maken van een SBOM verwijdert geen systeemkwetsbaarheden en voorkomt geen aanvallen op de softwaretoevoerketen volledig. Het vermindert echter de risico's in de toeleveringsketen en kan het proces van het beheersen van crises verbeteren wanneer deze zich toch voordoen. Het hebben van een lijst met alle afhankelijkheden die kunnen dienen als een potentieel punt van kwetsbaarheid in een softwareapplicatie vereenvoudigt het proces van risicobeheer.
- Kosten verlagen-Een van de gevolgen van het omgaan met beveiligingsrisico's door gebruik te maken van SBOM's is dat dit op de lange termijn de kosten verlaagt. Het proces van het handmatig parseren van code om kwetsbaarheden te lokaliseren kan behoorlijk kostbaar zijn. De Software Bill of Materials biedt inzicht in de onderliggende software van bibliotheken. Dit helpt tijd te besparen en de kosten van de beveiligingsbeoordeling te verlagen.
Conclusie
In elke softwareorganisatie die haar reputatie serieus neemt, is het creëren van een alomvattende SBOM die voortdurend wordt bijgewerkt met gegevens een van de belangrijkste manieren om de gevolgen van een software supply chain-aanval te voorkomen. Omdat het gebruik van software van derden vrijwel onvermijdelijk is bij het bouwen van softwareproducten, zal het hebben van een uitgebreide ingrediëntenlijst van alle componenten die u gebruikt het aanzienlijk eenvoudiger maken om problemen te beperken en ze effectiever op te lossen. Het maakt het ook gemakkelijker om te voldoen aan problemen met softwarelicenties en, in sommige gevallen, zelfs aan overheidsvoorschriften.