Sicherheit in CI und CD: OWASP Top 10 Risiken meistern

Continous Integration (CI) und Continous Deployment (CD) haben sich in den letzten Jahren zu wichtigen Bestandteilen des Softwareengineerings entwickelt. Automatisierung ermöglicht Entwicklerteams, neue Funktionen und Updates schnell und effizient bereitzustellen. Allerdings birgt der Einsatz von CI/CD auch einige Sicherheitsrisiken, die es zu berücksichtigen gilt. Die OWASP Top 10 CI/CD Security Risks bietet eine Übersicht der häufigsten Sicherheitsrisiken und zeigt Wege auf, wie diese gemeistert werden können.

Wieso wird Continous Integration (CI) und Continous Deployment (CD) gebraucht?

CI/CD ist die Automatisierung von wiederkehrenden Aufgaben und Tätigkeiten in der Softwareentwicklung, zum Beispiel die automatische Qualitätssicherung und Veröffentlichung von neuen Softwareversionen. Es hat seinen Ursprung in den frühen 2000er Jahren, als agile Methoden in der Softwareentwicklung immer beliebter wurden. Ein agiles Umfeld bedingt häufige und qualitative Releases. Das Ziel von CI/CD ist es, schnell und iterativ einen Mehrwert für die Stakeholders zu liefern, sowie die Qualität der Software zu verbessern.

Die 6 Vorteile von Continous Integration (CI) und Continous Deployment (CD) sind:

1. Kürzere Entwicklungszyklen
2. Bessere Softwarequalität durch automatisierte Tests und Überprüfungen
3. Reduktion von Fehlern und Verzögerungen durch ständige Integration und Überprüfung
4. Verkürzung der Time-to-Market durch automatische Bereitstellung von Änderungen
5. Erhöhung der Effizienz durch Automatisierung und Standardisierung des Entwicklungsprozesses
6. Verbesserung der Sicherheit durch automatisierte Sicherheitschecks in CI/CD-Pipelines, einschliesslich Prüfungen auf veraltete Dependencies und hartcodierte Zugangsdaten.

Insgesamt kann CI/CD dazu beitragen, die Entwicklung von Software schneller, effizienter und fehlerfreier zu gestalten. Allerdings bieten diese automatisierten Prozesse auch neue Angriffsflächen. OWASP hat im Oktober 2022 ihre erste offizielle Top 10 Liste für CI/CD Risiken spezifisch vorgestellt.

Die Top 10 Continous Integration (CI) und Continous Deployment (CD) Risiken

Die Vermeidung der OWASP Top 10 CI/CD Risiken erfordert die Implementierung angemessener Sicherheitsmassnahmen und -praktiken im gesamten CI/CD-Prozess. Es ist wichtig, die CI/CD-Prozesse sorgfältig zu überwachen und sicherzustellen, dass alle notwendigen Schutzmassnahmen implementiert werden, um die Sicherheit der Systeme und Daten zu gewährleisten.

Oft sind diese Systeme sehr komplex. Durch die Top 10 hat man Anhaltspunkte, nach denen man sich richten kann.

CICD-SEC-1: Insufficient Flow Control Mechanism

Beispielszenario

Ein Angreifer erlangt Zugriff auf das SCM (Source Code Management)-System wie Github oder Gitlab einer Organisation und pusht bösartigen Code auf einen Branch, der automatisch in die Produktionsumgebung deployt wird, ohne dass es eine zusätzliche Genehmigung oder Überprüfung gibt. Der Code wird anschliessend automatisiert gebaut und verteilt.

Risiko

CI/CD-Flows ermöglichen eine schnelle Entwicklung und Veröffentlichung von Code. Oft wird komplett auf automatische Prozesse gesetzt, die mit hohen Privilegien ausgestattet sind. Wenn die Software automatisch gebaut und bereitgestellt wird, kann es sein, dass schadhafter Code integriert und verteilt wird.

Massnahmen

Jede Änderung und Anpassung der Umgebung sollte gründlich reviewed und manuell genehmigt werden. Der Code soll automatisch geprüft werden, für neue Anpassungen sollte aber immer noch ein manuelles Code Review notwendig sein. Dies lässt sich mit den meisten SCM-Services wie Github als obligatorisch definieren.

CICD-SEC-2: Inadequate Identity and Access Management

Beispielszenario

