Een Software Bill of Materials is niet langer slechts een ‘good-to-have’-documentatie voor organisaties. Het is nu om een groot aantal redenen een ‘must-have’. Afgezien van het feit dat federale regelgeving het openbaar maken van de componenten van uw software verplicht heeft gesteld, hebben softwarebedrijven zich nu gerealiseerd dat het opsommen van alle open-source en commerciële afhankelijkheden die in uw applicatie worden gebruikt, een nuttige cyberbeveiligingspraktijk is.
Interessant is dat, ondanks de erkenning van de noodzaak van een SBOM, het creëren ervan nog steeds een behoorlijke uitdaging kan zijn. Dat komt omdat het proces van het maken van de softwarestuklijst voor een product complex, vervelend en tijdrovend kan zijn. Omdat regelgevende instanties aanbevelen om voor elke iteratie van uw product een nauwkeurige en nauwkeurige SBOM te genereren, is het elke keer handmatig implementeren ervan behoorlijk arbeidsintensief, zo niet geheel onpraktisch.
Als het gaat om het implementeren van uitgebreide SBOM’s, wordt altijd de automatiseringsroute aanbevolen. Elke software is een ingewikkeld pakket dat bestaat uit meerdere afhankelijkheden die hoogstwaarschijnlijk ook hun eigen afhankelijkheden hebben. Dit betekent dat zelfs de eenvoudigste software honderden of zelfs duizenden afhankelijkheden kan hebben. Het zal veel werk vergen om deze allemaal samen te stellen en ze handmatig georganiseerd te houden. In dit artikel wordt uitgelegd waarom automatisering nodig is voor het implementeren van SBOM's en hoe u automatisering kunt implementeren om de stress te verminderen die gepaard gaat met het handmatig genereren van SBOM's.
Waarom het automatiseren van het SBOM-proces belangrijk is
Een softwarestuklijst is eenvoudigweg een lijst met de componenten van een softwareproduct (vergelijkbaar met een lijst met ingrediënten op een eetbaar product). Over het algemeen heeft u voor het maken van een softwarestuklijst alleen een spreadsheet nodig waarin deze componenten worden vermeld. Dit is echter een te grote vereenvoudiging die vrijwel nooit praktisch is. Een SBOM is een uitputtende lijst met een nauwkeurige set van de benodigde informatie. Het zal uiteraard tijdrovend en ingewikkeld zijn om deze lijst handmatig te verwerken.
Handmatige SBOM's zijn simpelweg niet voldoende. Daarom is automatisering van cruciaal belang bij het implementeren en verwerken van SBOM's. Naast de moeilijkheid om handmatige SBOM's te implementeren, zijn er ook risico's verbonden aan het handmatig maken van SBOM's, om nog maar te zwijgen van de nalevingsproblemen. Hier volgen enkele redenen waarom SBOM's het beste kunnen worden gemaakt met een geautomatiseerd systeem dat een uitgebreide lijst met software verzamelt en samenstelt en deze opslaat in een repository die voor mensen leesbaar en gemakkelijk te doorzoeken is.
Bedreigingen van de cybertoeleveringsketen
Het belangrijkste doel van het genereren van een uitgebreide SBOM is het beter begrijpen van softwarecomponenten en het analyseren van mogelijke kwetsbaarheden. Dit is een belangrijke cyberbeveiligingsmaatregel geworden om de bedreigingen voor elk softwareproduct te beperken. Een geautomatiseerde SBOM maakt het proces om dit te doen naadloos. Niet alleen is een geautomatiseerde Software Bill of Materials veiliger (dankzij cryptografische ondertekening en geautomatiseerde componentverificatie), maar automatisering zorgt er ook voor dat componenten continu worden gescand tijdens de integratie- en implementatiepijplijn van een software-iteratie.
Tijd BESPAREN
Het automatiseren van de SBOM-implementatie betekent dat u vertrouwt op geavanceerde tools die op machinesnelheid werken om uw softwarestuklijst te genereren. Dit bespaart u op meer dan één manier tijd. Ten eerste is het op deze manier genereren van een SBOM sneller dan handmatig proberen individuele componenten te identificeren en deze in een spreadsheet op te nemen.
Het automatiseren van SBOM’s maakt het detecteren van kwetsbaarheden ook eenvoudiger en sneller. Met handmatig samengestelde SBOM’s is het identificeren van de mogelijke locaties van kwetsbaarheden een pijnlijk lang proces.
Updates zijn ook sneller met SBOM's. Geautomatiseerde systemen voeren regelmatig controles uit op uw SBOM om kwetsbaarheden te identificeren op basis van nieuw bijgewerkte afhankelijkheden. Op deze manier kunt u risico's sneller beperken en uw tijd en middelen investeren in andere belangrijke taken, in plaats van tijd te verspillen aan het maken van SBOM's of het handmatig opvragen ervan.
NIST en federale vereisten
Het automatiseren van SBOMs is niet alleen nuttig, maar heeft ook regelgevend belang. Federale vereisten voor SBOM’s, zoals de Cyber Supply Chain Management and Transparency Act van 2014, bepalen dat automatische oplossingen en hulpmiddelen moeten worden gebruikt om SBOM’s te genereren.
Op dezelfde manier publiceerde de National Telecommunication and Information Administration (NTIA) in juli 2021 federaal goedgekeurde richtlijnen waarin de minimale elementen worden beschreven die voor elke SBOM moeten worden opgenomen. Ondersteuning voor automatisering werd vermeld in deze documentatie als een van de essentiële elementen van elke SBOM.
Volgens de NTIA moet de Software Bill of Materials leesbaar zijn voor mens en machine en automatisch kunnen worden gegenereerd. Het implementeren van een geautomatiseerde SBOM maakt het eenvoudiger om gegevens in het document bij te houden.
Spreadsheets zijn inefficiënt en foutgevoelig
Zoals eerder opgemerkt heeft elk softwarepakket honderden afhankelijkheden. Dit betekent dat er duizenden datapunten moeten worden behandeld in een typische softwarestuklijst. Spreadsheets zijn eenvoudigweg slecht toegerust om deze hoeveelheid gegevens te beheren. Door al deze gegevenspunten handmatig in te voeren, wordt de deur geopend voor menselijke fouten die ernstige gevolgen kunnen hebben als ze niet op tijd worden opgemerkt. De kans is groter dat u een nauwkeurige en uitgebreide SBOM genereert als u voor een geautomatiseerd systeem kiest.
Consistentie
Een groot voordeel van het automatiseren van het SBOM-generatieproces is dat het helpt om de consistentie in de hele CI/CD-pijplijn van de verschillende iteraties van een softwareproduct te behouden. Dit omvat alle wijzigingen die aan een product worden aangebracht terwijl het wordt gebouwd en zelfs nadat het is uitgebracht.
Een SBOM is niet statisch. Naarmate een product evolueert, worden er herzieningen aangebracht in de Software Bill of Materials om elke nieuwe toegevoegde afhankelijkheid vast te leggen. Deze wijzigingen moeten worden gecommuniceerd naar alle gebruikers en andere belanghebbenden, zowel intern als in de hele toeleveringsketen van de software. Het is belangrijk dat iedere stakeholder toegang heeft tot de laatste versie van een SBOM, maar ook tot alle eerdere versies van de software.
Met een handmatig opgestelde SBOM is het handhaven van consistentie en versiebeheer moeilijk, en dit kan tot botsingen en andere problemen leiden. Een geautomatiseerde SBOM zorgt ervoor dat de aangebrachte wijzigingen consistent zijn, en het is gemakkelijker om te zien wanneer en hoe deze wijzigingen zijn aangebracht. Met een handmatig systeem is dit lastig te realiseren.
Manieren om softwarestuklijsten te automatiseren
Regelgevingsnormen zoals de minimumvereisten van de NTIA voor SBOM bepalen specifieke formaten voor de Software Bill of Materials. Deze standaarden omvatten Software Package Data Exchange (SPDX) en CycloneDX. Softwarebeveiligingsteams moeten weten dat de aard van deze standaarden al impliceert dat SBOM's bedoeld zijn om geautomatiseerd te worden.
Elk softwarebeveiligingsteam moet dus zorgen voor het genereren en gebruiken van SBOM's door een geautomatiseerde stap toe te voegen die op een strategisch punt binnen hun ontwikkelingspijplijn moet worden uitgevoerd om de SBOM te genereren. Dit kan een open source-tool zijn voor het onderzoeken van softwarecomponenten nadat de build is voltooid, of een SCA-tool die is geïntegreerd in de continue ontwikkelingspijplijn van de software. De verschillende methoden voor het automatiseren van Software Bill of Materials worden hieronder toegelicht.
Gebruik een open source-tool
Een van de goedkoopste manieren om een softwarestuklijst te maken is het gebruik van een open source-tool. Ze zijn vrijwel gratis, maar bieden slechts rudimentaire functies. Er zijn verschillende open source tools die het SBOM-implementatieproces automatiseren. De rapporten die door de meeste van deze tools worden gegenereerd, worden echter slechts in twee formaten gegenereerd; CycloonDX en SPDX.
Een goed voorbeeld van een open-source SBOM-automatiseringstool is De SBOM-generator van Microsoft. Deze algemene build-timegenerator is gebouwd om bedrijven te helpen SBOM's voor hun softwarepakketten te genereren. De tool biedt platformonafhankelijke ondersteuning en genereert SBOM's in het standaard Software Package Data Exchange (SPDX)-formaat.
De SBOM-generator van Microsoft kan worden geïntegreerd in softwarepakketten die zijn gebouwd met NPM, PyPI, Maven, Rust Crates, Ruby Gems, Linux en NuGet-frameworks om de lijst met afhankelijkheden en componenten te genereren. Het kan ook worden geïntegreerd met openbare GitHub-opslagplaatsen.
De tool levert algemene informatie over de SBOM-documentatie zoals gespecificeerd in de SBOM-minimumvereisten. Het vermeldt ook alle bestanden en pakketten, samen met de relaties ertussen.
Gebruik een plug-intool
Een andere aanpak voor het automatisch genereren van SBOM's is om dit te doen binnen uw pijplijn voor continue integratie en continue implementatie (DevOps-pijplijn). U kunt dit doen met behulp van een Maven-plug-in die kan worden geïntegreerd in de bouwfase van uw workflow. Deze aanpak is een schaalbare en handige manier om het proces van het genereren van de softwarestuklijst direct binnen de pijplijn te automatiseren.
U zult merken dat dit een stuk eenvoudiger is, omdat u dit binnen de gebouwde omgeving van uw project doet. U hoeft slechts een paar argumenten door te geven om de SBOM automatisch te genereren. Voor de Maven-plug-in wordt de SBOM gegenereerd in Cyclone DX-formaat.
De Maven-plug-in kan een uitgebreide SBOM genereren die alle afhankelijkheden binnen uw project gedetailleerd beschrijft. Om dit te doen, moet u beginnen met het configureren van het bestand pom.xml voordat u de opdracht “mvn verificatie” uitvoert om de SBOM-bestanden te genereren. Er wordt eerst een bom.json-bestand gegenereerd vóór het SBOM-bestand.
De Maven-plug-in wordt geleverd met een ingebouwde SCA-tool die de gegenereerde SBOM-bestanden controleert op afhankelijkheden. Nadat het bestand is gecontroleerd, kunt u de SCA-tool een tweede keer uitvoeren om de softwarestuklijst opnieuw te genereren.
Een voorbeeld van zo'n plug-intool is de Schrijfplatform, waarmee softwareproducenten automatisch SBOM's kunnen genereren. Het gaat verder dan het genereren van SBOM's en helpt gebruikers hun SBOM's te beheren en ook te delen, de integriteit te valideren en kwetsbaarheden van hun containers, afhankelijkheden en pijplijnen te volgen. Hier is een eenvoudig overzicht van hoe Scribe werkt voor het automatiseren van het maken van SBOM's:
- Stap 1: Registreer en log (gratis) in op Scribe Hub. Gebruikers registreren en stellen hun projecten in via deze webinterface. Een aparte bewijsverzamelaar, die draait op MAC's en Linux-apparaten, genereert de SBOM zelf.
- Stap 2: Integreer Scribe met uw continue integratiepijplijn. Dit wordt bereikt door codefragmenten van de Scribe Hub toe te voegen aan uw continue integratiepijplijn en/of uw uiteindelijke build-image.
- Stap 3: Genereer en exporteer de softwarestuklijst. Er wordt een softwarestuklijst gegenereerd met behulp van de Scribe gensbom CLI-tool. De gegenereerde SBOM kan worden geëxporteerd in CycloneDX JSON-formaat.
Gebruik een tool voor compositieanalyse (SCA).
Een derde benadering voor het automatisch genereren van SBOM's voor uw softwareproduct is door gebruik te maken van een analysetool voor softwaresamenstelling van derden. Een SCA-tool analyseert uw product om componenten en licenties van derden binnen de software te identificeren. De tool beoordeelt de legitimiteit van de code en de naleving van licentievereisten.
SCA's scannen de broncode, binaire bestanden, containerafbeeldingen en manifestbestanden van een stuk software om de samenstelling ervan te bepalen en een overzicht te geven van alle open-sourcecomponenten die in de software zijn opgenomen. Als onderdeel van de SBOM zal een SCA deze componenten ook tegen verschillende databases uitvoeren om hun beveiligingsinformatie, licenties en bekende kwetsbaarheden te extraheren.
Een analysetool voor softwaresamenstelling automatiseert en versnelt het proces van het maken van SBOM's. De tool is ontworpen om in korte tijd duizenden datapunten te scannen om een Software Bill of Materials voor uw product samen te stellen. SCA-tools helpen u uw DevOps-pijplijn te beveiligen door volledig overzicht te bieden over de componenten van een softwarepakket en de herkomst van deze componenten.
Conclusie
Hoewel sommige bedrijven SBOM's alleen genereren omdat dit verplicht is gesteld door wettelijke vereisten, heeft de praktijk zichzelf bewezen als een noodzaak als het gaat om het beperken van bedreigingen voor de softwaretoeleveringsketen. Het automatiseren van het proces is zelfs nog belangrijker omdat het het vervelende, tijdrovende werk van het handmatig samenstellen van SBOM’s helpt verminderen. SBOM-automatisering, zoals benadrukt in elk van de technieken die in dit artikel worden behandeld, kan het proces voor het maken van SBOM's versnellen en ook nauwkeuriger en betrouwbaarder maken. Een plug-intool zoals Scribe maakt het mogelijk om het maken van SBOM's direct binnen de ontwikkelingspijplijn van uw software te automatiseren. Bekijk onze blog en andere bronnen om te zien hoe Scribe werkt voor het automatiseren van het genereren van SBOM en hoe u hiervan gebruik kunt maken.