So stärken Sie die Sicherheit Ihrer CI/CD-Pipeline

DevSecOps bezeichnet die Integration von Sicherheitspraktiken in den DevOps-Prozess. Bei modernen Entwicklungszyklen können Sie es sich nicht leisten, die Sicherheit bis zum Schluss aufzuschieben. Sie sollte in jeder Phase von Anfang an berücksichtigt werden.

Sicherheit bei Continuous Integration und Continuous Delivery (CI/CD) ist ein wichtiger Teil von DevSecOps. Es ist entscheidend, Ihre Pipelines abzusichern und sicherzustellen, dass die automatisierten Systeme zur Implementierung von CI/CD nicht angreifbar sind.

In diesem Artikel erfahren Sie, welche Sicherheitsrisiken Ihre CI/CD-Pipeline bedrohen können. Außerdem lernen Sie, wie Sie Pipelines gegen Angriffe absichern und ihre Sicherheit durch Tests überprüfen.

Warum Sie Ihre CI/CD-Pipeline absichern müssen

Wenn es um Sicherheit geht, stehen meist Webanwendungen und öffentlich zugängliche Dienste im Fokus. Scheinbar nebensächliche Bereiche wie Ihre Pipeline werden leicht übersehen. Das ist ein Fehler, denn unzureichende CI/CD-Sicherheit kann schwerwiegende Folgen haben.

Eine kompromittierte Pipeline kann Hackern Zugriff auf Ihre Systeme verschaffen – darunter auf Ihren Code, wertvolle Daten und Kundengeheimnisse. Sobald ein Teil Ihrer Pipeline kompromittiert ist, ist alles darin gefährdet.

Auch das Einschleusen von Schadcode ist ein Risiko – eine unauffällige, aber äußerst schwerwiegende Angriffsform. Ein Angreifer mit Zugriff auf Ihre Pipeline kann eigenen Code einschleusen, der anschließend ohne Ihr Wissen in Ihren finalen Build integriert wird. Dadurch wird Ihre bereitgestellte Anwendung kompromittiert und Angreifer können ungehindert Daten von Ihnen und Ihren Nutzern stehlen.

Außerdem kann eine kompromittierte Build-Kette Geheimnisse preisgeben. Passwörter oder Zugangsdaten, mit denen Ihre Tools autorisiert werden, können gestohlen und für den Zugriff auf andere Teile Ihres Systems verwendet werden. Mit gestohlenen Zugangsdaten können Hacker großen Schaden anrichten – deshalb müssen Sie diese unbedingt schützen.

Verwenden Sie außerdem keine veralteten Komponenten, denn diese sind besonders anfällig für Angriffe. Neue Angriffsvektoren werden ständig entdeckt und Software wird aktualisiert und gepatcht, um sie zu beseitigen. Ältere Software bleibt jedoch ungeschützt.

Die Aktualisierung Ihrer Software auf die neuesten Versionen bietet neben der Sicherheit viele weitere Vorteile. Eine aktuelle Toolchain sollte daher ein zentraler Bestandteil Ihrer Sicherheitsstrategie sein.

Eine sichere CI/CD-Pipeline aufbauen

Zum Glück können Sie viel tun, um sich vor Angriffen zu schützen. Sehen wir uns einige Maßnahmen an, die Sie ergreifen können.

Rollenbasierte Zugriffskontrolle implementieren

Mit der rollenbasierten Zugriffskontrolle (RBAC) können Sie den Zugriff auf verschiedene Bereiche Ihres Systems beschränken. Sie können Personen entsprechend ihrer Rolle Zugriff gewähren. So lassen sich sichere Regeln mit unterschiedlichen Zugriffsstufen einfacher erstellen und schnell umsetzen.

Der Zugriff pro Nutzer scheint sicher, führt in der Praxis jedoch zu Problemen: Alte Konten werden beispielsweise übersehen und Berechtigungen bleiben zu lange bestehen. Mit RBAC verfügen Sie über einen festen Regelsatz, dessen Berechtigungen Sie gesammelt erteilen oder entziehen können.

Auf Schwachstellen scannen

Automatisierte Tools sind beim Scannen auf Schwachstellen unverzichtbar. Zum Glück stehen zahlreiche Sicherheitsscanner zur Verfügung, mit denen Sie Probleme schnell und effizient finden. Sie können Codierungsfehler oder Konfigurationsprobleme erkennen, durch die Ihr System angreifbar wird.

Sie können auch externe Unterstützung hinzuziehen und eine unabhängige Sicherheitsprüfung durchführen lassen, um übersehene Probleme aufzuspüren. Wer nicht so nah am Projekt ist wie Sie, kann blinde Flecken erkennen, die Ihnen möglicherweise nicht aufgefallen sind.

Einen Secrets Manager verwenden