Ein Angreifer findet durch Passwort-Brute-Forcing aktive Anmeldedaten eines alten Testaccounts, für welchen ein simples Passwort gesetzt wurde, aber welcher nie deaktiviert wurde. Der Angreifer kann damit Schadcode einschleusen, Daten stehlen oder das System anderweitig kompromittieren.

Risiko

Die Komplexität unterschiedlicher Identitäten und Zugriffsmethoden im System macht es schwierig, Berechtigungen zu verwalten und sicherzustellen. Grund dafür ist, dass CI/CD-Systeme sowohl menschliche Benutzer als auch verschiedene Benutzer für automatisierte Prozesse auf verschiedenen Umgebungen benötigen.

Massnahmen

Folgende Punkte können dabei helfen:

• Eine kontinuierliche Analyse und Zuordnung aller Identitäten
• Entfernung unnötiger Berechtigungen
• Deaktivierung/Entfernung veralteter Konten
• Vermeidung von lokalen Benutzerkonten
• Berechtigungen mit einem vorbestimmten Ablaufdatum

Allgemein sollte immer das Least-Privilege-Prinzip gelten.

CICD-SEC-3: Dependency Chain Abuse

Beispielszenario

Ein Angreifer veröffentlicht ein bösartiges Paket in einem öffentlichen Repository, das den Namen eines internen Pakets in einer Organisation trägt. Wenn Entwickler oder Build-Server das Paket herunterladen, wird das bösartige statt des internen Pakets heruntergeladen und ausgeführt. Das gibt dem Angreifer die Möglichkeit, auf die Umgebung zuzugreifen, in der das Paket ausgeführt wird.

Risiko

Abhängigkeiten werden oft aus einem Verzeichnis geladen. Angreifer können Schwachstellen in Arbeitsstationen und Build-Umgebungen ausnutzen, um dort bösartigen Code zu platzieren. Wie im Szenario beschrieben, kann ebenfalls Code aus zentralen Repositories wie NPM oder PyPi, auf welchen externen Code gelagert wird, betroffen sein.

Massnahmen Die Empfehlung zur Risikoreduzierung ist der Einsatz eines zentralen Artefakt-Systems. Die vom Unternehmen freigegebenen Abhängigkeiten werden auf dieses System geladen und ihre Checksummen sowie Signaturen werden geprüft. Ein Beispiel dafür ist Azure Artifacts.

CICD-SEC-4: Poisoned Pipeline Execution (PPE)

Beispielszenario
Ein Angreifer mit Zugang zu einem SCM-Repository kann das Build-Verfahren manipulieren, indem bösartiger Code in die Konfigurationsdatei der Build-Pipeline eingefügt wird. Der Code wird dann als Teil des Build-Prozesses ausgeführt und kann dazu verwendet werden, auf geheime Informationen zuzugreifen. Beispielsweise können Zugangsdaten zu einem Cloud-Dienst oder anderen Systemen gestohlen werden.

Risiko

PPE-Risiken entstehen, wenn ein Angreifer Source-Control-Systeme infiltriert und bösartigen Code in die Build-Pipeline-Konfiguration einschleust. Durch Continous Integration (CI) und Continous Deployment (CD) wird der Code automatisch kompiliert und ausgeführt, ohne dass es kontrolliert wird.

Massnahmen

Ungeprüfter Code in Pipelines sollte auf isolierten Systemen ausgeführt werden und der Zugriff auf sensible Umgebungen muss begrenzt werden. Das Auslösen von Pipelines auf öffentlichen Repositories sollte kontrolliert werden und unnötige Berechtigungen von Benutzern sollten entfernt werden. CI-Konfigurationsdateien sollten vor der Pipeline-Ausführung überprüft werden.

CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)

Beispielszenario
Ein Angreifer ist in der Lage, einen Pipeline-Job auszuführen, der höhere Berechtigungen hat als erforderlich. In diesem Szenario kann der Angreifer durch das Eindringen in den Pipeline-Job, welcher auf eine Produktionsdatenbank zugreift, Daten und Ressourcen stehlen und diese dann in anderen Teilen des Systems oder sogar in externen Systemen ausnutzen.

Risiko

