CI/CD-pijplijnen zijn notoir ondoorzichtig als het gaat om wat er precies binnenin gebeurt. Zelfs als jij degene bent die het YAML-configuratiebestand (de pijplijnlijst met instructies) heeft geschreven, hoe kun je er dan zeker van zijn dat alles precies gebeurt zoals beschreven? Erger nog, de meeste pijpleidingen zijn volledig kortstondig, dus zelfs als er iets ergs gebeurt, blijven er daarna geen sporen achter.
Simpel gezegd is een pijplijn een geautomatiseerde manier om uw software, app of artefact te testen, bouwen en publiceren. Dergelijke pijpleidingen worden steeds gebruikelijker en ingewikkelder. Pipelines werken uitstekend om teams sneller te laten werken en consistentere en voorspelbaardere resultaten te geven bij het produceren van hun software-artefact. Het belang van het automatiseren van deze processen wordt nog duidelijker als je bedenkt dat grotere bedrijven honderden georkestreerde pipelines kunnen hebben die van elkaar afhankelijk zijn. Het is dus essentieel dat alles soepel en foutloos verloopt.
Als laatste schakel in het ontwikkelingsproces tussen de ontwikkelaars en de eindgebruiker of klant, ben ik van mening dat er niet genoeg aandacht is voor de manier waarop dergelijke geautomatiseerde processen kunnen worden gebruikt als potentiële aanvalsvectoren. Door toegang te krijgen tot een build-pijplijn kunnen kwaadwillende actoren niet alleen het systeem van het producerende bedrijf binnendringen, maar ook het resulterende artefact potentieel zodanig wijzigen dat alle toekomstige gebruikers worden getroffen, waardoor een enorme ontploffingsradius ontstaat die vaak wordt omschreven als een aanval op de software supply chain.
In een vorig artikel hebben we de principes besproken die u als leidraad dienen te dienen het beveiligen van uw CI/CD-pijplijn. In dit artikel bespreek ik enkele van de meest voorkomende potentiële zwakke punten in een CI/CD-pijplijn en bied ik enkele herstelopties aan. Voor onze doeleinden maakt het niet uit welke automatiseringstools of -systemen u gebruikt – de beveiligingsprincipes zijn nog steeds geldig, u hoeft alleen maar de juiste tool te vinden voor de taak om dat deel van uw pijplijn te beveiligen.
De kunst van CI/CD beheersen: de belangrijkste elementen die u niet kunt negeren
Verschillende pijpleidingen hebben verschillende elementen en gebruiken verschillende tools. De elementen waarop ik mij concentreer, zijn relevant voor vrijwel elke pijplijn, dus het beveiligen van deze elementen kan als een best practice worden beschouwd, ongeacht uw SCM, tooling of bestaande beveiligingsconfiguratie.
Geheim Beheer – geheimen zijn meestal strings of tokens die worden gebruikt om uw software of pijplijn met andere bronnen te verbinden. Een veelvoorkomend voorbeeld zijn de API-sleutels die worden gebruikt om uw code te verbinden met AWS-bronnen zoals een S3-bucket. De meeste mensen weten al dat ze deze geheimen verborgen moeten houden en ze niet als platte tekst in een open repository moeten opnemen. Binnen een CI/CD-pijplijn zijn de zaken iets ingewikkelder. Normaal gesproken heeft de pijplijn toegang nodig tot deze geheimen om toegang te krijgen tot de bronnen en informatie die ze vertegenwoordigen. Dat betekent dat iedereen die toegang heeft tot wat er in uw pijplijn gebeurt, mogelijk uw geheimen kan zien en kopiëren. Eén manier om uw geheimen veilig te houden, zelfs binnen uw pijplijn, is door een tool voor geheimbeheer te gebruiken, zoals Hashicorp-kluis. Dergelijke tools kunnen niet alleen uw geheimen verdoezelen, zelfs binnen uw pijplijn, maar ze maken het ook veel gemakkelijker om uw geheimen te rouleren, zodat u ze regelmatig kunt wijzigen, waardoor het stelen van geheimen uit een pijplijn waardeloos wordt. Ongeacht de tool voor geheimenbeheer die u kiest, kan het regelmatig rouleren van uw geheimen als een goede beveiligingspraktijk worden beschouwd.
Uitvoering van vergiftigde pijpleidingen (PPE) - Poisoned pipeline executie (PPE) is een techniek waarmee bedreigingsactoren de CI-pijplijn kunnen 'vergiftigen'. In feite kunnen de pijplijnstappen of hun volgorde worden gewijzigd, zoals gedefinieerd in het pijplijninstructiebestand. De techniek maakt misbruik van machtigingen in broncodebeheer (SCM)-repository's om het bouwproces te manipuleren. Het maakt het mogelijk om kwaadaardige code of opdrachten in de build-pijplijnconfiguratie te injecteren, waardoor de pijplijn wordt vergiftigd om tijdens het bouwproces kwaadaardige code uit te voeren. Tenzij u het pijplijninstructiebestand vóór elke build verifieert, tast u hoogstwaarschijnlijk in het ongewisse over het feit dat uw builds niet langer worden uitgevoerd zoals u hebt opgegeven. Zelfs een minuscule verandering, zoals het benoemen van de ene bibliotheek boven de andere, kan verstrekkende gevolgen hebben, zoals het opnemen van backdoors of cryptominers in het eindproduct.
Een van de manieren om PPE te vermijden is door te verifiëren dat het pijplijninstructiebestand ongewijzigd is. U kunt het bestand cryptografisch ondertekenen en de handtekeningverificatie toevoegen als eerste stap van elke pijplijn. Een tool die u kunt gebruiken om bestanden te ondertekenen en verifiëren is Valint, een tool uitgegeven door Scribe Security. Welk hulpmiddel voor tekenverificatie u ook gebruikt, het is de bedoeling ervoor te zorgen dat de integriteit van uw instructiebestand intact blijft.
Cache/afhankelijkheden Vergiftiging – CI/CD-pijplijnworkflows worden vaak gebruikt om bepaalde acties te specificeren die moeten worden uitgevoerd. Elke workflow bestaat uit een reeks van één of meer taken, die worden gekenmerkt als een reeks acties. De meeste workflows delen om veiligheidsredenen geen bronnen. Er zijn echter oplossingen voor wanneer het nodig wordt om bronnen te delen. Een cache waartoe alle workflows in gelijke mate toegang hebben, is zo'n oplossing. Omdat de cache wordt gedeeld door meerdere workflows, is er slechts één overtreding nodig in een workflow met de bevoegdheid om deze te wijzigen, zodat de cache giftig wordt voor al het daaropvolgende gebruik van de workflow. Een vergiftigde cache kan heel lang actief zijn, wat gevolgen heeft voor talloze iteraties van softwarebuilds die in die pijplijn worden uitgevoerd, aangezien de cache alleen wordt bijgewerkt als er een nieuw artefact of nieuw pakket is om te downloaden.
Net als bij de verificatie van het pijplijninstructiebestand kunt u gebruik maken van Valint om uw cache of een map met alle vooraf goedgekeurde afhankelijkheden die uw pijplijn vereist te ondertekenen en later te verifiëren. Als u een paranoïde type bent, is het een trefzekere manier om uw pijplijn onafhankelijk verbinding te laten maken met internet en alle bibliotheken te downloaden die zij nodig achten om meer kwetsbaarheden en mogelijke exploits in uw uiteindelijke build te krijgen.
SSH-sleutels – Een SSH-sleutel is een toegangsreferentie voor het SSH-netwerkprotocol (secure shell). Dit netwerkprotocol wordt gebruikt voor communicatie op afstand tussen machines op een onbeveiligd open netwerk. SSH wordt gebruikt voor bestandsoverdracht op afstand, netwerkbeheer en toegang tot het besturingssysteem op afstand. Met SSH-sleutels kunt u bijvoorbeeld verbinding maken met GitHub zonder bij elk bezoek uw gebruikersnaam en persoonlijke toegangstoken op te geven. U kunt ook een SSH-sleutel gebruiken om commits te ondertekenen. Je kunt ook andere applicaties met je GitHub verbinden met behulp van SSH-sleutels zoals BitBucket en GitLab.
Om de veiligheid van uw account te behouden, moet u regelmatig uw lijst met SSH-sleutels controleren en alle sleutels intrekken/verwijderen die ongeldig of gecompromitteerd zijn. Voor GitHub vindt u uw lijst met SSH-sleutels op de volgende pagina:
Toegang tot settings > SSH- en GPG-sleutels
Een hulpmiddel dat u kan helpen uw SSH-sleutels onder controle te houden, is een open-source beveiligingspostuurrapport genaamd GitGat. Het GitGat-rapport waarschuwt u als een van uw geconfigureerde SSH-sleutels is verlopen of ongeldig is. Naast dat je je sleutels nauwlettend in de gaten houdt en ze vaak draait, waarschuwt GitHub je dat als je een SSH-sleutel tegenkomt die je niet kent, deze onmiddellijk moet verwijderen en contact moet opnemen met GitHub-ondersteuning voor verdere hulp. Een niet-geïdentificeerde openbare sleutel kan duiden op een mogelijke inbreuk op de beveiliging.
SLSA-herkomst als een onveranderlijk pijplijnlogboek - SLSA staat voor Supply Chain Levels for Software Artifacts, een raamwerk ontwikkeld door Google en andere industriële partners om de veiligheid en integriteit van softwaretoeleveringsketens te helpen verbeteren.
SLSA definieert een reeks van vier niveaus, die elk een hoger niveau van vertrouwen en zekerheid in de softwaretoeleveringsketen vertegenwoordigen. Elk niveau is een toenemende toename van de beveiligingsvereisten. Een belangrijke vereiste is de noodzaak van de herkomst van het bestand. Voor het SLSA-framework geldt
Herkomst is de verifieerbare informatie over softwareartefacten die beschrijven waar, wanneer en hoe iets is geproduceerd. Aangezien het grootste deel van het doel van een CI/CD-pijplijn is om iets te produceren (meestal een build), is het kunnen bijhouden van welke bestanden precies zijn binnengekomen en wat ermee is gebeurd een soort niet-falsifieerbaar machinelogboek van de pijplijn. Voor dit doel is het belangrijk dat de SLSA-herkomst onafhankelijk van welke gebruiker dan ook wordt aangemaakt. De integriteit van alles wat een gebruiker kan onderbreken of wijzigen, kan verdacht zijn.
Eén tool waarmee u een SLSA-herkomst in uw pijplijn kunt creëren voor een grote verscheidenheid aan SCM-systemen is Valint (ja, dezelfde tool van Scribe – het is een zeer veelzijdige tool). De link laat zien hoe u Valint verbindt met uw GitHub-pijplijn om een SLSA-herkomst te genereren voor elke build die op die pijplijn wordt uitgevoerd. U kunt later elk herkomstbestand openen en controleren of er iets ongewoons of onverwachts is gebeurd. Hier is een fragment uit zo'n herkomstbestand:
Het herkomstbestand is slechts een JSON-bestand, maar aangezien er (nog) geen geautomatiseerde tools zijn om herkomstbestanden te lezen, ligt de taak van het lezen en interpreteren ervan bij u.
Uw eindresultaat veiligstellen – Een van de meest bekende inbreuken op de softwaretoeleveringsketen in de recente geschiedenis is de SolarWinds-incident. Daarin hebben de hackers een code op de buildserver aangepast, zodat elke build die door het bedrijf werd vrijgegeven een geheime achterdeur bevatte. Een ander beroemd geval van het corrumperen van het eindresultaat is te zien in de hack van de Vietnamese Government Certificate Authority (VGCA) uit 2020, genaamd Operatie SignSight. De indringers infiltreerden de VGCA-website en stuurden downloadlinks door naar hun eigen, met malware besmette versie van de software. In beide gevallen konden de eindgebruikers niet verifiëren of de software die ze kregen de software was die het producerende bedrijf wilde uitbrengen.
Een eenvoudiger aanval zou kunnen zijn om het uiteindelijke image dat aan het einde van de pijplijn is gebouwd, te vervangen door een kwaadaardig exemplaar en het slechte image te uploaden naar de plek waar het naartoe moet. Omdat bij de meeste van dergelijke aanvallen de afbeelding vermoedelijk afkomstig is van het producerende bedrijf, is het niet genoeg, zelfs als dat bedrijf wordt beschermd door een geldig certificaat. Het zou de nep alleen maar veel geloofwaardiger maken.
Opnieuw is de oplossing om het uiteindelijke artefact dat door de pijplijn wordt geproduceerd cryptografisch te ondertekenen en de eindgebruiker in staat te stellen die handtekening te verifiëren.
Zoals ik al vermeldde Valint Ik stel het gebruik van open-source voor Cosign van Sigstore. Cosign wil het ondertekenen eenvoudig maken door de noodzaak van belangrijke infrastructuur weg te nemen. Hiermee kan de gebruiker zijn online geverifieerde identiteit (zoals Google, GitHub, Microsoft of AWS) als sleutel gebruiken. U kunt Cosign gebruiken om afbeeldingen te ondertekenen en te verifiëren, waardoor het ideaal is voor de ondertekening en latere verificatie van het uiteindelijk gebouwde beeld van een pijplijn.
Of u er nu voor kiest om Valint of Cosign te gebruiken, uw gebruikers de mogelijkheid bieden om een cryptografische handtekening op uw uiteindelijke artefact te verifiëren om er zeker van te zijn dat ze precies krijgen wat u wilde leveren, is een idee waarvan ik zeker weet dat de meeste eindgebruikers dit op prijs zouden stellen.
Pijpleidingbeveiliging in de toekomst
Er zijn uiteraard nog andere elementen betrokken bij een bouwpijplijn die baat zouden kunnen hebben bij extra beveiliging. In dit artikel heb ik ervoor gekozen om naar enkele van de meer voor de hand liggende en enkele van de meer kwetsbare pijplijnelementen te kijken.
Welke pijplijntools of infrastructuur u ook gebruikt, zorg ervoor dat u uw ogen open houdt voor de mogelijkheid van een inbreuk. Vertrouw nooit blindelings op een systeem dat u vertelt dat het volledig veilig is.
Gezien de toenemende dreiging van identiteitsdiefstal, spearphishing en andere vormen van het vervalsen van legitieme toegang, zijn wij van mening dat het tekenverificatiemechanisme een goed, veelzijdig hulpmiddel is om in uw digitale gereedschapskist te hebben.
Of u nu een afbeelding, bestand of map moet ondertekenen, ik nodig u uit om Valint van Scribe Security eens nader te bekijken als een one-stop-shop-tool voor dergelijke behoeften.
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
