Hoe u een SBOM op de juiste manier beheert

Sinds de recente toename van aanvallen op softwaretoeleveringsketens is het genereren van Software Bill of Materials (SBOM) een kernstap in de ontwikkeling geworden die teams moeten voltooien om software veilig te kunnen bouwen en verzenden. Een SBOM is een uitgebreide lijst met alle softwarecomponenten die in een softwareproduct worden gebruikt. Het doel van SBOM-beveiliging is het waarborgen van transparantie en traceerbaarheid binnen de softwaretoeleveringsketen, waardoor organisaties potentiële beveiligingskwetsbaarheden en compliancerisico's kunnen identificeren en corrigeren.

Maar het maken en beheren van een SBOM is een ingewikkeld karwei, vooral voor organisaties met een groot softwareportfolio. Het identificeren van alle softwarecomponenten die in een product worden gebruikt en het bijhouden van alle updates en patches, terwijl de nauwkeurigheid ervan wordt gewaarborgd, vereist een systematische aanpak.

In dit artikel bespreken we de best practices en strategieën voor het effectief beheren van een SBOM, de uitdagingen die gepaard gaan met SBOM-beheer en hoe u dit proces kunt vereenvoudigen om uw softwaretoeleveringsketen veilig te houden.

Wat is SBOM-beheer?

Het maken van een softwarestuklijst is slechts de eerste stap in het proces van het handhaven van de veiligheid van uw software. Maar het maken van een lijst met softwarecomponenten is niet voldoende; u moet uw SBOM bijhouden, valideren, bewerken en beheren. Hierdoor bent u er zeker van dat u niet alleen op de hoogte bent van de componenten van uw software, maar dat u daadwerkelijk alle risico's van de afzonderlijke componenten en hun impact op uw software begrijpt.

SBOM-beheer is het proces waarbij uw softwarestuklijst wordt gevolgd terwijl deze in uw DevOps-pijplijn wordt gegenereerd. Het beheren van uw SBOM omvat het genereren, opslaan, analyseren en monitoren van uw SBOM-documentatie. Door deze SBOM-beheertaken gedurende de gehele levenscyclus van uw app te voltooien, kunt u softwareafhankelijkheden identificeren en de beveiliging van uw toeleveringsketen verbeteren.

Uw SBOM heeft geen nut als deze inactief blijft in de build-directory waar deze is gegenereerd. SBOM-beheer helpt u deze gegevens te benutten, zodat u bruikbare inzichten kunt genereren en de open-sourcecomponenten van uw softwarepakket en hun impact op de softwaretoeleveringsketen beter kunt begrijpen. Het scannen en rapporteren van kwetsbaarheden zijn ook aspecten van SBOM-beheer.

Dus hoewel het genereren van de Software Bills of Material een belangrijk onderdeel is van het DevOps-proces, is het continue proces van SBOM-beheer zelfs nog belangrijker. Hiermee kunt u systemen voor het opwarmen van kwetsbaarheden, een zero-trust-beleid en software-supply chain-intelligentie voor de lange termijn volledig benutten en implementeren.

Inzichten in SBOM-beheer

Om gelijke tred te houden met het toenemende aantal bedreigingen voor verschillende software in de toeleveringsketen, voorspelt Gartner dat tot 60% van de organisaties die afhankelijk zijn van software als kritieke infrastructuur de komende jaren het gebruik van SBOM's gaat verplichten. Dit blijkt uit Gartners Innovation Insight Report 2022 over SBOM die essentiële informatie biedt over het belang van de implementatie van een SBOM-managementprogramma.

Het rapport erkent het belang van SBOM-cyberbeveiliging voor het verbeteren van de zichtbaarheid, integriteit, transparantie en veiligheid van codes die worden gebruikt in softwaretoeleveringsketens. Zonder de componenten van de software te kennen, is het moeilijk om de omvang van de risico's en kwetsbaarheden van deze software te begrijpen. De beste oplossing is om eenvoudigweg alle software in een applicatie te volgen en deze te vergelijken met een database met bekende kwetsbaarheden om er zeker van te zijn dat ze veilig zijn.

