Die Einzelheiten dessen, was in CI/CD-Pipelines passiert, sind äußerst undurchsichtig. Wie können Sie sicher sein, dass alles genau so abläuft, wie es beschrieben wird, obwohl Sie die YAML-Konfigurationsdatei geschrieben haben, bei der es sich um die Pipeline-Anweisungsliste handelt? Schlimmer noch: Die meisten Pipelines sind völlig transient, sodass es selbst im Falle einer Fehlfunktion außer den protokollierten Informationen kaum Anhaltspunkte gibt, die möglicherweise Einzelheiten des Problems enthalten oder auch nicht.
Eine schnelle Entwicklung wird durch den Einsatz automatisierter CI/CD-Pipelines (Continuous Integration/Continuous Delivery) erreicht. Trigger oder Zeitpläne zu haben, die Ihren Code automatisch kompilieren, erstellen, testen und versenden, ist fantastisch. Die meisten Pipelines sind jedoch nicht auf Sicherheit ausgelegt, sondern auf Geschwindigkeit und Benutzerfreundlichkeit ausgelegt. Da die Pipelines in der Regel Zugriff auf das Internet benötigen, um Abhängigkeiten und Dateien herunterzuladen, stehen dem Angreifer nach der Kompromittierung einer Pipeline verschiedene Möglichkeiten zur Verfügung, Ihren Betrieb zu stören oder Informationen oder Geheimnisse auszuschleusen.
In diesem Artikel beschreibe ich einige der Best Practices, die Sie zum Schutz Ihrer CI/CD-Pipeline implementieren können. Für unsere Zwecke spielt es keine Rolle, welche Automatisierungstools oder -systeme Sie verwenden – die Sicherheitsprinzipien gelten weiterhin. Sie müssen nur das richtige Werkzeug für die Sicherung dieses Abschnitts Ihrer Pipeline finden.
Was ist die CI/CD-Pipeline (Continuous Integration/Continuous Delivery)?
Eine CI/CD-Pipeline ist ein automatisierter Prozess zum Erstellen, Testen und Veröffentlichen Ihrer Software, Anwendung oder Ihres Artefakts. Diese Pipelines werden immer alltäglicher und komplizierter. Pipelines sind ein hervorragendes Werkzeug zur Steigerung der Teamproduktivität und zur konsistenteren und vorhersehbareren Erstellung von Softwareartefakten. Die Bedeutung der Automatisierung dieser Verfahren wird noch deutlicher, wenn man bedenkt, dass größere Unternehmen möglicherweise über Hunderte miteinander verbundener, choreografierter Pipelines verfügen, deren ordnungsgemäße Funktion alle voneinander abhängig sind.
Das automatische und regelmäßige Erstellen und Testen von Codeänderungen in ein neues Endprodukt wird als kontinuierliche Integration oder CI bezeichnet. Codierungsänderungen werden im Rahmen eines zweistufigen Prozesses namens Continuous Delivery und/oder Deployment (CD) bereitgestellt, getestet und integriert. Durch die kontinuierliche Bereitstellung werden die Updates automatisch in die Produktionsumgebung bereitgestellt, während die kontinuierliche Bereitstellung unmittelbar vor der automatischen Produktionsbereitstellung stoppt. Ob Ihre Pipeline das eine oder das andere verwendet, liegt ganz bei Ihnen und der Art und Weise, wie Ihre Umgebungen und Ergebnisse eingerichtet sind.
Die Bedeutung der CI/CD-Sicherheit für Ihre Software-Lieferkette
Die meisten Unternehmen verlassen sich darauf CI / CD-Werkzeuge zur Automatisierung ihrer Pipelines. Das heißt, wie viele andere auch Angriffe auf die Software-Lieferkette, alles, was die Bösewichte brauchen, ist, ein einzelnes Ziel zu durchbrechen, um einen großen Explosionsradius zu erhalten. Eine der Hauptschwächen besteht darin, dass die Pipeline Abhängigkeiten herunterladen und in das Endprodukt oder Artefakt integrieren muss. Schon eine einzige schlechte Abhängigkeit reicht aus, um einem unerwünschten Element in der Pipeline Fuß zu fassen. Da die Pipeline (je nach Bedarf) Zugriff auf den Quellcode und verschiedene andere Elemente Ihrer Infrastruktur hat, kann eine Rechteausweitung auf fast jeden Teil des in dieser bestimmten Pipeline erstellten Produkts zugreifen und ihn später ändern oder exfiltrieren.
Ein einfaches Beispiel finden Sie in unserer Erklärung zu a Cache- oder Abhängigkeitsvergiftung.
In den letzten Jahren waren mehrere große Unternehmen Opfer von Software-Supply-Chain-Angriffen, deren Ursprung eine CI/CD-Pipeline war. Sie können sich zum Beispiel ansehen Der Verstoß von CircleCI im Januar 2023, Der Kompromiss von Argo CD im Januar 2022, und die Codecove-Verstoß im April 2021.
Die potenziellen Folgen solcher Angriffe sind schwerwiegend. Daher ist es sinnvoll, alles zu tun, um sicherzustellen, dass Ihre Pipelines so sicher wie möglich sind.
Best Practices für CI/CD-Sicherheit
Welche CI/CD-Plattform oder welche Tools Sie auch verwenden, es gibt ein paar Dinge, die Sie tun können, um Ihre Sicherheit zu stärken und den potenziellen Schaden zu verringern, sollte der unwahrscheinliche Fall eintreten, dass es einem feindlichen Akteur gelingt, Zugriff auf Ihre Pipeline oder Ihr Netzwerk zu erhalten.
Überwachung und Alarmierung – Selbst wenn Sie Ihre Techniker darin geschult haben, vor Phishing und anderen Social-Engineering-Betrügereien vorsichtig zu sein, kann es zu einem Sicherheitsverstoß kommen. Da die meisten Pipeline-Umgebungen vorübergehend sind, bleiben nach Abschluss der Arbeit nicht viele Spuren zurück, es sei denn, Sie protokollieren sie aktiv. Stellen Sie bei der Arbeit an jeder PR, Zusammenführung, jedem Build und jedem Test sicher, dass alle an der Umgebung oder den Konfigurationsdateien vorgenommenen Änderungen protokolliert werden. Benutzerdaten sollten zusammen mit allen anderen Daten auch zur Überprüfung protokolliert werden, wenn ein Problem dies erfordert. Ziel ist es, einen Verstoß rekonstruieren und feststellen zu können, was schief gelaufen ist und wie es schief gelaufen ist. Wählen Sie im Voraus die Ereignisse aus, die eine Warnung auslösen sollen, und stellen Sie sicher, dass die entsprechenden Parteien informiert werden. Achten Sie darauf, Einzelpersonen nicht mit sinnlosen oder übermäßig sensiblen Warnungen zu überfordern. Dies könnte zu einer Alarmmüdigkeit führen, die dazu führen würde, dass sie die Alarme einfach ignorieren oder viel später reagieren, als es ratsam wäre.
Nutzen Sie das RBAC-Prinzip kombiniert mit der geringsten Berechtigung – Die Bereitstellung des Zugriffs auf Systemressourcen basierend auf der festgelegten Rolle oder Jobfunktion eines Benutzers innerhalb einer Organisation ist die Grundlage der rollenbasierten Zugriffskontrolle oder RBAC. Benutzern werden in RBAC Rollen zugewiesen, die ihre Zugriffsrechte und Berechtigungen für verschiedene Systemressourcen wie Dateien, Ordner und Programme festlegen. Andererseits bezieht sich das Konzept des geringsten Privilegs auf die Praxis, Benutzern den minimalen Zugriff und die minimalen Privilegien zu gewähren, die zur Erfüllung ihrer beruflichen Aufgaben erforderlich sind. Dies bedeutet, dass Benutzer nur die Ressourcen verwenden dürfen, die für die Erledigung der ihnen zugewiesenen Aufgaben erforderlich sind, und nicht mehr. Least Privilege und RBAC werden häufig gemeinsam als komplementäre Sicherheitskonzepte eingesetzt. Das Least-Privilege-Prinzip stellt sicher, dass Benutzer nur Zugriff auf die minimale Menge an Ressourcen haben, die für die Erfüllung ihrer jeweiligen Aufgaben erforderlich sind, und RBAC weist Rollen zu, die Benutzern die richtige Menge an Zugriff auf die Ressourcen gewähren, die sie für die Ausführung ihrer Aufgaben benötigen, und nicht mehr . In Kombination tragen diese Richtlinien dazu bei, ein gut gewartetes, relativ sicheres System aufrechtzuerhalten. Als zusätzliche Sicherheitsebene können Sie es so konfigurieren, dass für wichtige Systemaktionen mehrere Benutzerberechtigungen erforderlich sind. Diese Strategie sollte mit Vorsicht angewendet werden, da sie zu einer spürbaren Verzögerung des Entwicklungsprozesses führen kann.
Bewahren Sie die Herkunft der Pipeline als unveränderliches Protokoll auf – Überprüfbare Informationen über Softwareartefakte, die beschreiben, wo, wann und wie etwas erstellt wurde, werden als Provenienz bezeichnet. Wenn Sie genau wissen, welche Dateien in einer Pipeline eingegeben wurden und was mit ihnen passiert ist, können Sie eine Herkunftsdatei erstellen, um ein fälschungssicheres Protokoll dieser Pipeline zu erstellen. Um sicher zu sein, muss die Herkunft unabhängig von jedem Benutzer erstellt werden, da alles, was ein Benutzer stören oder ändern kann, nicht völlig vertrauenswürdig ist. Valint des Schreibers ermöglicht es Ihnen, Herkunft feststellen in Ihrer Pipeline für eine breite Palette von SCM-Systemen. Auf jede Herkunftsdatei (JSON) kann später zugegriffen werden, sodass Sie sie überprüfen können, um festzustellen, ob etwas Unerwartetes oder Unerwünschtes passiert ist. Im Mittelpunkt steht übrigens die Generierung und Verwaltung von Herkunftsdateien aus allen Ihren Pipelines SLSA-Framework.
Nutzen Sie Ihre SBOM voll aus – Für den Fall, dass Sie einige der potenziellen Verwendungsmöglichkeiten verpasst haben, könnte eine am Ende der Pipeline erstellte SBOM dabei helfen, alle verwendeten Open-Source-Pakete aufzulisten. Ein Vergleich dieser Liste mit bekannten CVEs könnte Ihnen Aufschluss darüber geben, welche potenziellen Schwachstellen in Ihrem Endprodukt bestehen. Sie können die Liste auch verwenden, um zu überprüfen, ob Sie noch veraltete Versionen von Open-Source-Paketen verwenden, und sogar so etwas wie das verwenden OpenSSF-Scorecard um den Zustand der von Ihnen verwendeten Pakete zu überprüfen. Da ständig neue CVEs ans Licht kommen, sollten Sie im Gegensatz zu einem einmaligen SAST über einen Service verfügen, der Sie darüber informiert, ob in einem Ihrer vorhandenen Pakete ein neues CVE entdeckt wurde. Der Service von Scribe kann Ihnen dabei helfen, all das automatisch zu erledigen.
Überprüfen Sie die Einhaltung Ihrer Richtlinien – Jedes Unternehmen und manchmal auch jede Pipeline hat Richtlinien, die umgesetzt werden müssen, um sicherzustellen, dass alles in Ordnung ist. Einige Richtlinien sind generisch (z. B. die Sicherstellung, dass es einen Zwei-Personen-Verifizierungsprozess gibt), andere sind einzigartig (z. B. die Sicherstellung, dass Mike die neueste Änderung abzeichnet, bevor wir sie an die Produktion senden). Mithilfe des kryptografischen Signierungsüberprüfungsmechanismus und einer eindeutigen Richtliniendatei können Sie jetzt die erforderlichen Richtlinien in jede Pipeline einbinden und (für sich selbst und andere) überprüfen, ob sie durchgeführt wurden. Es handelt sich um eine menschliche Schwäche, die, wenn sie betont wird, dazu führen kann, dass einige Anforderungen übersprungen und einige Regeln verbogen werden, um eine Frist einzuhalten. Mit dieser Maßnahme können die Menschen die Regeln nicht mehr missachten, und das sollte dazu beitragen, die Sicherheit Ihrer Pipeline sowohl vor Bedrohungen von innen als auch von außen aufrechtzuerhalten. Scribe hat eine neuartige Möglichkeit entwickelt, solche Richtlinien durchzusetzen und Ihnen sogar das Verfassen eigener Richtlinien zu ermöglichen. Hör zu Hier .
Sichern Sie die Anweisungsdatei der Pipeline – Bedrohungsakteure können die CI-Pipeline „vergiften“, indem sie eine Technik namens „Poisoned Pipeline Execution“ (PPE) verwenden, die im Wesentlichen die Pipeline-Stufen oder ihre Reihenfolge, wie ursprünglich in der Pipeline-Anweisungsdatei angegeben, ändert. Die Methode manipuliert den Build-Prozess, indem sie Berechtigungen in SCM-Repositorys (Source Code Management) missbraucht. Durch das Einfügen von Schadcode oder Befehlen in die Build-Pipeline-Einstellungen ist es möglich, die Pipeline zu vergiften und die Ausführung von Schadcode zu bewirken, während der Build abgeschlossen wird. Sie werden nicht feststellen können, dass Ihre Builds nicht wie beabsichtigt funktionieren, bis Sie die Pipeline-Anweisungsdatei überprüft haben. Um sicherzustellen, dass Ihre Pipelines wie beabsichtigt ausgeführt werden, sollten Sie die Anweisungsdatei vor jeder Ausführung überprüfen. Kryptografisch gesehen ist das Signieren der Datei und das Hinzufügen der Signaturüberprüfung als erster Schritt der Pipeline eine Möglichkeit, diese Sicherheit zu erreichen. Valint des Schreibers unterschreiben und überprüfen Funktionen sind eine Möglichkeit, zu überprüfen, ob Ihre Anweisungsdatei unverändert geblieben ist, bevor Sie eine neue Pipeline-Ausführung starten.
Sichern Sie sich Ihr Endergebnis – Warum sollte ein Angreifer hart arbeiten, um Ihre Pipeline zu stören, wenn es doch viel einfacher ist, Ihr Endprodukt durch eine betrügerische Version zu ersetzen? Da bei solchen Angriffen offenbar das erzeugende Unternehmen die Quelle des Bildes ist, reicht es nicht aus, dass dieses Unternehmen über ein gültiges Zertifikat zum Schutz verfügt. Vereinfacht ausgedrückt würde es die Glaubwürdigkeit der Fälschung erhöhen. Die Lösung besteht darin, das endgültige von der Pipeline erzeugte Artefakt kryptografisch zu signieren und dem Endbenutzer die Überprüfung dieser Signatur zu ermöglichen. Scribe's Valint kann verwendet werden unterschreiben und überprüfen eine große Vielfalt an Artefakten, die Ihnen die zusätzliche Sicherheit geben, dass Ihre Benutzer genau das bekommen, was Sie für sie vorgesehen haben.
In die Zukunft schauen
Niemand wird auf Automatisierungstechniken wie CI/CD verzichten, um seine Arbeit zu beschleunigen. Ganz im Gegenteil: In der Welt, in der wir leben, drängen wir immer auf immer schnellere Software-Update-Iterationen. Wir sollten zumindest darauf achten, dass wir die Aufgabe mit Vorsicht angehen und dabei darauf achten, weder unsere Produktionsumgebung noch unseren Quellcode zu gefährden.
Entscheidend ist, die möglichen Konsequenzen zu berücksichtigen, wenn sich jemand illegalen Zugriff auf Ihre Pipeline, Ihre Umgebung oder Ihren Quellcode verschafft. Ich bin mir sicher, dass Sie die geeigneten Maßnahmen ergreifen können, um potenzielle Lecks zu stoppen oder abzumildern, sobald Sie erkennen, wie gefährlich sie sein können und wo Ihre Pipelines und Ihr Netzwerk am anfälligsten sind.
Da die Komplexität miteinander verbundener Pipelines immer weiter zunehmen wird, ist es von entscheidender Bedeutung, die Sicherheit Ihrer gesamten Umgebung (segmentiertes Netzwerk, RBAC, Zero Trust usw.) als ersten Schritt zum Schutz Ihrer Pipelines aufrechtzuerhalten. Versuchen Sie anschließend, solide, nicht fälschbare Beweise zu erstellen und kryptografisches Signieren und Verifizieren von Daten einzusetzen, um das Potenzial eines Angriffs auf die Software-Lieferkette, der Ihre Pipeline oder den Cache Ihrer Pipeline vergiften könnte, so weit wie möglich einzudämmen. Wenn Sie wachsam und misstrauisch bleiben, kann dies Ihrem Unternehmen unzählige Kopfschmerzen ersparen.
Diese Inhalte werden Ihnen von Scribe Security zur Verfügung gestellt, einem führenden Anbieter von End-to-End-Sicherheitslösungen für die Software-Lieferkette, der modernste Sicherheit für Code-Artefakte sowie Code-Entwicklungs- und Bereitstellungsprozesse in der gesamten Software-Lieferkette bietet. Weitere Informationen.
Zusammenhängende Artikel
