Valint gebruiken om beleid toe te passen op uw SDLC

Valint is de belangrijkste Scribe-tool voor het maken, beheren, ondertekenen en verifiëren van bewijsmateriaal. In een vorige postbehandelden we de theorie van het gebruik van het ondertekenen en verifiëren van bewijsmateriaal als een belangrijk hulpmiddel bij het valideren van de beveiliging van uw CI/CD-pijplijn. Ter korte herinnering: het door Scribe voorgestelde model bevat verschillende bouwstenen die op elke gewenste manier kunnen worden geschud en gestapeld. De bouwstenen omvatten het verzamelde bewijsmateriaal (SBOM's, SLSA herkomst, eventuele testresultaten van derden die u wilt opnemen), de omgevingscontext van het verzamelde bewijsmateriaal (wie het heeft gemaakt, waar, wanneer, enz.) en het beleid dat u op dat bewijsmateriaal wilt toepassen.

Omdat het beleid dat u op uw bewijsmateriaal wilt toepassen een sleutelfactor is in dit model, dachten we dat we een blogpost zouden wijden om het potentieel van de beleidsmotor die we aanbieden in meer detail te onderzoeken.

In dit artikel bespreken we het meest elementaire beleid dat we hebben opgesteld (informatie ondertekenen en verifiëren). We bespreken hoe de sjabloon voor een complexer beleid eruit ziet en geven een paar standaardvoorbeelden voor beleid, zoals hoe u kunt verifiëren dat een specifieke gebruiker degene was die de laatste 'hoofd'-vertakking heeft gemaakt, of hoe u kunt verifiëren dat uw pijplijn loopt bevat een tooltest van derden die moet worden meegeleverd.

Begin hier: bewijsmateriaal ondertekenen en verifiëren

Valint is een zeer veelzijdige tool, maar om dit artikel eenvoudig te houden zullen we voornamelijk de CLI-interface van Valint als voorbeeld gebruiken.

De eerste stap zou zijn om Valint te downloaden:

curl -sSfL https://get.scribesecurity.com/install.sh | sh -s -- -t valint

Het commando om een ​​SBOM te maken vanuit een repository of een afbeelding is 'bom'. Dus bijvoorbeeld als je dat wilt bom het beeld van busybox:latest het commando ziet er als volgt uit:

$HOME/.scribe/bin/valint bom busybox:latest -o attest -f

Merk op dat attest is een alias voor attest-cyclonedx-json.

Standaard gebruikt Valint sigstore interactieve flow als de motor achter het ondertekeningsmechanisme dat is ingebed in de Cocosign-bibliotheek van Scribe. Deze bibliotheek houdt zich bezig met digitale handtekeningen voor ondertekening en verificatie. Zodra u de opdracht heeft toegepast, moet u eerst goedkeuren dat u het bewijsmateriaal wilt ondertekenen met een Y/[N]-optie:

U kunt ook standaard PKI gebruiken voor ondertekening (we ondersteunen x509-certificaten). Er zijn meerdere opties voor het opslaan van de ondertekeningssleutel – bijvoorbeeld KMS, GitHub geheime opslag, en u kunt Valint eenvoudig configureren om welk ondertekeningsmechanisme dan ook te gebruiken.

Ervan uitgaande dat u de handtekening goedkeurt, wordt u in uw browser doorgestuurd naar Sigstore, waar u moet inloggen met uw GitHub-account, uw Google-account of uw Microsoft-account:

Nadat u zich heeft aangemeld, ziet u dat het inloggen is gelukt:

waarna u de browser kunt sluiten en terug kunt gaan naar uw shell, waar u kunt zien dat het bewijsmateriaal met succes is aangemaakt.

Het attest wordt standaard geschreven naar de lokale cache waarvan de locatie wordt geleverd door de --output-directory flag in het configuratiebestand flag. Je kunt ook gebruik maken van de –uitvoerbestand flag om een ​​aangepast pad voor het attest op te geven.

Nu we een ondertekend attest hebben gemaakt, gaan we proberen te verifiëren dat deze bestaat en is ondertekend. Het commando om bewijsmateriaal te verifiëren is verify. De manier om het te gebruiken is vrijwel identiek aan de bom commando, behalve dat we de vlag zullen gebruiken -iwat een afkorting is voor --input-format en de standaard hiervoor is, zoals in bom, attest-cyclonedx-json. Het verificatiecommando zoekt eerst naar het benodigde bewijsmateriaal op de standaardlocatie die door Valint wordt gebruikt. U kunt een andere locatie opgeven als u het bewijsmateriaal wilt opslaan en er later naar wilt zoeken.

Dus als we de busybox:latest afbeeldingsattest die we hebben gegenereerd en ondertekend in het vorige voorbeeld, de opdracht ziet er als volgt uit:

$HOME/.scribe/bin/valint verify busybox:latest -i attest

Ervan uitgaande dat je alles goed hebt gedaan, zou het resultaat er als volgt uit moeten zien:

U kunt de lijst met e-mails met het e-mailadres van de ondertekenaar zien op het originele attest en u kunt ook het type attest zien dat is geverifieerd, in dit geval cyclonedx-json. 

Lijkt vrij eenvoudig toch? Laten we een stapje verder gaan.

Beleidssjablonen

A beleidsmaatregelen bestaat uit een set van modules. Het beleid is geverifieerd als alle modules die het bevat, zijn geëvalueerd en geverifieerd. Een module wordt geverifieerd als ELK bewijs wordt gevonden dat voldoet aan de moduleconfiguratie en -instelling.  

Beleid wordt geconfigureerd als onderdeel van Valint's configuratiebestand, onder de beleidssectie. Dit is een voorbeeld van een deel van een Valint-configuratiebestand, het deel dat potentieel beleid bevat. 

Onthoud dat u geen configuratiebestand in uw project hoeft op te nemen. Valint kan prima werken als alleen de standaardopties zijn ingeschakeld. Omdat alles in dit bestand optioneel is, is het bovendien volkomen geldig om zo'n bestand te hebben dat ALLEEN uw beleid bevat. 

Het configuratiebestand, dat standaard .valint.yaml heet, moet in de hoofdmap van uw repository worden opgenomen. Gebaseerd op het beleid dat u in dit bestand opneemt, wanneer u de opdracht uitvoert valint verify het zal alle beleidsregels en modules uitvoeren die zijn ingeschakeld. Omdat het basisbeleid 'verifiëren' de standaard is, hoeft u niets te configureren voor het verify opdracht om correct te werken, zelfs zonder een .valint.yaml-bestand.

Welk beleid u ook toevoegt aan het configuratiebestand, het is afhankelijk van het feit of u naar bewijsmateriaal moet zoeken. Wanneer u de opdracht 'bom' in uw pijplijn uitvoert, wordt het resulterende bewijsmateriaal standaard geüpload naar de Scribe-bewijsopslag. Op dezelfde manier zal het programma, wanneer u de opdracht 'verify' uitvoert, naar het bewijs zoeken in de Scribe-bewijsopslag. U kunt deze standaard wijzigen en een OCI of een cache gebruiken als uw bewijsopslag, maar voor dit artikel gaan we ervan uit dat de standaard wordt gebruikt en dat al het bewijs wordt geüpload en uit de Scribe-bewijsopslag wordt gehaald.

Laten we op basis van dit voorbeeld eens kijken naar de componenten van een beleid. De beleidsmaatregelen ondersteunt de volgende velden:

• naam, de beleidsnaam (vereist).
• in staat stellen, schakel de module in (de standaardwaarde is false).
• modules, lijst met configuraties van beleidsmodules.  

 

De module secties ondersteunen de volgende velden:

• naam, de naam van de beleidsmodule (vereist).
• in staat stellen, schakel de module in (de standaardwaarde is false).
• type dan: , type module dat momenteel wordt ondersteund verifieer-artefact en git-eigenaar.
• match, match op bewijsmateriaal met een specifieke context.
• invoer, modulespecifieke configuratie.

Een beleid kan meerdere modules hebben en alle ingeschakelde modules worden uitgevoerd zodra u de opdracht 'verify' uitvoert. 

Omdat ik weet dat een droge lijst met velden niet erg informatief is, gaan we meteen naar de volgende sectie, voorbeeldbeleid.

Voorbeeldbeleid

Beleid voor beeldverificatie

Laten we beginnen met het eenvoudigste beleid, een beleid dat de tekenverificatiestroom van Valint tot uitdrukking brengt. 

attest: cocosign: beleid: - naam: verificatie_beleid inschakelen: waar modules: - naam: ondertekende_sbom type: verificatie-artefact inschakelen: waar invoer: ondertekend: waar formaat: attest-cyclonedx-json identiteit: e-mails: - barak@scribesecurity.com

Nogmaals, dit beleid moet worden opgenomen in het .valint.yaml-bestand in de root van uw repository. Om het te laten werken, moet u vooraf een ondertekende SBOM hebben gemaakt door de valint bom commando. Zodra u klaar bent om het te verifiëren, moet u de valint verify opdracht.

Als we naar dit voorbeeld kijken, kunnen we zien dat het beleid is ingeschakeld en dat het één ingeschakelde module van het type heeft ‘verify-artifact‘. De module controleert of de invoer ondertekend is en van formaat is ‘attest-cyclonedx-json’, en dat het is ondertekend door de identiteit die in de e-mail wordt weergegeven ‘barak@scribesecurity.com’.

Om dit beleid uit te voeren, moeten we de verifycommando in onze pijplijn als volgt:

valint verify busybox:latest

Aangezien de verify commando is nu gebaseerd op het beleid dat we hebben gegeven en zal zoeken naar een busybox:latest bewijsstuk in uw Scribe-bewijsarchief. Er wordt gezocht naar een ondertekende SBOM van formaat `cyclonedx-json` en het zou controleren of de identiteit die de SBOM heeft ondertekend, het e-mailadres gebruikt dat in het beleid is voorgeschreven `barak@scribesecurity.com`.

Je zou kunnen zeggen dat er meerdere van dit soort afbeeldingen in die bewijsopslag kunnen staan, en dan heb je gelijk. Dit is waar de context een rol speelt. Standaard, verify commando zal zoeken naar de dichtstbijzijnde beschikbare match. U kunt echter opgeven dat de opdracht moet overeenkomen met de context van de pijplijnrun-ID of het buildsysteem waarin het artefact is gemaakt. Om dat te doen, moet u het veld gebruiken match: met het juiste contexttype. Bijvoorbeeld:

            match: context_type: github git_url: github.com/my_org/myimage.git branch: main

In dit geval moest het bewijsmateriaal zijn gegenereerd door Github, door de door de genoemde repository git_url en door de main tak van die repository. Het is belangrijk om waar nodig de juiste context te gebruiken om ervoor te zorgen dat uw beleid precies verifieert wat u wilt dat het verifieert. 

Binair verificatiebeleid

Laten we een ander voorbeeld onderzoeken. Dit beleid is bedoeld om te verifiëren dat een exe-bestand dat we controleren afkomstig is uit een specifieke opslagplaats en is ondertekend door een van de verschillende bekende personen. 

attest: cocosign: beleid: - naam: verificatie_beleid inschakelen: echte modules: - naam: binary_module type: verificatie-artefact inschakelen: waar invoer: ondertekend: waar formaat: attest-cyclonedx-json identiteit: e-mails: - barak@scribesecurity.com - mikey@scribesecurity.com - adam@scribesecurity.com match: target_type: file context_type: azure git_url: https://dev.azure.com/mycompany/somerepo # Git-URL van de omgeving. invoernaam: mijn_binary.exe

Als we naar dit voorbeeld kijken, kunnen we zien dat het beleid is ingeschakeld en dat het één ingeschakelde module van het type heeft ‘verify-artifact‘ De module controleert of de invoer ondertekend is en het formaat heeft ‘attest-cyclonedx-json’, en dat het is ondertekend door 1 van de 3 toegestane e-mailadressen die in de module worden vermeld. Daarnaast controleert het of de verify commando ontvangt een invoer om te verifiëren dat de invoer een naam heeft ‘my_binary.exe’, dat de invoer een bestand is dat in Azure is gemaakt en dat het afkomstig is van een specifieke git-URL: https://dev.azure.com/mycompany/somerepo.

Zoals u kunt zien, zijn er in dit voorbeeld veel meer vereisten om het beleid te verifiëren.

Om dit beleid uit te voeren, moeten we de verify commando in onze pijplijn als volgt:

valint verify file:my_binary.exe

Om er zeker van te zijn dat uw Scribe-bewijsarchief een ondertekende versie van dit binaire bestand heeft, moet u eerst het bewijsmateriaal als volgt maken:

valint bom file:my_binary.exe -o attest

Beleid voor bewijsverificatie door derden

Laten we in ons laatste voorbeeld eens kijken hoe we kunnen verifiëren dat een tool van derden die we gebruiken goed in onze pijplijn heeft gewerkt en het resultaat heeft opgeleverd dat we verwachten in de vorm van een JSON-bestand. 

attest: cocosign: beleid: - naam: verificatie_beleid inschakelen: waar modules: - naam: regeltype van derden: verificatie-artefact inschakelen: waar invoer: ondertekend: vals formaat: attest-generieke identiteit: e-mails: - bob@scribesecurity. com match: target_type: generiek context_type: azure git_url: https://dev.azure.com/mycompany/somerepo git_branch: hoofdinvoernaam: 3rd-party-scan.json

In dit voorbeeld stellen we ons voor dat we op een bepaald punt in de pijplijn een tool van derden hebben uitgevoerd die als resultaat het bestand `3rd-party-scan.json` heeft gemaakt. Om aan het beleid te voldoen zou dat bestand afkomstig moeten zijn van Azure DevOps, geactiveerd door de `https://dev.azure.com/mycompany/somerepo` repository en ondertekend door `bob@scribesecurity.com`. 

Om het bewijsmateriaal te genereren waarnaar we op zoek zijn, moeten we, direct nadat de tool van derden is uitgevoerd, het resulterende bestand vastleggen en het in bewijsmateriaal omzetten met behulp van Valint:

valint bom 3rd-party-scan.json -o attest-generic --predicate-type https://scanner.com/scan_format

Wat bewijst het bewijs? 

We hebben dus gezien dat we Valine kunnen gebruiken om verschillende dingen in onze pijplijn te verifiëren. Waar kan dit vermogen eigenlijk voor worden gebruikt?

Laten we ons voorstellen dat onze pijplijn is doorbroken en dat een aantal slechteriken daarin dingen zijn gaan doen die we niet willen dat ze doen. Door te verifiëren dat de verschillende stappen van de pijpleiding hebben plaatsgevonden zoals verwacht, de verwachte resultaten hebben opgeleverd en zijn ondertekend door het goedgekeurde personeel, maken we het veel moeilijker voor de slechteriken om ons te misleiden.

Een mogelijke aanval is het vervangen van het binaire bestand aan het einde van de pijplijn, zodat de versie die uw klanten krijgen een kwaadaardige versie is in plaats van uw originele. Door uw versie te ondertekenen en uw klanten te vragen deze te verifiëren aan de hand van de hoofdkopie, kunt u ervoor zorgen dat ze allemaal hetzelfde bestand gebruiken dat u hebt gemaakt en geen slimme vervalsing zijn.

Dit model van het creëren van bewijsmateriaal en het vervolgens verifiëren ervan is nog maar het begin. We werken er voortdurend aan om extra mogelijkheden aan Valint toe te voegen om het nog robuuster en veelzijdiger te maken. In de tussentijd moedig ik u aan om onze documentatie voor meer informatie over wat Scribe te bieden heeft en wat u nog meer met Valint kunt doen. Valint is gratis te downloaden en te gebruiken, dus niets zou u ervan moeten weerhouden om deze tool vandaag nog eens uit te proberen.