Er is de afgelopen jaren veel geschreven over de SBOM – Softwarestuklijst. Door al deze bekendheid hebben mensen het gevoel dat ze goed genoeg weten wat het is om uit te leggen: het is een lijst met software-ingrediënten, het is belangrijk voor transparantie en veiligheid, en het helpt voorbijgaande afhankelijkheden bloot te leggen. Dit is allemaal waar.
Toch is de SBOM niet zo eenduidig als het lijkt. Bedenk allereerst dat om up-to-date te blijven, voor elke nieuwe bibliotheekversie of patch een nieuwe SBOM moet worden uitgebracht. Vaak verander of patch je slechts één of twee bibliotheken tegelijk, zodat je gewoon hun nieuwe ingrediënten kunt opsplitsen, die aan de SBOM kunt toevoegen en al het andere hetzelfde kunt laten, toch?
En hoe zit het met het concept van het 'bekende-onbekende'? Als de ontwikkelaars weten dat ze iets missen, kunnen ze het invoeren als 'bekend-onbekend' en de lege plekken later (of helemaal niet) invullen.
Er zijn ook softwareartefacten die zeer complex zijn en meerdere in elkaar grijpende elementen bevatten, die elk op zichzelf een softwareartefact zijn. Elk element heeft vaak zijn eigen, afzonderlijke SBOM, en de hele build kan een grotere, geaggregeerde SBOM hebben.
Dit alles laat zien dat je in plaats van een duidelijk, eenvoudig SBOM-bestand een groot aantal verschillende, steeds veranderende elementen kunt krijgen die je voortdurend zo up-to-date mogelijk moet houden.
Dit is allemaal leuk en aardig, maar wat voor verschil zou het voor iemand maken als een SBOM of een deel van een SBOM niet zo nauwkeurig of actueel is als het zou kunnen zijn? Wat kunnen we doen om zowel de herkomst als de nauwkeurigheid van de SBOM te behouden?
In dit artikel onderzoeken we het gebruik van de SBOM bij kwetsbaarheidsscans en het openbaar maken van kwetsbaarheden. We zullen het hebben over cryptografische ondertekening en zien hoe het ondertekenen van een SBOM, of delen daarvan, deze nuttiger maakt als hulpmiddel voor beveiliging en transparantie. We zullen ook praten over metagegevens en waarom deze zo belangrijk zijn bij de productie van SBOM en andere artefacten, vooral wanneer deze cryptografisch zijn ondertekend in een attest.
Begin hier: wat is cryptografische ondertekening eigenlijk?
Cryptografische handtekeningen worden gebruikt om de integriteit en nauwkeurigheid van digitale bestanden of mappen te verifiëren. Er kan niet met een ondertekend bestand worden geknoeid zonder dat de handtekening ongeldig wordt. Het bestand wordt dus onmiddellijk ontdekt zodra iemand het ondertekende document probeert te verifiëren.
Dat maakt digitale handtekeningen tot een onschatbaar hulpmiddel in het arsenaal van de software beveiliging industrie en er zijn al talloze toepassingen gevonden voor het eenvoudige concept van digitale of cryptografische ondertekening van digitale activa.
Hoe werkt het? Digitale handtekeningen zijn gebaseerd op asymmetrische cryptografie waarbij een entiteit twee sleutels heeft: een privésleutel en een publieke sleutel. De twee sleutels zijn op zo'n manier met elkaar verbonden dat een document dat is ondertekend met iemands privésleutel kan worden geverifieerd met behulp van iemands openbare sleutel. Een verificatie zou zowel betekenen dat er op geen enkele manier met het document zou zijn geknoeid (zelfs de wijziging van een enkele bit zou de handtekening oncontroleerbaar maken), als dat de identiteit van de ondertekenaar zou worden bewezen, of op zijn minst de identiteit van de gebruikte sleutel.
Wat doe je met die SBOM?
SBOM's zijn niet alleen lange, ingewikkelde bestanden met informatie over softwarecomponenten. Ze vormen uw toegangspoort om precies te weten uit welke componenten uw software-artefact bestaat. U moet de volledige componentenlijst kennen, want ook al denkt u misschien dat u precies weet wat u hebt opgenomen, de kans is groot dat u met elke toegevoegde bibliotheek talloze verborgen en voorbijgaande afhankelijkheden heeft toegevoegd, die elk een drager kunnen zijn van een kwetsbaarheid of misbruik daarvan. is nu opgenomen in de software die u naar uw klanten verzendt.
Zodra u een SBOM en de volledige lijst met ingrediënten heeft, kunt u die lijst scannen op basis van bekende kwetsbaarheidsdatabases en zien welke kwetsbaarheden in uw software zijn opgenomen. Maar dat is nog maar het begin. Zoals iedereen die ooit een kwetsbaarheidsscan heeft uitgevoerd weet, kunnen de resultaten van zelfs een eenvoudige artefactscan gemakkelijk in de honderden (of meer) kwetsbaarheden liggen.
Dat is waar het harde werk begint, bij het in kaart brengen van elke kwetsbaarheid, kijken of deze mogelijk exploiteerbaar is in uw specifieke softwaresamenstelling, het documenteren van die informatie en het omgaan met de exploiteerbare kwetsbaarheden door ze te patchen en te herstellen, bij voorkeur in volgorde van het gevaar dat ze vertegenwoordigen (live). exploits in het wild zijn gevaarlijker dan een theoretische exploit die nog nooit heeft plaatsgevonden).
Al dit werk en het documenteren en herstellen van kwetsbaarheden is belangrijk voor u als softwareproducent, maar ook voor uw klanten, uw partners en potentiële auditors.
Ze willen weten dat u op de hoogte bent van potentiële kwetsbaarheden en dat u er bovenop zit en fouten herstelt en corrigeert, zodat deze geen gevolgen hebben voor HEN als uw klanten of partners.
Omdat het tijdstip waarop u een scan uitvoert in dit opzicht belangrijk is vanwege het feit dat er voortdurend nieuwe kwetsbaarheden aan het licht komen, is het ondertekenen van uw SBOM samen met de metadata van WANNEER deze is gemaakt een geweldige manier om te laten zien dat u echt bovenaan staat. van uw kwetsbaarheidslijst.
Zo kun je bewijzen dat je vooraf op de hoogte was van een kwetsbaarheid en dat deze niet relevant is (met behulp van een VEX adviserend), dat het niet aanwezig is in een bepaalde versie, of dat het niet eens bestond op het moment dat u uw laatste versie uitbracht.
Waar moet ik tekenen?
Laten we nu dat eenvoudige ingrediëntenlijstbestand vervangen door een van de complexere gebruiksscenario's die in het begin van het artikel worden beschreven. Zodra u meerdere SBOM's hebt gecombineerd om een grotere, geaggregeerde versie te vormen om uw volledige artefact te beschrijven, wordt het ondertekenen en verifiëren van elk afzonderlijk onderdeel van die geaggregeerde versie steeds belangrijker. Stel dat u een nieuwe versie van een complex softwareartefact bouwt. In deze nieuwe versie is het enige dat is veranderd deel 1 van een driedelig artefact. De andere twee delen blijven precies hetzelfde. Waarom zou u tijd en middelen verspillen aan het bouwen van de volledige driedelige SBOM, het scannen van alle drie op kwetsbaarheden en het in kaart brengen van alle drie op relevante exploits? De enige wijzigingen waren in deel 3, dus dat is de enige waarin je het werk moet plaatsen. Als je alle drie de SBOM's en kwetsbaarheidsscans hebt ondertekend de laatste keer dat je ze hebt gemaakt, kun je de informatie van de andere twee delen opnemen in de wetenschap dat dit mogelijk is. t zijn gewijzigd. U kunt dan op ieder moment aantonen dat de SBOM’s voor deel 3 en 3 identiek zijn aan de originele versies. U kunt de scans uiteraard opnieuw uitvoeren als u zich zorgen maakt over nieuwe kwetsbaarheden, maar dat is geheel aan u en uw software risicoanalyse.
Het is om tal van redenen nuttig om aan uw klanten, partners en auditors te kunnen bewijzen wanneer en hoe vaak u SBOM's hebt gemaakt en deze hebt gescand op kwetsbaarheden. Niet in de laatste plaats kan het in de rechtszaal worden gebruikt om te bewijzen dat u niet aansprakelijk bent voor de schade die voortvloeit uit een exploit, aangezien u alles hebt gedaan wat nodig was om beschermd te worden, waardoor u een veilige haven.
Waar te gaan vanaf hier
Zoals we eerder hebben aangegeven, is een van de problemen bij het digitaal ondertekenen van softwareartefacten of bestanden het gedoe van het omgaan met sleutelbeheersystemen. Zodra we dat gedoe hebben weggenomen door zoiets als Sigstore te gebruiken om het gebruik van een traditionele PKI te omzeilen en het ondertekenings- en verificatieproces automatisch te laten verlopen, is er eigenlijk weinig reden om deze beveiligingstool niet te gebruiken. Als u bedenkt dat de identiteit die wordt gebruikt om een bestand of artefact te ondertekenen, ook kan worden gebruikt in een beleid dat de veiligheid van uw CI/CD-pijplijn verifieert, zou u nog gemotiveerder moeten zijn om bijna alles wat u ziet te ondertekenen.
Door bestanden te ondertekenen met hun metadata kunt u de tijd en locatie van hun oorsprong verifiëren, evenals de persona en het systeem waarin ze zijn gemaakt, allemaal relevante stukjes informatie wanneer bekeken door de lenzen van een beveiligingsspecialist. Het is een goed idee om te kunnen vaststellen dat de persoon, het systeem en de tijd overeenkomen met het bedrijf en de pijplijn waar de software is gemaakt, wanneer een eenvoudige vervanging een ondertekende, overtuigende vervalsing kan opleveren – totdat de zingende persoonlijkheid is gecontroleerd.
Gezien het feit dat de tool die ik zou voorstellen voor het ondertekenen en verifiëren van bewijsmateriaal gratis te gebruiken is, zou je eigenlijk geen excuus moeten hebben. Bekijk ons volledige artikel op Valint – onze Validation Integrity-tool om te zien wat u er nog meer mee kunt doen en begin vandaag nog met het ondertekenen van uw SBOM’s en ander gegenereerd bewijsmateriaal.
Deze inhoud wordt u aangeboden door Scribe Security, een toonaangevende aanbieder van end-to-end software supply chain-beveiligingsoplossingen die state-of-the-art beveiliging levert voor codeartefacten en codeontwikkelings- en leveringsprocessen in de software supply chain. Meer informatie.
Gerelateerde berichten
