CI/CD-pijplijnen maken snellere en frequentere softwareontwikkeling mogelijk, van ontwerp tot implementatie. Maar toen ze voor het eerst hun intrede deden in de technologiesector, ontbrak er vaak een schakel: beveiliging.
Dat is een probleem, vooral gezien statistieken zoals deze: ongeveer één op de vijf organisaties meldde het afgelopen jaar een beveiligingsincident in zijn CI/CD-pijplijn, volgens een recent onderzoek uitgevoerd door Techstrong Research.
Naarmate CI/CD-pijplijnen steeds gebruikelijker zijn geworden, hebben ze ook het dreigingslandschap voor softwareteams veranderd. Zoals het Open Worldwide Application Security Project (OWASP) opmerkt: “Gezien hun belang en populariteit zijn CI/CD-pijplijnen ook een aantrekkelijk doelwit voor kwaadwillende hackers en mag hun beveiliging niet worden genegeerd.”
In dit artikel gaan we dieper in op de specifieke risico’s – en op effectieve principes en praktijken om die risico’s te beperken en de beveiliging van CI/CD-pijplijnen te waarborgen.
Wat is een CI/CD-pijplijn?
Laten we eerst zorgen dat we hetzelfde uitgangspunt hebben: wat is CI/CD? CI/CD is een afkorting van continue integratie en continue levering en verwijst naar een reeks processen en tools die moderne softwareteams gebruiken om software te ontwerpen, te bouwen en uiteindelijk te implementeren – waarbij automatisering een van de belangrijkste middelen is om code sneller en vaker te leveren en bij te werken.
Zo definieerden we het in ons vorige artikel, “Overzicht van CI/CD-pijplijnen: waarom je hiervan op de hoogte moet zijn”: “Een CI/CD-pijplijn is een transparant, geautomatiseerd en betrouwbaar proces voor softwareontwikkeling en -levering.”
Het doel is meestal niet alleen om sneller en vaker te leveren – het is ook om de kwaliteit, betrouwbaarheid en – ervan uitgaande dat je er de juiste prioriteit aan geeft – beveiliging te verbeteren.
Veelvoorkomende beveiligingsrisico’s van CI/CD: 5 aandachtsgebieden
De oorzaken van veel beveiligingsrisico’s van CI/CD zouden een techprofessional op zijn minst enigszins bekend moeten voorkomen. Zaken als toegangsbeheer en te ruime toegangsrechten, ontoereikende monitoring en logging, en niet-gereguleerde afhankelijkheden en softwaretoeleveringsketens dragen allemaal bij aan grotere risico’s wanneer ze niet goed worden beheerd.
OWASP heeft een lijst gepubliceerd met de 10 belangrijkste CI/CD-beveiligingsrisico’s die de moeite waard is om als referentie te bekijken. Deze lijst is een afgeleide van de populaire OWASP Top 10-lijst met beveiligingsrisico’s voor webapplicaties, die algemeen wordt geaccepteerd als industriestandaard voor de beveiliging van webapplicaties.
Risico’s binnen CI/CD-pijplijnen kunnen zowel door automatisering worden geïntroduceerd als verergerd. Veel risico’s worden automatisch geïntroduceerd – of automatisch naar productie uitgerold – in CI/CD-pijplijnen. Enigszins ironisch genoeg kan het automatiseren van de beveiliging van die pijplijnen met infrastructuur-als-code-tools (IaC-tools) of andere automatisering eveneens risico’s introduceren of versterken als je niet goed oplet, merkt Derek Ashmore, Principal voor applicatietransformatie bij Asperitas, op.
Volgens Ashmore zijn dit vijf belangrijke risicogebieden waarmee je rekening moet houden bij het beveiligen van je CI/CD-pijplijnen:
- Toegangsbeheer: “Toegangsbeheer wordt vaak uit gemaksoverwegingen te ruim toegewezen en houdt zich niet aan de principes van minimale rechten en dubbele controle,” zegt Ashmore. Over het algemeen moet het principe van minimale rechten hier leidend zijn – geef mensen of machines geen toegang tot gegevens of systemen die ze niet daadwerkelijk nodig hebben om hun werk te doen.
- Niet-gevalideerde afhankelijkheden: De software van vandaag – en als gevolg daarvan CI/CD-pijplijnen – is vaak afhankelijk van bibliotheken van derden en andere externe afhankelijkheden, en die componenten bevatten soms kwetsbaarheden. “Zorg er altijd voor dat externe afhankelijkheden zijn gevalideerd en een controleerbare bewakingsketen hebben,” zegt Ashmore.
- Auditing en logboekregistratie: Zorg ervoor dat uitgebreide auditing en logboekregistratie zijn geïmplementeerd. Een gebrek aan zichtbaarheid en controleerbaarheid kan leiden tot grotere beveiligingsrisico’s waarvan je je anders niet bewust zou zijn.
- Escalatie van bevoegdheden: Automatisering – van het soort dat inherent is aan CI/CD en CI/CD-beveiliging – kan soms in silo’s worden ontwikkeld, wat leidt tot onbedoelde hiaten waarin bevoegdheden kunnen worden verhoogd door een onbedoelde automatiseringsreeks uit te voeren. “Om dit risico te beperken, moet je ervoor zorgen dat minimale rechten zijn geïmplementeerd en dat er testgevallen zijn geïmplementeerd voor automatiseringswerkstromen en afzonderlijke taken of pijplijnen,” zegt Ashmore.
- Onvoldoende geautomatiseerd testen: Geautomatiseerd testen is niet alleen essentieel voor sterke CI/CD-pijplijnbeveiliging – denk bijvoorbeeld aan geautomatiseerde kwetsbaarheidsscans voor containerimages – maar ook voor een gezonde pijplijn als geheel. “Defecten in pijplijnen kunnen ongewenste beveiligingskwetsbaarheden veroorzaken en een negatieve invloed hebben op ontwikkelingsteams van applicaties door hen ervan te weerhouden hun toegewezen werk uit te voeren,” zegt Ashmore.
10 Top CI/CD-tools!
Here's my pick of the 10 best software from the 10 tools reviewed.
Clicks on the links below may earn a commission, which supports our independent testing and review of software and services. Learn more about how we stay transparent.
15 best practices voor sterkere CI/CD-beveiliging
Als je eenmaal een goed inzicht hebt in de risico’s, is het tijd om naar oplossingen te kijken. Het goede nieuws: er zijn er veel, deels omdat de sector als geheel het belang heeft ingezien van het integreren van beveiliging als volwaardig onderdeel van CI/CD.
Ashmore van Asperitas gaf ons een overzicht van 15 algemeen aanvaarde best practices en tactieken om de beveiliging van CI/CD-pijplijnen te versterken. Zonder verder oponthoud:
- Gebruik veilige versiebeheersystemen: Een van de belangrijkste voordelen van versiebeheersystemen zoals Git is dat ze wijzigingsgeschiedenis vastleggen die nodig kan zijn om beveiligingsinbreuken of andere problemen te onderzoeken. “Idealiter zou niets handmatig moeten worden gewijzigd”, zegt Ashmore. Bekijk onze uitgebreide lijst met bronbeheertools voor meer opties: “De 20 beste versiebeheertools beoordeeld”
- Dwing minimale toegangsrechten af: Zorg ervoor dat de rollen en rechten die worden toegekend aan zowel menselijke gebruikers als zaken zoals infrastructuurresources minimaal zijn en het principe van minimale toegangsrechten volgen. Als ze het niet nodig hebben, ken het dan niet toe.
- Gebruik geheimenbeheer: “Vermijd het hardcoderen van geheimen – wachtwoorden, tokens, API-sleutels – in IaC-sjablonen”, zegt Ashmore. Gebruik in plaats daarvan tools voor geheimenbeheer zoals HashiCorp Vault, AWS Secrets Manager of Azure Key Vault. Bekijk onze diepgaande analyse van tools voor geheimenbeheer voor nog meer opties: “Digitale kluizen: de 24 beste tools voor geheimenbeheer”
- Voer regelmatig geautomatiseerde beveiligingsscans uit: Gebruik tools die automatisch scannen op beveiligingskwetsbaarheden, en doe dit in de vroegst mogelijke fasen van je CI/CD-pijplijn.
- Volg het principe van onveranderlijkheid: Het minimaliseren van handmatige wijzigingen, vooral in infrastructuuromgevingen, is een goede strategie om risico’s te beperken. “Infrastructuur moet onveranderlijk zijn; zodra deze is ingericht, mag ze niet handmatig worden aangepast”, zegt Ashmore. “In plaats daarvan moeten wijzigingen worden aangebracht door de IaC-code bij te werken en opnieuw te implementeren. Het wegnemen van de mogelijkheid om handmatige wijzigingen aan te brengen is de veiligste aanpak.”
- Gebruik rolgebaseerde toegangscontrole (RBAC): “Beheer de toegang tot je IaC-tools en omgevingen met RBAC”, zegt Ashmore. “Alleen geautoriseerde gebruikers mogen infrastructuur implementeren of wijzigen.” Kubernetes is hier nog een belangrijk voorbeeld van, vooral omdat het een essentieel onderdeel is van veel CI/CD-pijplijnen. Vertrouw niet alleen op standaardconfiguraties.
- Pas idempotentie toe: Nu wordt het wat geavanceerder: idempotentie is het concept waarbij bepaalde bewerkingen – of code, in het geval van software-engineering – meerdere keren kunnen worden uitgevoerd zonder het resultaat te wijzigen. “Ontwerp IaC [en CI/CD-pijplijnen] op een idempotente manier. Dat betekent dat het meerdere keren uitvoeren van de code de toestand van de infrastructuur niet mag wijzigen, tenzij dit expliciet vereist is”, zegt Ashmore.
- Gebruik parametrisering: Ashmore raadt aan om variabelen en parametrisering te gebruiken in IaC-sjablonen om het hardcoderen van omgevingsspecifieke waarden, zoals regio’s, instantiegroottes en IP-adressen, te voorkomen.
- Implementeer monitoring en logboekregistratie: Deze zijn nodig om ongeautoriseerde of ongebruikelijke activiteiten te detecteren en om de grondoorzaken te achterhalen wanneer incidenten plaatsvinden. “Diensten zoals AWS CloudTrail of Azure Monitor kunnen helpen”, zegt Ashmore. Hier zijn nog twee bronnen: “De 25 beste keuzes voor logboekmonitoringsoftware” en “Gids voor de 26 beste tools voor infrastructuurmonitoring”
- Gebruik tools voor infrastructuurtests: “Integreer tools voor infrastructuurtests, zoals Test Kitchen, Terratest of InSpec, om vóór implementatie de juistheid van je IaC te valideren”, zegt Ashmore.
- Implementeer detectie van infrastructuurafwijkingen: Gebruik tools om infrastructuurafwijkingen te detecteren – dat wil zeggen wijzigingen die buiten de CI/CD-pijplijn plaatsvinden – en draai ongeautoriseerde wijzigingen terug wanneer deze worden gedetecteerd, adviseert Ashmore.
- Volg normen voor compliance en beveiliging: Zorg ervoor dat je CI/CD-pijplijn voldoet aan beveiligingsnormen en complianceframeworks binnen de sector, zoals CIS-benchmarks, NIST of AVG. De OWASP Top 10-lijst die we hierboven deelden is nog een voorbeeld.
- Maak herbruikbare en modulaire IaC-code: “Splits IaC-code op in herbruikbare en modulaire onderdelen, zoals Terraform-modules of AWS CloudFormation-stacks”, zegt Ashmore.
- Documenteer je pijplijn: Ashmore raadt aan om uitgebreide documentatie van je IaC-beleid, sjablonen en beveiligingsprocedures te maken en bij te houden, evenals van andere onderdelen van je CI/CD-pijplijn.
- Werk tools regelmatig bij: “Houd je IaC-tools (zoals Terraform, Ansible en CloudFormation) en alle gerelateerde afhankelijkheden bijgewerkt naar de nieuwste versies”, zegt Ashmore. Hetzelfde advies geldt in brede zin voor andere tools en afhankelijkheden in je pijplijn: verouderde versies hebben vaker bekende (en mogelijk onbekende) risico’s.
Meld je aan voor meer CI/CD-inzichten
CI/CD-pijplijnen zijn een vast onderdeel geworden van moderne softwareontwikkeling. Dat betekent dat CI/CD-beveiliging minstens zo belangrijk is. Voordat je vertrekt, schrijf je in voor onze nieuwsbrief om de nieuwste inzichten van toonaangevende denkers in de softwarebranche te ontvangen.
