De details van wat er binnen CI/CD-pijplijnen gebeurt, zijn berucht ondoorzichtig. Hoe kun je er, ondanks dat je het YAML-configuratiebestand, de pijplijnlijst met instructies, hebt geschreven, zeker van zijn dat alles precies gebeurt zoals beschreven? Erger nog, het merendeel van de pijpleidingen is volledig van voorbijgaande aard, dus zelfs in het geval van een storing is er, afgezien van wat er is geregistreerd, weinig bewijsmateriaal dat wel of niet de details van het probleem bevat.
Snelle ontwikkeling wordt bereikt door het gebruik van geautomatiseerde Continuous Integration/Continuous Delivery (CI/CD) pipelines. Het is fantastisch om triggers of planningen te hebben die uw code automatisch compileren, bouwen, testen en verzenden. De meeste pijpleidingen zijn echter niet gebouwd met het oog op veiligheid, omdat ze zijn ontworpen met het oog op snelheid en gebruiksgemak. Omdat de pijplijnen doorgaans toegang tot internet vereisen voor het downloaden van afhankelijkheden en bestanden, heeft de aanvaller, zodra een pijplijn is aangetast, verschillende opties om uw werking te verstoren of informatie of geheimen te exfiltreren.
In dit artikel bespreek ik enkele van de best practices die u kunt invoeren om uw CI/CD-pijplijn te beschermen. Voor onze doeleinden maakt het niet uit welke automatiseringstools of -systemen u gebruikt: de beveiligingsprincipes zijn nog steeds geldig. U hoeft alleen maar het juiste gereedschap te vinden om dat deel van uw pijpleiding te beveiligen.
Wat is de CI/CD-pijplijn (Continuous Integration/Continuous Delivery)?
Een CI/CD-pijplijn is een geautomatiseerd proces voor het bouwen, testen en publiceren van uw software, applicatie of artefact. Deze pijpleidingen worden steeds gebruikelijker en ingewikkelder. Pipelines zijn een uitstekend hulpmiddel om de teamproductiviteit te verhogen en software-artefacten consistenter en voorspelbaarder te produceren. Het belang van het automatiseren van deze procedures wordt veel duidelijker als je bedenkt dat grotere bedrijven honderden onderling verbonden, gechoreografeerde pijpleidingen kunnen hebben, die allemaal van elkaar afhankelijk zijn om goed te kunnen functioneren.
Het automatisch en regelmatig bouwen en testen van codewijzigingen in een nieuw eindproduct staat bekend als continue integratie of CI. Coderingswijzigingen worden geleverd, getest en geïntegreerd als onderdeel van een tweestapsproces dat continue levering en/of implementatie wordt genoemd: CD. Continue implementatie levert de updates automatisch in de productieomgeving, terwijl continue levering stopt vlak voor de automatische productie-implementatie. Of uw pijplijn het een of het ander gebruikt, hangt volledig af van u en van de manier waarop uw omgevingen en deliverables zijn ingericht.
Het belang van CI/CD-beveiliging voor uw softwaretoeleveringsketen
De meeste bedrijven vertrouwen erop CI/CD-tools voor het automatiseren van hun pijpleidingen. Dat betekent dat, net als vele anderen software supply chain-aanvallenHet enige wat de slechte acteurs nodig hebben is een enkel doelwit te doorbreken om een enorme ontploffingsradius te krijgen. Een van de belangrijkste zwakke punten is de noodzaak voor de pijplijn om afhankelijkheden te downloaden en te integreren in het eindproduct of artefact. Zelfs één slechte afhankelijkheid is genoeg om een ongewenst element voet aan de grond in de pijplijn te geven. Omdat de pijplijn toegang heeft tot de broncode en verschillende andere elementen van uw infrastructuur (indien nodig), kan een escalatie van bevoegdheden toegang krijgen tot vrijwel elk deel van het product dat in die specifieke pijplijn is gemaakt en dit later wijzigen of exfiltreren.
Een eenvoudig voorbeeld vindt u in onze uitleg van a cache- of afhankelijkheidsvergiftiging.
De afgelopen jaren hebben verschillende grote bedrijven te lijden gehad onder aanvallen op de software-toeleveringsketen die een CI/CD-pijplijn als oorsprong hadden. Je kunt bijvoorbeeld kijken naar De inbreuk van CircleCI in januari 2023, Het compromis van Argo CD in januari 2022, en de Codecove-inbreuk in april 2021.
De potentiële gevolgen van dergelijke aanvallen zijn ernstig, dus het is verstandig om alles te doen wat u kunt om ervoor te zorgen dat uw pijpleidingen zo veilig mogelijk zijn.
Best practices voor CI/CD-beveiliging
Welk CI/CD-platform of welke tools u ook gebruikt, er zijn een paar dingen die u kunt doen om uw beveiliging te versterken en de potentiële schade te verminderen in het onwaarschijnlijke geval dat een vijandige actor erin slaagt toegang te krijgen tot uw pijplijn of netwerk.
Bewaken en waarschuwen – Er kan zelfs een inbreuk plaatsvinden als u uw technici hebt getraind om voorzichtig te zijn met phishing en andere social engineering-fraude. Omdat de meeste pijplijnomgevingen tijdelijk zijn, zullen er na voltooiing van het werk niet veel sporen meer achterblijven, tenzij u ze actief registreert. Terwijl u aan elke PR werkt, samenvoegt, bouwt en test, moet u ervoor zorgen dat eventuele wijzigingen in de omgeving of configuratiebestanden worden geregistreerd. Gebruikersgegevens moeten ook samen met alle andere gegevens worden geregistreerd voor onderzoek als een probleem daarom vraagt. Het doel hierbij is het kunnen reconstrueren van een breuk en vaststellen wat er mis is gegaan en hoe het mis is gegaan. Selecteer vooraf de gebeurtenissen die een waarschuwing moeten activeren en zorg ervoor dat de juiste partijen op de hoogte worden gesteld. Zorg ervoor dat u personen niet overweldigt met zinloze of overdreven gevoelige waarschuwingen; dit zou kunnen leiden tot waarschuwingsmoeheid, waardoor ze de waarschuwingen eenvoudigweg zouden negeren of veel later zouden reageren dan verstandig is.
Gebruik het RBAC-principe gecombineerd met de minste privileges – Het bieden van toegang tot systeembronnen op basis van de toegewezen rol of functie van een gebruiker binnen een organisatie vormt de basis van Role-Based Access Control (RBAC). Gebruikers krijgen rollen in RBAC die hun toegangsrechten en machtigingen voor verschillende systeembronnen, zoals bestanden, mappen en programma's, specificeren. Aan de andere kant verwijst het concept van de minste privileges naar de praktijk om gebruikers de minimale hoeveelheid toegang en privileges te geven die nodig zijn om hun taken uit te voeren. Dit houdt in dat gebruikers beperkt zijn tot het gebruik van de middelen die nodig zijn om de hun toegewezen taken te voltooien en niets meer. Least Privilege en RBAC worden vaak naast elkaar toegepast als complementaire beveiligingsconcepten. Het Least Privilege-principe zorgt ervoor dat gebruikers alleen toegang hebben tot de minimale hoeveelheid bronnen die nodig zijn om hun specifieke taken uit te voeren, en RBAC wijst rollen toe die gebruikers de juiste hoeveelheid toegang bieden tot de bronnen die ze nodig hebben om hun taken uit te voeren en niets meer. . Gecombineerd helpen deze richtlijnen bij het handhaven van een goed onderhouden, relatief veilig systeem. U kunt het configureren om meerdere gebruikersautorisaties te vereisen voor essentiële systeemacties als extra beveiligingslaag. Deze strategie moet zorgvuldig worden toegepast, omdat dit ertoe kan leiden dat het ontwikkelingsproces merkbaar vertraging oploopt.
Bewaar de herkomst van de pijpleiding als een onveranderlijk logboek – Verifieerbare informatie over softwareartefacten die beschrijft waar, wanneer en hoe iets is gemaakt, wordt herkomst genoemd. Door precies te weten welke bestanden zijn ingevoerd en wat ermee is gebeurd in een pijplijn, kan dit worden gegenereerd als een herkomstbestand om een niet-falsifieerbaar logboek van die pijplijn te vormen. Om veilig te zijn, moet de herkomst onafhankelijk van welke gebruiker dan ook worden aangemaakt, aangezien alles wat een gebruiker kan verstoren of wijzigen niet geheel betrouwbaar is. Valint van de schrijver stelt u in staat herkomst vaststellen in uw pijplijn voor een breed scala aan SCM-systemen. Elk herkomstbestand (JSON) is later toegankelijk, zodat u het kunt bekijken om te bepalen of er iets onverwachts of ongewenst is gebeurd. Trouwens, het genereren en beheren van herkomstbestanden vanuit al uw pijplijnen vormt de kern van de SLSA-framework.
Benut uw SBOM volledig – Voor het geval je een paar van de mogelijke toepassingen hebt gemist, kan een SBOM aan het einde van de pijplijn helpen bij het opsommen van alle gebruikte open source-pakketten. Als u die lijst vergelijkt met bekende CVE's, kunt u ontdekken welke potentiële kwetsbaarheden er in uw eindproduct voorkomen. U kunt de lijst ook gebruiken om te controleren of u nog steeds verouderde versies van open-sourcepakketten gebruikt, en zelfs zoiets als de OpenSSF-scorekaart om de 'gezondheid' van de pakketten die u gebruikt te controleren. Omdat er voortdurend nieuwe CVE's aan het licht komen, zou u, in tegenstelling tot een eenmalige SAST, een dienst moeten hebben die u laat weten of er in een van uw bestaande pakketten een nieuwe CVE is ontdekt. De service van Scribe kan u helpen dat allemaal automatisch te doen.
Controleer de naleving van uw beleid – Elk bedrijf, en soms elke pijplijn, heeft beleid dat moet plaatsvinden om ervoor te zorgen dat alles in orde is. Sommige beleidsregels zijn algemeen (zoals ervoor zorgen dat er een tweepersoonsverificatieproces is), en andere zijn uniek (zoals ervoor zorgen dat Mike de laatste wijziging ondertekent voordat we deze naar productie sturen). Met behulp van het cryptografische tekenverificatiemechanisme en een uniek beleidsbestand kunt u nu het benodigde beleid in elke pijplijn opnemen en verifiëren (voor uzelf en anderen) dat dit heeft plaatsgevonden. Het is een menselijke zwakte die er bij stress voor kan zorgen dat sommige vereisten worden overgeslagen en dat sommige regels worden verbogen om aan een deadline te voldoen. Nu deze maatregel van kracht is, kunnen mensen de regels niet langer omzeilen, en dat zou moeten bijdragen aan het behoud van de veiligheid van uw pijpleiding, zowel tegen bedreigingen van binnenuit als van buitenaf. Scribe heeft een nieuwe manier ontwikkeld om dergelijk beleid af te dwingen en u zelfs in staat te stellen uw eigen beleid te schrijven. Bekijken hier.
Beveilig het instructiebestand van The Pipeline – Bedreigingsactoren kunnen de CI-pijplijn “vergiftigen” door gebruik te maken van een techniek die bekend staat als vergiftigde pijplijnuitvoering (PPE), die in wezen de fasen van de pijplijn of hun volgorde wijzigt, zoals oorspronkelijk gespecificeerd in het pijplijninstructiebestand. De methode manipuleert het bouwproces door misbruik te maken van machtigingen in broncodebeheeropslagplaatsen (SCM). Door kwaadaardige code of opdrachten in de build-pijplijninstellingen in te voegen, is het mogelijk de pijplijn te vergiftigen en ervoor te zorgen dat kwaadaardige code wordt uitgevoerd terwijl de build wordt voltooid. U kunt niet zien dat uw builds niet werken zoals u het bedoeld had, totdat u het pijplijninstructiebestand controleert. Om er zeker van te zijn dat uw pijplijnen worden uitgevoerd zoals bedoeld, moet u vóór elke uitvoering het instructiebestand verifiëren. Cryptografisch gezien is het ondertekenen van het bestand en het toevoegen van de handtekeningverificatie als eerste stap in de pijplijn één manier om die beveiliging te bereiken. Valint van de schrijver ondertekenen en verifiëren functies zijn een manier om te verifiëren dat uw instructiebestand ongewijzigd is gebleven voordat u een nieuwe pijplijnrun start.
Beveilig uw eindresultaat – Waarom zou een aanvaller hard moeten werken om uw pijplijn te verstoren terwijl het vervangen van uw eindproduct door een frauduleuze versie veel eenvoudiger is? Omdat het genererende bedrijf bij dit soort aanvallen de bron van het beeld lijkt te zijn, is het onvoldoende dat dat bedrijf over een geldig certificaat beschikt dat het beeld beschermt. Simpel gezegd: het zou de geloofwaardigheid van de nep vergroten. De oplossing is 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. Scribe's Valint kan gebruikt worden ondertekenen en verifiëren een grote verscheidenheid aan artefacten die u de extra zekerheid bieden dat uw gebruikers precies krijgen wat u van hen had verwacht.
Op zoek naar de toekomst
Niemand zal stoppen met het gebruik van automatiseringstechnieken zoals CI/CD om hun werk te versnellen. Integendeel: in de wereld waarin we leven streven we altijd naar steeds snellere iteraties van software-updates. We moeten er op zijn minst voor zorgen dat we de taak met de nodige voorzichtigheid benaderen en ervoor zorgen dat we onze productieomgeving of onze broncode daarbij niet in gevaar brengen.
Het cruciale punt is om rekening te houden met de mogelijke gevolgen als iemand illegale toegang krijgt tot uw pijplijn, uw omgeving of uw broncode. Ik weet zeker dat u de juiste actie kunt ondernemen om potentiële lekken te stoppen of te beperken zodra u zich realiseert hoe gevaarlijk het kan zijn en waar uw pijpleidingen en netwerk het meest vatbaar zijn.
Omdat onderling verbonden pijpleidingen alleen maar in complexiteit zullen toenemen, is het van cruciaal belang om uw algehele omgevingsbeveiliging (gesegmenteerd netwerk, RBAC, zero trust, enz.) te handhaven als eerste stap om uw pijpleidingen te helpen beschermen. Probeer daarna solide, niet-falsifieerbaar bewijsmateriaal te creëren en maak gebruik van cryptografische ondertekening en verificatie van gegevens om te proberen het potentieel van een software supply chain-aanval die uw pijplijn of de cache van uw pijplijn zou kunnen vergiftigen, zoveel mogelijk te beperken. Alert en achterdochtig blijven kan uw bedrijf ongekende kopzorgen besparen.
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
