Heeft u al gehoord van Dependabot? Als dat niet het geval is, vraag het dan aan een willekeurige ontwikkelaar om je heen, en zij zullen waarschijnlijk enthousiast zijn over de manier waarop het een revolutie teweeg heeft gebracht in de vervelende taak van het controleren en bijwerken van verouderde afhankelijkheden in softwareprojecten.
Dependabot verzorgt niet alleen de controles voor u, maar geeft ook suggesties voor wijzigingen die met slechts één klik kunnen worden goedgekeurd. Hoewel Dependabot beperkt is tot door GitHub gehoste projecten, heeft het een nieuwe standaard gezet voor continue providers om vergelijkbare mogelijkheden te bieden. Deze automatisering van ‘administratieve’ taken is een norm geworden, waardoor ontwikkelaars hun werk sneller dan ooit tevoren kunnen integreren en inzetten. Continue integratie- en implementatieworkflows zijn de hoeksteen van software-engineering geworden, waardoor de DevOps-beweging naar de voorgrond van de industrie is gestuwd.
Maar een recent advies van beveiligingsbedrijf Checkmarx werpt licht op een zorgwekkend incident. Kwaadwillige actoren hebben onlangs geprobeerd het vertrouwen in Dependabot te misbruiken door zich voor te doen als de tool. Door de suggesties van Dependabot na te bootsen (in de vorm van pull-verzoeken) probeerden deze actoren ontwikkelaars te misleiden om veranderingen te accepteren zonder erover na te denken.
Hoewel Dependabot een voorbeeld is van de vooruitgang op het gebied van het automatiseren van softwareonderhoudstaken, onderstreept dit incident ook de bredere complexiteit en kwetsbaarheden die inherent zijn aan CI/CD-pijplijnen. Deze pijplijnen dienen als vitale kanalen en verbinden de externe wereld van softwareontwikkeltools en -platforms met de interne processen van softwarecreatie en -implementatie. Het begrijpen van dit verband is van cruciaal belang voor het aanpakken van de veiligheidsuitdagingen waarmee we worden geconfronteerd.
CI/CD-pijplijnen: de buitenwereld verbinden met de interne wereld
Continue integratie (CI) en implementatie (CD) workflows hebben een revolutie teweeggebracht in het softwareontwikkelingsproces, waardoor ontwikkelaars de mogelijkheid hebben gekregen om hun werk naadloos samen te voegen en in de productieomgeving te implementeren. Deze workflows zorgen ervoor dat de code geautomatiseerde beveiligingsscans, rigoureuze tests en naleving van coderingsstandaarden ondergaat, wat resulteert in een efficiënter en betrouwbaarder ontwikkelingsproces. Ze zijn een katalysator voor innovatie geworden, waardoor teams zich kunnen concentreren op het bouwen en verbeteren van hun producten met de zekerheid van kwaliteit en veiligheid.
Om het concept te illustreren, stel je voor dat je een puzzel bouwt. CI fungeert als een waakzame controleur en verifieert dat elk nieuw puzzelstukje correct past voordat er verder wordt gegaan. Aan de andere kant gaat CD nog een stap verder door elk geverifieerd stukje automatisch in de uiteindelijke puzzel te plaatsen, waardoor het niet meer nodig is om te wachten tot de hele puzzel is voltooid. Dit versnelde proces zorgt voor een snellere levering van functies en versnelt uiteindelijk de algehele productontwikkelingstijdlijn.
Deze CI/CD-workflows verbinden de buitenwereld echter ook met de interne ontwikkelomgeving, waardoor potentiële risico’s ontstaan. Overweeg bijvoorbeeld een scenario waarin een ontwikkelaar een bibliotheek van derden in zijn project integreert via een CI/CD-pijplijn. Als de ontwikkelaar er niet in slaagt de bibliotheek grondig te onderzoeken of als de pijplijn niet over de juiste veiligheidscontroles beschikt, kan er onbewust kwaadaardige code in het project worden opgenomen, waardoor de integriteit ervan in gevaar komt. De afgelopen jaren is het aantal aanvallen zoals typosquatting en afhankelijkheidsverwarring toegenomen, die tot doel hebben de afhankelijkheid van open source-software te misbruiken voor financieel gewin.
De opkomst van geautomatiseerde integratieworkflows heeft de economie voor aanvallers veranderd door de kosten te verlagen en de potentiële voordelen van een aanval te vergroten. Aanvallers kunnen zich richten op populaire centrale pakketopslagplaatsen zoals PyPi, die duizenden pakketten host en dagelijks miljoenen downloads verzorgt. De enorme omvang van de operaties maakt het voor aanvallers economisch haalbaar om hun geluk te beproeven, zelfs met een kleine kans op succes.
Een ander voorbeeld is het gebruik van externe API’s binnen CI/CD-pipelines. Ontwikkelaars moeten vaak geldige inloggegevens voor deze API’s opgeven om geautomatiseerde implementatie of integratie met externe services mogelijk te maken. Als deze referenties echter niet veilig worden beheerd of als ze onbedoeld in logboeken of artefacten worden weergegeven, kunnen ze door aanvallers worden misbruikt om ongeautoriseerde toegang te krijgen tot gevoelige bronnen of om het gedrag van de pijplijn te manipuleren.
CI/CD-inbreuken zijn vaak het gevolg van een initiële compromittering van geheimen of van ontwikkelaars die het doelwit worden van specifieke aanvallen. Maar in plaats van ontwikkelaars de schuld te geven van deze inbreuken, is het van cruciaal belang om te erkennen dat het probleem ligt in het inherente gebrek aan veiligheid in deze pijpleidingen. Dit benadrukt een groter probleem: CI/CD-pijplijnen zijn verre van standaard veilig.
Het probleem: CI/CD-pijplijnen zijn verre van standaard veilig
Hoewel het idee om ‘secure-by-design’-workflows te implementeren steeds populairder wordt, hebben CI/CD-platforms nog een aanzienlijke weg te gaan. Platforms als GitHub Actions, GitLab CI/CD en CircleCI, die aanvankelijk zijn ontworpen met het oog op flexibiliteit, geven vaak prioriteit aan gebruiksgemak boven robuuste beveiligingsmaatregelen. Het gevolg is dat er geen standaardgaranties zijn om te voorkomen dat er potentiële problemen ontstaan.
Een treffend voorbeeld hiervan is hoe gemakkelijk het voor een ontwikkelaar is om gevoelige informatie, zoals geheimen, openbaar te maken. Ontwikkelaars injecteren gewoonlijk geheimen tijdens runtime en vertrouwen daarvoor op de mogelijkheid om geheimen op te slaan in de CI-provider zelf. Hoewel deze praktijk op zichzelf geen probleem is, brengt het op zijn minst twee veiligheidsproblemen met zich mee: ten eerste wordt de CI-provider die de geheimen host, een kluis met gevoelige informatie en een aantrekkelijk doelwit voor aanvallers. Nog maar begin 2023 kreeg CircleCI te maken met een inbreuk op zijn systemen, waardoor gebruikers “alles en al” hun geheimen moesten doorgeven na een inbreuk op de systemen van het bedrijf.
Ten tweede kunnen geheimen vaak lekken en onopgemerkt blijven via de CI/CD-pijplijnen zelf. Als een geheim bijvoorbeeld wordt samengevoegd met een andere tekenreeks (bijvoorbeeld een URL) en vervolgens wordt vastgelegd, werkt het CI-redactiemechanisme niet. Hetzelfde geldt voor gecodeerde geheimen. Het gevolg is dat CI-logboeken vaak leesbare geheimen blootleggen. Op dezelfde manier is het helemaal niet ongewoon om geheimen te vinden die hardgecodeerd zijn in softwareartefacten, als resultaat van een verkeerd geconfigureerde continue integratieworkflow.
CI/CD-providers hebben al stappen ondernomen om de beveiliging te verbeteren, zoals GitHub Dependabot-beveiligingscontroles. Maar meestal zijn tolerante standaardinstellingen en complexe toestemmingsmodellen nog steeds de regel. Om CI/CD-pijplijnen te beschermen en codecompromis te voorkomen, moeten ontwikkelaars aanvullende maatregelen nemen om hun pijplijnen tegen aanvallen te beschermen. Een cruciaal aspect is het waarborgen van de bescherming van de inloggegevens van ontwikkelaars. Een andere is het kiezen voor een proactieve benadering van beveiliging met waarschuwingstriggers.
Bescherming van CI/CD en de softwaretoeleveringsketen
Om CI/CD-pijplijnen effectief te beveiligen, is het van cruciaal belang om ze te zien als potentieel extern verbonden omgevingen met hoge prioriteit. De sleutel is een mix van best practices:
- Beperk de toegang en minimaliseer rechten: Verleen toegang op basis van noodzaak, niet op basis van gemak. Uitgebreide toegang tot alle DevOps-teamleden vergroot het risico dat een gecompromitteerd account aanvallers uitgebreide systeemtoegang biedt. Beperk de toegang tot kritieke bedieningselementen, configuraties of gevoelige gegevens.
- Multi-Factor Authenticatie (MFA) afdwingen: Cruciaal is dat u altijd multi-factor authenticatie (MFA) gebruikt voor het inloggen op het CI/CD-platform. MFA voegt een essentiële beveiligingslaag toe, waardoor het voor ongeautoriseerde gebruikers aanzienlijk moeilijker wordt om toegang te krijgen, zelfs als ze inloggegevens hebben gecompromitteerd.
- Maak gebruik van OpenID Connect (OIDC): Gebruik OIDC voor het veilig verbinden van workloads met externe systemen, zoals voor implementatie. Dit protocol biedt een robuust raamwerk voor authenticatie en identiteitsverificatie tussen domeinen, wat van cruciaal belang is in een gedistribueerde en onderling verbonden omgeving.
- Gebruik vooraf beoordeelde softwareafhankelijkheden: Het is belangrijk om ontwikkelaars veilige, vooraf beoordeelde softwareafhankelijkheden te bieden. Deze praktijk waarborgt de integriteit van de toeleveringsketen en voorkomt dat ontwikkelaars de code van elk pakket moeten verifiëren. Dit waarborgt de integriteit van de toeleveringsketen en ontlast ontwikkelaars van de last van het individueel verifiëren van de code van elk pakket.
- Veilige runtimegeheimen: Het veilig opslaan van geheimen zoals API-sleutels en inloggegevens op het CI/CD-platform vereist krachtige beveiligingsmaatregelen, zoals afgedwongen MFA en op rollen gebaseerde toegangscontroles (RBAC). Deze zijn echter niet waterdicht. Geheimen zijn van nature lekkend, en extra beveiligingslagen, zoals een strikte hygiëne van de identiteitsgegevens en een waakzame monitoring van interne en externe bedreigingen, zijn noodzakelijk voor uitgebreide bescherming.
- Implementeer geavanceerde verdedigingssystemen: Integreer waarschuwingssystemen in uw beveiligingsframework. Hoewel honeypots effectief zijn, maar lastig te schalen, bieden honeytokens een schaalbaar, eenvoudig te implementeren alternatief. Deze tokens, die een minimale installatie vereisen, kunnen de beveiliging aanzienlijk verbeteren voor bedrijven van elke omvang op verschillende platforms, zoals SCM-systemen, CI/CD-pijplijnen en registers van softwareartefacten.
- Maak gebruik van oplossingen op ondernemingsniveau: Oplossingen zoals het GitGuardian Platform bieden één enkel venster voor het monitoren van incidenten zoals gelekte geheimen, misconfiguraties van Infrastructure as Code en honeytoken-triggers, waardoor organisaties CI/CD-incidenten op grote schaal kunnen detecteren, verhelpen en voorkomen. Hierdoor wordt de impact van potentiële datalekken aanzienlijk beperkt.
Door deze strategieën te combineren kunnen organisaties hun CI/CD-pijplijnen en softwaretoeleveringsketen volledig beveiligen, zich aanpassen aan veranderende bedreigingen en robuuste beveiligingsprotocollen handhaven. Ga vandaag nog aan de slag met het beveiligen van uw pijpleidingen met het GitGuardian Platform.