Volgens het Gartner-rapport zou elke organisatie moeten investeren in het genereren van een SBOM voor elk softwarepakket dat ze bouwen. Vervolgens moeten ze de SBOM verifiëren van alle software die ze gebruiken. Er is ook behoefte aan continu SBOM-beheer, zodat ze de gegevens opnieuw kunnen beoordelen om nieuwe beveiligingsrisico's te begrijpen, zelfs nadat de app is geïmplementeerd.

Strategieën voor effectief beheer van softwarestuklijsten

Organisaties kunnen de veiligheid en compliance garanderen van de software die zij bouwen of gebruiken door prioriteit te geven aan SBOM-beheer. Hieronder volgen enkele strategieën voor het effectief beheren van de softwarestuklijst van een organisatie. 

Automatiseer het genereren van SBOM's

Voor elke iteratie van uw software moet een Software Bill of Material worden opgesteld. Maar ontwikkelaars zullen dit moeilijk kunnen bereiken als ze voor elke build handmatig SBOM's moeten genereren. Dit is waarom SBOM-generatie moet in uw softwareleveringspijplijn worden ingebouwd. Automatisering maakt het mogelijk om “machinesnelheid” te bereiken voor het genereren van SBOM, zoals aanbevolen door de National Telecommunications and Information Administration (NTIA). 

SBOM-automatisering verhoogt ook de integriteit en betrouwbaarheid van uw SBOM-documentatie. Geautomatiseerde SBOM's die binnen de ontwikkelingspijplijn worden gegenereerd, kunnen cryptografisch worden ondertekend, wat voor gebruikers bewijst dat de lijst met softwarecomponenten in de SBOM authentiek is.

Gestructureerde opmaak

Alle gegevens die in uw Software Bill of Materials-beheer worden gepresenteerd, moeten worden gestructureerd op basis van een standaardformaat. Hoewel er nog verschillende andere zijn, zijn SPDX, SWID en CycloneDX drie van de meest populaire formaten. Omdat er geen officiële SBOM-aanbeveling of algemene branchebrede standaard bestaat, mag elke organisatie kiezen welk formaat het beste voor hen werkt. De belangrijkste factor hierbij is consistentie, ongeacht het SBOM-formaat dat u kiest.

Bied SBOM's aan voor SaaS

Als het gaat om het implementeren van cyberbeveiligingsmaatregelen voor software, richten organisaties zich vaak op apps of software die ze zelf in de cloud of on-premise implementeren, terwijl SaaS-apps die ze gebruiken worden genegeerd.

Het wordt echter ook aanbevolen om SBOM's aan te bieden voor deze Software as a Service-apps. Klanten in een SaaS-model hoeven zelf geen software-updates of nieuwe releases te beheren. In het geval dat de SaaS-applicatie van een klant echter in gevaar komt als gevolg van een kwetsbaarheid, kan het verstrekken van SBOM's voor de applicatie dienen als een vroege waarschuwing die ook kan bijdragen aan de eigen cybersecuritymaatregelen. 

Regelmatige updates voor elke release

Om het meest effectief te zijn, moeten SBOM's versiespecifiek zijn; ontwikkelaars moeten de SBOM herzien wanneer ze een update voor hun applicatie uitrollen. Het is gemakkelijk voor ontwikkelaars om in de val te trappen door één keer een SBOM te maken en deze zo nu en dan te upgraden, vanwege de moeilijkheid om deze tussen releases handmatig bij te werken. Bedrijven moeten ervoor zorgen dat hun Software Bill of Materials-beheer onmiddellijk wordt bijgewerkt wanneer er een nieuwe versie van hun software beschikbaar is. Dit is nog een reden waarom het automatiseren van het genereren van SBOM belangrijk is, omdat het het gemakkelijker maakt om elke keer dat u een update vrijgeeft een bijgewerkte versie van uw SBOM te genereren.

Creëer duidelijke communicatiekanalen

Bij het SBOM-management zijn meerdere stakeholders betrokken die op één of andere manier met het softwareproduct verbonden zijn. Dit omvat softwareleveranciers, ontwikkelingsteams, klanten en anderen. Een van de manieren om effectief SBOM-beheer te garanderen, is het opzetten van duidelijke communicatiekanalen tussen deze belanghebbenden. Dit zorgt ervoor dat iedereen toegang krijgt tot alle nieuwe informatie over de softwarecomponenten in een product en indien nodig updates kan implementeren