CI/CD-Systeme, welche Pipelines ausführen, haben oft Zugriff auf sensible Daten und Systeme, sowohl innerhalb als auch ausserhalb der Ausführungsumgebung. Ein Angriff auf die Pipeline-basierte Zugriffskontrolle (PBAC) kann dazu führen, dass Schadcode innerhalb der Pipeline ausgeführt wird und dadurch Zugriff auf vertrauliche Daten und Ressourcen ermöglicht wird.

Massnahmen

Empfohlene Massnahmen zur Begrenzung des Schadens umfassen die Verwendung dedizierter Umgebungen für sensible Pipelines, die Begrenzung von Zugriffsberechtigungen auf erforderliche Ressourcen und die Begrenzung der Netzwerkverbindung der Ausführungsumgebung.

CICD-SEC-6: Insufficient Credential Hygiene

Beispielszenario

Ein Angreifer findet ein öffentliches CI/CD-Repository. Dort werden versehentlich gespeicherte API-Schlüssel und Zugangsdaten zu Cloud-Diensten entdeckt. Mit diesen Zugangsdaten kann der Angreifer nun im CI/CD-System eigene Pipeline-Jobs einrichten, um bösartigen Code in das Build- oder Deployment-Verfahren einzuschleusen.

Risiko

Zugangsdaten werden in verschiedenen Kontexten verwendet, was die Gefahr von unsicherer Nutzung erhöht. Typische Schwachstellen sind beispielsweise:

• Zugangsdaten in Code und Konfigurationsdateien
• Zugangsdaten in Container-Images
• Unsichere Verwendung von Zugangsdaten im Build- und Deployment-Prozess
• Alte, unveränderte Zugangsdaten

Massnahmen

Zu den Empfehlungen zur Verbesserung der Sicherheit gehören die Verwendung temporärer statt statischer Anmeldedaten und die Vermeidung der gemeinsamen Nutzung von Anmeldedaten in verschiedenen Kontexten. Weiterhin wird empfohlen, automatisierte Scanner zu verwenden, welche nach Anmeldeinformationen in den Dateien suchen. Beispiele dafür sind git-secrets von AWS Labs und TruffleHog von Truffle Security.

CICD-SEC-7: Insecure System Configuration

Beispielszenario
Angreifer identifizieren eine Komponente im CI/CD-System, welche eine veraltete Version eines Webservers verwendet. Eine bekannte Schwachstelle dieses Webservers kann ausgenutzt werden, um auf das System zuzugreifen. Sobald Angreifer sich Zugang verschaffen haben, können möglicherweise weitere Angriffe durchgeführt werden, um sich innerhalb des CI/CD-Systems zu bewegen, auf sensible Tokens oder Anmeldeinformationen zuzugreifen und schliesslich bösartige Artefakte in die Produktion zu integrieren.

Risiko
Risiken durch unsichere Systemkonfigurationen können aufgrund von Schwachstellen in den Sicherheitseinstellungen, Konfigurationen und Absicherungen der verschiedenen Systeme im CI/CD-Pipeline-Ökosystem entstehen. Angreifer können dadurch oft leichtes Spiel haben, um ihre Position in der Umgebung auszubauen. Dabei kann es sich um Entwicklermaschinen sowie Server handeln.

Massnahmen

Zur Optimierung der CI/CD-Sicherheit ist es wichtig, sowohl auf den Code und die Artefakte als auch auf die Haltung und Widerstandsfähigkeit jedes einzelnen Systems zu achten. Empfohlene Massnahmen zur Verbesserung der Sicherheit umfassen regelmässige Überprüfungen der Systemkonfigurationen und Updates veralteter Softwareversionen.

CICD-SEC-8: Ungoverned Usage of 3rd Party Services

Beispielszenario
In einem System wird ein unsicheres 3rd Party Framwork verwendet. Angreifer könnten sich über eine ungeregelte Verwendung von Drittanbieter-Services Zugang zu einem CI/CD-System verschaffen, in dem sie das Verzeichnis des Frameworks übernehmen. Sie könnten anschliessend bösartigen Code oder Schadsoftware einbringen, der dann im gesamten Pipeline-System ausgeführt wird.

Risiko

Die CI/CD-Angriffsfläche umfasst sowohl die internen Funktionalitäten als auch die Drittanbieterdienste. Risiken im Zusammenhang mit der ungeregelten Nutzung von Drittanbieterdiensten hängen damit zusammen, dass Drittanbieterdienste problemlos Zugang zu Ressourcen in CI/CD-Systemen erhalten können. Zudem können Systeme von Drittanbietern unbemerkt verändert werden.

