Achtergrond
SLSA (Supply-chain Levels for Software Artefacts) is een beveiligingsframework dat tot doel heeft manipulatie te voorkomen, de integriteit te verbeteren en pakketten en infrastructuur te beveiligen. Het kernconcept van SLSA is dat een softwareartefact alleen kan worden vertrouwd als het aan drie vereisten voldoet:
- Het artefact moet een herkomstdocument hebben waarin de oorsprong en het bouwproces worden beschreven (L1).
- Het herkomstdocument moet betrouwbaar zijn en stroomafwaarts worden geverifieerd (L2).
- Het bouwsysteem moet betrouwbaar zijn (L3).
Het SLSA-framework definieert niveaus die aangeven hoe veilig de softwaretoeleveringsketen is. Deze niveaus komen overeen met het implementatieniveau van deze vereisten (hierboven vermeld als L1-L3).
Schrijver valint slsa commando kan worden gebruikt om herkomstdocumenten te produceren. Hieronder beschrijven we hoe u SLSA-niveaus kunt bereiken met behulp van deze tool.
Let op: We verwijzen hier naar het SLSA V1.0-framework.
SLSA L1
De eisen voor SLSA L1 omvatten:
- Softwareproducenten volgen een consistent bouwproces.
- Het bouwplatform genereert automatisch herkomstgegevens die beschrijven hoe het artefact is gebouwd.
- Softwareproducenten distribueren herkomstgegevens naar consumenten.
Checklist voor het behalen van SLSA L1:
- Bouw uw software met behulp van een CI-systeem. Gebruik bij voorkeur een buildscript dat brongestuurd is.
- Activeer de
valint slsaopdracht als onderdeel van uw build-script om een Provenance-document te maken. Merk op dat devalint slsaMet de opdracht kunt u aanvullende informatie toevoegen aan het herkomstdocument. U kunt de inhoud van het herkomstdocument aanpassen aan uw behoeften.
SLSA L2
De eisen voor SLSA L2 omvatten:
- De SLSA L1-vereisten.
- De build draait op een gehost buildplatform dat de herkomst zelf genereert en ondertekent.
- Stroomafwaartse verificatie van de herkomst omvat het valideren van de authenticiteit van de herkomst.
Checklist voor het behalen van SLSA L2:
- De SLSA L1-checklist.
- Gebruik een gehoste buildservice (in plaats van de build uit te voeren op de ontwikkelaarsmachine).
- Maak een ondertekend herkomstdocument (in plaats van een niet-ondertekend document, wat voldoende is voor SLSA L1). Dit kan worden bereikt door het uitvoeren van
valint slsa ... -o attest. Schrijver valint tool heeft een breed scala aan ondertekeningsmogelijkheden; voor een onderneming raden we aan X.509 PKI-sleutels en -certificaten te gebruiken. - Controleer de authenticiteit van het herkomstdocument stroomafwaarts met behulp van de
valint verifycommando. Verificatie kan de handtekening en handtekeningidentiteit omvatten, evenals andere verificatieregels die de inhoud van het SLSA-herkomstdocument garanderen. Enkele voorbeelden zijn te vinden in Scribe's beleidscatalogus.
Let op: Verificatie dient te worden gedaan door de consument van de gebouwde software; voor interne naleving kan de verificatie worden uitgevoerd als onderdeel van een testpijplijn.
SLSA L3
SLSA L3-vereisten
De eisen voor SLSA L3 omvatten:
- De SLSA L2-vereisten.
- Build-platform implementeert sterke controles om:
- Voorkom dat runs elkaar beïnvloeden, zelfs binnen hetzelfde project.
- Voorkom dat geheimen die worden gebruikt om de herkomst te ondertekenen, toegankelijk zijn via de door de gebruiker gedefinieerde bouwstappen.
Om het bouwplatform te kunnen vertrouwen, is dat bovendien nodig verifieer het bouwplatform. Het bouwplatform moet vertrouwd worden in de zin dat het Provenance-document dat ook zal zijn onvervalsbaar en de bouw zal zijn geïsoleerd. Voor een dergelijke verificatie gelden de volgende vereisten:
- Verifieer dat het gebruik van het platform breekt niet de onvervalsbaarheid en het isolement vereisten.
- Het verifiëren van de isolatie kan bijvoorbeeld worden gedaan door het gebruik van cache in de pijplijn te evalueren.
- Om de onvervalsbaarheid van het herkomstdocument te garanderen, raden we u aan het in een speciale build-pijplijn te genereren en te ondertekenen.
- Controleer de betrouwbaarheid van het bouwplatform.
- Voor SaaS-CI's moet een verificatie worden uitgevoerd bij de leverancier van het bouwplatform. In gevallen waarin de softwareproducent verantwoordelijk is voor de implementatie van het bouwsysteem, wordt een combinatie van leverancierszelfattestering en het uitvoeren van een analyse van de implementatieaspecten aanbevolen.
- Wanneer u bijvoorbeeld een zelf-hostend CI implementeert, moet de attest van de leverancier aangeven hoe builds van elkaar worden geïsoleerd, en moet de implementatieanalyse de toegangsrechten en log-audit van het CI-systeem verifiëren.
Deze vereisten zijn een uitdaging omdat het voldoen aan deze vereisten afhankelijk is van het CI-platform, niet volledig kan worden geautomatiseerd en een professionele beveiligingsanalyse van de bouwsystemen en pijplijnen vereist. Dat is de reden waarom het SLSA-framework specifiek suggereert dat organisaties geleidelijk evolueren van SLSA L2- naar SLSA L3-compliance.
Als je dit artikel helemaal tot hier hebt doorgenomen en hebt besloten dat SLSA L3 de juiste keuze voor je is, stroop dan je mouwen op – hier is onze aanbeveling voor een checklist:
Checklist voor het behalen van SLSA L3:
- De SLSA L2-checklist.
- Beoordeel het CI-systeem. Het doel is om de volgende vragen te beantwoorden:
- Onder welke omstandigheden kan een ongeautoriseerde entiteit het bouwsysteem omzeilen?
- Onder welke omstandigheden kunnen gebouwen elkaar beïnvloeden?
Eenmaal beantwoord: beheer de resterende risico's.
- Isoleer de generatie van het herkomstdocument:
- Scheid het maken van het herkomstdocument naar een andere pijplijn, bij voorkeur op een afzonderlijke buildservice.
- Stel aan deze pijplijn alleen de geheimen bloot die zijn gebruikt voor het ondertekenen van het herkomstdocument.
- Maak of verifieer de inhoud van het herkomstdocument in deze pijplijn. In het geval van verificatie verifieert u alle mogelijke velden van een in de pijplijn gegenereerd Provenance-document met gegevens die rechtstreeks van het bouwplatform of van andere vertrouwde bronnen zijn verzameld.
- Scheid het maken van het herkomstdocument naar een andere pijplijn, bij voorkeur op een afzonderlijke buildservice.
- Isoleer en verifieer de isolatie van de build-pijplijn van andere pijplijnuitvoeringen:
- Controleer het gebruik van caches en gedeelde volumes.
- Controleer of geheimen die met andere pijplijnen worden gedeeld, niet toestaan dat pijplijnen elkaar beïnvloeden.
- Controleer of pijplijnuitvoeringen elkaar niet kunnen beïnvloeden
- Voorkom bijvoorbeeld dat installaties via één pijpleiding andere pijpleidingen beïnvloeden. Dit kan worden gedaan door kortstondige build-runners te gebruiken (zoals een container die voor elke build wordt gemaakt) of door te verifiëren dat build-runners elke keer vanuit een vooraf bepaalde status starten.
Om SLSA L3 te bereiken met Scribe-tools, raden we het volgende aan:
- Instrumenteer de build-pijplijn voor het genereren van alle attesten die nodig zijn om het herkomstdocument in te vullen. U kunt bijvoorbeeld besluiten dat u een lijst wilt met de afhankelijkheden die tijdens de build zijn geïnstalleerd. Deze lijst kan worden gegenereerd door a
valint bom dir:commando. Maak bovendien een herkomstattest in de pijplijn met behulp van devalint slsaopdracht. - Maak een afzonderlijke pijplijn voor het genereren van vertrouwde herkomst die het volgende zal uitvoeren:
- Genereer een vertrouwd herkomstdocument op basis van het document dat in de build-pijplijn is gemaakt;
- Verzamel gegevens van de bouwservice en gebruik deze om het herkomstdocument te verifiëren en bij te werken.
- Controleer de inhoud van attesten die in de build-pijplijn zijn gemaakt. Controleer bijvoorbeeld de inhoud van de build-runner door een SBOM-attest uit de build-pijplijn te vergelijken met een SBOM-attest dat afzonderlijk is bemonsterd.
- Gebruik attesten die zijn verzameld uit de build-pijplijn om het herkomstdocument bij te werken.
- Het bijwerken van het herkomstdocument kan worden gedaan met behulp van de
valint slsaopdracht.
- Controleer of de build is geïsoleerd door gegevens te evalueren die zijn verzameld via de build-service. Controleer bijvoorbeeld het gebruik van caches en geheimen.
- Genereer een vertrouwd herkomstdocument op basis van het document dat in de build-pijplijn is gemaakt;
Om dergelijke gegevensverzameling en -evaluatie uit te voeren, biedt Scribe tools die attesten voor de build-run creëren en de benodigde verificaties uitvoeren.
---
Oke. Het lijkt erop dat je er helemaal klaar voor bent om te gaan. Mocht u hulp nodig hebben, dan kan dit uiteraard Laat het ons weten. Wij zijn er om u te helpen en adviseren u graag of helpen u actief mee.
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