Metagegevens opnemen

De hoeveelheid metagegevens (aanvullende informatie zoals licentiegegevens en patchstatus) die u in uw SBOM-documentatie moet opnemen, is afhankelijk van het formaat dat u gebruikt. Hoewel sommige formaten standaard meer metadata ondersteunen dan andere, moeten ontwikkelaars prioriteit geven aan het toevoegen van zoveel mogelijk metadata aan hun SBOM. Deze aanvullende informatie maakt SBOM-beheer eenvoudiger voor gebruikers, omdat ze deze stukjes informatie niet elke keer handmatig hoeven op te zoeken als ze deze nodig hebben. De metagegevens maken het ook gemakkelijker om kwetsbare componenten in uw producten te identificeren en bij te werken wanneer er een beveiligingsfout wordt aangekondigd.

SBOM-beheeruitdagingen

Ondanks de wijdverbreide adoptie van SBOM blijven veel aspecten van SBOM-beheer een uitdaging voor gebruikers. Misschien wel de grootste uitdaging van allemaal is het gebrek aan standaardisatie in SBOM-formattering in de hele sector. Hoewel het vasthouden aan dezelfde standaard voor het maken en delen van SBOM de beste waarde voor iedereen garandeert, zal het een tijdje duren voordat consensus kan worden bereikt.

Een andere uitdaging is de noodzaak om SBOM’s actueel en relevant te houden. De software die door de meeste organisaties wordt gemaakt, is dynamisch. Dit betekent dat er periodiek updates worden uitgebracht en dat er nieuwe componenten worden toegevoegd. Om relevant en veilig in gebruik te blijven, moet de Software Bill of Materials bij elke nieuwe release van de software worden bijgewerkt. Elke organisatie moet plannen maken voor het genereren en beheren van SBOM-tools, zodat ze bij elke nieuwe release van hun software naadloos nieuwe SBOM kunnen uitbrengen.

En dan is er nog het risico van onnauwkeurigheden of weglatingen binnen de SBOM, wat kan leiden tot blootstelling aan kwetsbaarheden en complianceproblemen. Sommige SBOM-generatietools slagen er niet in om onbewerkte code of binaire bestanden te documenteren die door ontwikkelaars in hun broncode zijn opgenomen. SBOM's die op deze manier worden gegenereerd, creëren een vals gevoel van volledigheid, waardoor ze onveilig zijn. Voor de veiligheid en transparantie moet uw SBOM zeer gedetailleerd zijn, waarbij zoveel mogelijk componenten worden vermeld en optimaal hiërarchische informatie wordt verstrekt om de relatie tussen deze componenten weer te geven.

Ten slotte bestaat het risico dat de beveiliging van de SBOM zelf wordt beheerd, omdat deze gevoelige informatie bevat over softwarecomponenten die tijdens het ontwikkelingsproces worden gebruikt, inclusief potentiële beveiligingsproblemen. Daarom moeten organisaties maatregelen nemen om de SBOM te beschermen tegen ongeoorloofde toegang of openbaarmaking.

Samenvatting 

Ter afsluiting is het van cruciaal belang om het belang van een goed beheer van een softwarestuklijst te benadrukken voor elke organisatie die softwareproducten maakt of gebruikt. Naast het creëren van een SBOM helpt het implementeren van effectieve SBOM-beheerpraktijken een bedrijf om zijn softwareproducten veilig te houden en te voldoen aan de relevante regelgeving.

Enkele van de belangrijkste componenten van een effectief SBOM-beheerframework zijn onder meer het bijhouden van een uitgebreide inventaris van uw softwarecomponenten, het plannen van regelmatige updates, het indien nodig uitvoeren van risicobeoordelingen en het automatiseren van het genereren en beheren van SBOM.

Door zich aan deze best practices te houden, kan een organisatie een veel dieper inzicht krijgen in haar softwaretoeleveringsketens, waardoor het risico op beveiligingsinbreuken wordt geminimaliseerd en andere potentiële problemen worden vermeden. Uiteindelijk zal effectief SBOM-beheer u helpen veilige en betrouwbaardere softwareproducten te bouwen die voldoen aan de behoeften van uw klanten en alle belanghebbenden.