Massnahmen

Es ist wichtig, Governance-Kontrollen rund um die Verwendung von Drittanbieterdiensten zu implementieren, um die Sicherheit zu erhöhen. Das kann zum Beispiel durch Signierungschecks gemacht werden.

CICD-SEC-9: Improper Artifact Integrity Validation

Beispielszenario

Angreifer, welche Zugang zu einem System innerhalb des CI/CD-Prozesses haben, laden ein scheinbar harmloses Artefakt hoch, das in Wirklichkeit Schadcode enthält und das richtige Artefakt ersetzt. Wenn keine geeigneten Mechanismen zur Validierung der Integrität der Artefakte vorhanden sind, kann der Schadcode durch den gesamten Prozess fliessen und schliesslich in der Produktionsumgebung ausgeführt werden.

Risiko
Die unzureichende Validierung der Integrität von Artefakten im CI/CD-Prozess kann es einem Angreifer ermöglichen, bösartige Artefakte in den Prozess einzuschleusen. Das heisst, ein von der Pipeline erstelltes Artefakt wird durch einen Angreifer ersetzt.

Massnahmen

Zur Risikominimierung sollten Ressourcen-Integritätsprüfungen erfolgen, z.B. durch Prozesse zur Code-Signierung und Tools zur Überprüfung von Code und Artefakten.

CICD-SEC-10: Insufficient Logging and Visibility

Beispielszenario:

Angreifer haben eines der bereits erwähnten Szenarios ausgenutzt, um Zugriff auf die CI/CD-Systeme zu erlangen. Sie können durch unzureichende Logging- und Sichtbarkeitskontrollen unbemerkt bleiben, während sie bösartige Aktivitäten innerhalb des CI/CD-Systems durchführen.

Risiko

Während eine Organisation in der Regel über umfassende Protokolle und Sichtbarkeitsprogramme für Arbeitsstationen, Server, Netzwerkgeräte und wichtige IT- und Geschäftsanwendungen verfügt, fehlen diese häufig für Systeme und Prozesse in Engineering-Umgebungen. Dadurch ist es nicht möglich, die automatischen Prozesse nachzuvollziehen.

Massnahmen

Es ist wichtig, dass Organisationen starke Protokollierungs- und Sichtbarkeitsfähigkeiten mit Logging haben, um Angriffe zu erkennen und Sicherheitsvorfälle zu untersuchen. Es ist empfohlen, Alarme zu erstellen, um Anomalien und potenziell bösartige Aktivitäten in mehreren Systemen im Prozess zu erkennen.

Fazit

Continous Integration (CI) und Continous Deployment (CD) sind wichtige Prozesse im Lebenszyklus der Softwareentwicklung, welche sicherstellen, dass Änderungen schnell und effizient in die Produktion eingespielt werden können. Es gibt jedoch Risiken wie mangelnde Überwachung und Überprüfung, unsichere Zugangsberechtigungen und Probleme mit Abhängigkeiten. Diese treten vor allem auf, wenn zu viel Vertrauen in die automatisierten Prozesse gelegt wird.

Zusammengefasst gibt es einige Punkte, die besonders beachtet werden müssen. Es wird empfohlen, die Umgebungen auf möglichst niedriger Berechtigung zu halten und zu separieren. Ebenfalls ist es wichtig, stets die Integrität aller internen und externen Komponenten sicherzustellen. Sämtliche Aktivitäten in der Lieferkette müssen protokolliert und kontrolliert werden.

Mit Hilfe der OWASP Top 10 CI/CD lassen sich Sicherheitslücken in der Lieferkette definieren. Das Penetration Testing Team hilft Ihnen, Sicherheitslücken in Ihrer Lieferkette zu finden und Massnahmen zu erheben. Über Ihre unverbindliche Kontaktaufnahme freuen wir uns:

weitere Artikel zum Thema OWASP

• OWASP Top 10:2021 – Kalter Kaffee neu aufgekocht?
• Die OWASP API Top 10 2019
• OWASP IoT Top 10 – Teil 1
• OWASP IoT Top 10 – Teil 2

Quellen

• OWASP Top 10 CI/CD Security Risks, OWASP
• Was ist CI/CD? Konzepte und CI/CD Tools im Überblick, Redhat