Secrets Manager sind Tools, die sensible Daten wie Zugangsdaten oder Schlüssel speichern und den Zugriff darauf verwalten. Wenn Sie festlegen, wer, wo und wie auf diese Daten zugreifen kann, sinkt das Risiko einer Offenlegung erheblich. Ein gutes Secrets-Management-Tool verschlüsselt die Daten außerdem sowohl im Ruhezustand als auch während der Übertragung und begrenzt so die Auswirkungen einer Offenlegung.

Viele CI-Plattformen verfügen über ein integriertes System zur Verwaltung von Geheimnissen und Zugangsdaten. Einige lassen sich sogar in gängige externe Secrets-Management-Systeme integrieren.

Netzwerkexposition verwalten

Uneingeschränkter Netzwerkzugriff kann Ihre CI/CD-Systeme für Angriffe von außen (Ingress) anfällig machen und gleichzeitig den unbemerkten Datenabfluss (Egress) erleichtern. Wenn Sie die Netzwerkexposition verwalten und nicht benötigte Zugriffe auf Ihre Pipeline unterbinden, sind Sie besser geschützt.

Öffnen Sie beispielsweise so wenige Ports wie möglich und schließen Sie diese, wenn sie nicht benötigt werden. Deaktivieren Sie außerdem Remote-Funktionen, die Sie nicht brauchen. Docker-Sockets, APIs und alle anderen Schnittstellen, über die Ihre Systeme mit der Außenwelt kommunizieren, müssen streng geschützt werden.

Vertrauensgrenzen einschränken

Eine weitere Möglichkeit, Risiken zu mindern, besteht darin, Vertrauensgrenzen so weit wie möglich einzuschränken. Jede Kommunikation mit externen Systemen oder Nutzern muss abgesichert werden. Erlauben Sie nur, was Sie benötigen, und gewähren Sie Zugriff möglichst nur für einen bestimmten Zeitraum.

Wenn alle Teile Ihrer Kette möglichst wenige Informationen preisgeben, wird es auch schwieriger, Sie anzugreifen. Textausgaben wie Fehlermeldungen können in einem öffentlich zugänglichen Teil Ihres Systems landen. Hacker können damit ein detailliertes Bild Ihrer Infrastruktur erstellen und ihre Angriffe gezielter ausrichten.

Um dies zu verhindern, können Sie Befehle in manchen Fällen mit möglichst geringer Ausgabe ausführen. So enthalten Protokolle und Ausgaben, die möglicherweise offengelegt werden, so wenige Informationen wie möglich über Ihr System.

Der Bash-Befehl wget gibt beispielsweise alle möglichen Informationen aus. Mit dem Flag q lässt sich diese Ausgabe unterdrücken, etwa so:

wget -q https://google.com

Hacker arbeiten sich oft entlang Ihrer Toolchain vor und gewinnen dabei nach und nach Wissen über Ihr System. Wenn Sie die Ausgabe minimieren, verringern Sie ihre Möglichkeiten dazu. Ähnliche Flags können Sie auch für andere Befehle verwenden.

So automatisieren Sie die Sicherheit Ihrer CI/CD-Pipeline

Zum Glück lassen sich einige dieser Probleme mit einem Sicherheitsprodukt wie Snyk beheben, das als Teil Ihrer Build-Pipeline ausgeführt wird und Ihnen hilft, Probleme schnell zu erkennen und darauf zu reagieren.

Ein Schwachstellenscanner in Ihrer Pipeline kann beispielsweise Probleme durch veraltete Komponenten erkennen. Snyk kann solche Probleme finden und erkennen. Um im Terminal nach Problemen zu suchen, geben Sie einfach Folgendes ein:

snyk test

Sie können auch Ihre Quellcodeverwaltung, beispielsweise GitHub, in Snyk integrieren, um PR-Prüfungen automatisch hinzuzufügen. Diese erkennen neue Schwachstellen in Abhängigkeiten, Containern oder Infrastructure-as-Code-Richtlinien:

Weitere Informationen zur Integration von Snyk in PR-Prüfungen finden Sie in der Snyk-Support-Dokumentation.

So integrieren Sie Sicherheitstests in eine CI/CD-Pipeline

Sie können Sicherheitstests in Ihre Pipeline aufnehmen. Da die Tests verschiedene Aspekte abdecken können, sollten Sie alle berücksichtigen.

RBAC

Wie bereits erwähnt, ist RBAC eine hervorragende Möglichkeit, verschiedene Bereiche Ihres Systems abzusichern. Regelmäßige Tests können sicherstellen, dass dies so bleibt. Automatisierte Prüfungen können verifizieren, dass Nutzer nur auf Ressourcen zugreifen, die ihrer Rolle entsprechen. Ein Test mit einem anonymen Nutzer sollte beispielsweise keinen Zugriff auf Ressourcen ermöglichen, die Sie auf autorisierte Nutzer beschränken möchten. Ein solcher Test kann fehlschlagen, wenn Sie Software aktualisieren und sich dadurch Einstellungen ändern, sodass zuvor vorgenommene Konfigurationsänderungen nicht mehr angewendet werden.

APIs

API-Tests lassen sich ebenfalls automatisieren. Aus Sicherheitsgründen sollten Sie sowohl Tests durchführen, die mit den richtigen Zugangsdaten erfolgreich sind, als auch solche, die ohne diese fehlschlagen.

Der erfolgreiche Zugriff auf eine Ressource ohne die erforderlichen Zugangsdaten ist ein Sicherheitsproblem. Mit automatisierten API-Tests können Sie dies regelmäßig und schnell überprüfen. Sie können auch testen, ob Ihre APIs die erwarteten Ergebnisse zurückgeben und angemessen auf fehlerhafte Anfragen reagieren, die Ihre Sicherheit gefährden sollen.

Geheimnisse

Mit Tests auf Geheimnisse können Sie prüfen, ob diese irgendwo offengelegt werden. Pipelines müssen Passwörter und Tokens verwalten, und die Tools in Ihrer Kette benötigen die richtigen Berechtigungen, um ihre Aufgaben auszuführen.

Achten Sie darauf, Ihre Geheimnisse nicht in Tests offenzulegen, da auf diese zugegriffen werden kann. Snyk kann fest codierte Geheimnisse in Ihrem Code oder Ihren Skripten erkennen, damit Sie das Problem beheben können.

So sichern Sie eine Jenkins-CI/CD-Pipeline mit Snyk ab

Um mit Snyk zu starten, müssen Sie sich registrieren und den Client lokal installieren – die Installationsanleitung finden Sie hier. Wenn Sie beispielsweise npm verwenden, können Sie folgenden Code nutzen:

npm install snyk -g

Snyk lässt sich in die wichtigsten Cloud-Anbieter und viele weitere CI/CD-Tools integrieren. Zahlreiche Snyk-Plug-ins erleichtern diese Integration. Um Snyk beispielsweise mit Jenkins zu verwenden, rufen Sie das Jenkins-Dashboard und anschließend Manage Plugins auf. Suchen Sie dann im Tab Available nach Snyk Security. Denken Sie daran, das Plug-in zu registrieren und mit Ihrem Konto zu verknüpfen.

Sobald Sie Snyk integriert haben, können Sie es mit dem Eintrag snykSecurity als Phase in Ihre Pipeline aufnehmen:

1//build stage omitted 
2
3stage('Test') {
4      steps {
5            echo 'Testing with Snyk'
6            snykSecurity(
7                  snykInstallation: '<Snyk Installation Name>',
8                  snykTokenId: '<Snyk API Token ID>',
9                  // other parameters here
10            )
11      }
12}
13
14//deploy stage omitted

Mit den folgenden zusätzlichen Befehlen können Sie das Verhalten von Snyk steuern:

• failOnIssues und failOnError: Mit diesen Befehlen können Sie Ihr Skript bei einem der beiden Ereignisse stoppen. So verhindern Sie, dass von Snyk erkannte Probleme in Deployments gelangen. Das ist besonders empfehlenswert, wenn Ihre CI/CD-Pipeline die Bereitstellung von Anwendungen automatisiert, die live gehen.

• severity: Hiermit legen Sie fest, welchen Schweregrad Snyk untersuchen soll. Weniger schwerwiegende Probleme können Sie gegebenenfalls ignorieren und Builds fortsetzen, wenn nur geringfügige Probleme erkannt werden. Sie können sogar einen separaten Build-Schritt mit abweichendem Verhalten je nach Schweregrad ausführen.

Während Ihre Builds ausgeführt werden, sehen Sie in der Snyk-Konsole, ob Probleme vorliegen. In den Protokollen können Sie anschließend nachsehen, was behoben werden muss.

So richten Sie Snyk mit Jenkins ein. Es gibt jedoch viele weitere Möglichkeiten, darunter die Integration von Snyk in GitHub oder Cloud-Anbieter wie Amazon Web Services (AWS) und Azure.

Fazit

Ihre CI/CD-Pipeline ist ein wichtiger, aber leicht übersehener Teil Ihrer Sicherheitsstrategie. Hacker können sie auf vielfältige Weise ausnutzen. Deshalb sollten Sie unbedingt Maßnahmen ergreifen, um jeden Angriffsvektor einzudämmen.

Sie müssen sich schützen und denjenigen, die Ihre Systeme kompromittieren wollen, möglichst immer einen Schritt voraus sein. Sicherheitsupdates, automatisierte Tests und Rollenverwaltung sind nur einige der Möglichkeiten, Ihr System abzusichern und Angreifer fernzuhalten.

Snyk ist ein wertvolles Tool in Ihrem Sicherheitsarsenal und gibt Ihnen die Kontrolle über Ihre Pipeline. Besuchen Sie die Website und legen Sie los, um Ihre CI/CD-Sicherheit zu stärken. Mit Snyk bleiben Sie ganz einfach geschützt.