CI/CD-Pipelines sind bekanntermaßen undurchsichtig, was genau darin geschieht. Selbst wenn Sie derjenige sind, der die YAML-Konfigurationsdatei (die Pipeline-Anweisungsliste) geschrieben hat, wie können Sie dann sicher sein, dass alles genau wie beschrieben abläuft? Schlimmer noch: Die meisten Pipelines sind völlig vergänglich. Selbst wenn etwas Schlimmes passiert, bleiben danach keine Spuren zurück.
Vereinfacht ausgedrückt ist eine Pipeline eine automatisierte Möglichkeit zum Testen, Erstellen und Veröffentlichen Ihrer Software, App oder Ihres Artefakts. Solche Pipelines werden immer häufiger und komplizierter. Pipelines eignen sich hervorragend, um Teams schneller arbeiten zu lassen und bei der Erstellung ihrer Softwareartefakte konsistentere und vorhersehbarere Ergebnisse zu liefern. Die Bedeutung der Automatisierung dieser Prozesse wird noch deutlicher, wenn man bedenkt, dass größere Unternehmen möglicherweise über Hunderte orchestrierter Pipelines verfügen, die voneinander abhängig sind. Daher ist es wichtig, dass alles reibungslos und fehlerfrei läuft.
Als letztes Glied im Entwicklungsprozess zwischen den Entwicklern und dem Endbenutzer oder Kunden wird meiner Meinung nach nicht ausreichend darauf geachtet, wie solche automatisierten Prozesse als potenzielle Angriffsvektoren genutzt werden könnten. Der Zugriff auf eine Build-Pipeline könnte es böswilligen Akteuren ermöglichen, nicht nur in das System des produzierenden Unternehmens einzudringen, sondern möglicherweise auch das resultierende Artefakt so zu modifizieren, dass alle zukünftigen Benutzer betroffen sind, wodurch ein riesiger Explosionsradius entsteht, der oft als bezeichnet wird Angriff auf die Software-Lieferkette.
In einem früheren Artikel haben wir die Grundsätze besprochen, die Ihnen als Leitfaden dienen sollten Sichern Sie Ihre CI/CD-Pipeline. In diesem Artikel werde ich einige der häufigsten potenziellen Schwachstellen in einer CI/CD-Pipeline behandeln und einige Korrekturoptionen anbieten. Für unsere Zwecke spielt es keine Rolle, welche Automatisierungstools oder -systeme Sie verwenden – die Sicherheitsprinzipien gelten weiterhin, Sie müssen nur das richtige Tool für die Sicherung dieses Abschnitts Ihrer Pipeline finden.
Die Kunst des CI/CD beherrschen: Die Schlüsselelemente, die Sie nicht ignorieren dürfen
Unterschiedliche Pipelines bestehen aus unterschiedlichen Elementen und verwenden unterschiedliche Tools. Die Elemente, auf die ich mich konzentriert habe, sind für fast jede Pipeline relevant, daher kann die Sicherung dieser Elemente als bewährte Methode angesehen werden, unabhängig von Ihrem SCM, Ihren Tools oder Ihrem vorhandenen Sicherheitssetup.
Geheime Verwaltung – Geheimnisse sind normalerweise Zeichenfolgen oder Token, die zum Verbinden Ihrer Software oder Pipeline mit anderen Ressourcen verwendet werden. Ein häufiges Beispiel sind die API-Schlüssel, mit denen Sie Ihren Code mit AWS-Ressourcen wie einem S3-Bucket verbinden. Die meisten Menschen wissen bereits, dass sie diese Geheimnisse geheim halten und sie nicht als Klartext in ein offenes Repository aufnehmen sollten. Innerhalb einer CI/CD-Pipeline sind die Dinge etwas komplizierter. Normalerweise benötigt die Pipeline Zugriff auf diese Geheimnisse, um auf die Ressourcen und Informationen zugreifen zu können, die sie darstellen. Das bedeutet, dass jeder, der Zugriff auf die Vorgänge in Ihrer Pipeline hat, möglicherweise Ihre Geheimnisse sehen und kopieren kann. Eine Möglichkeit, Ihre Geheimnisse auch innerhalb Ihrer Pipeline zu schützen, ist die Verwendung eines Geheimnisse-Management-Tools wie Hashicorp-Tresor. Solche Tools können nicht nur Ihre Geheimnisse sogar innerhalb Ihrer Pipeline verschleiern, sondern sie machen es auch viel einfacher, Ihre Geheimnisse zu rotieren, sodass Sie sie regelmäßig ändern können, was den Diebstahl von Geheimnissen aus einer Pipeline wertlos macht. Unabhängig davon, für welches Secrets-Management-Tool Sie sich entscheiden, kann die regelmäßige Rotation Ihrer Secrets als gute Sicherheitspraxis angesehen werden.
Poisoned Pipeline Execution (PPE) - Poisoned Pipeline Execution (PPE) ist eine Technik, die es Bedrohungsakteuren ermöglicht, die CI-Pipeline zu „vergiften“ – also die Pipeline-Schritte oder deren Reihenfolge entsprechend der Definition in der Pipeline-Anweisungsdatei zu ändern. Die Technik missbraucht Berechtigungen in SCM-Repositorys (Source Code Management), um den Build-Prozess zu manipulieren. Es ermöglicht das Einschleusen von bösartigem Code oder Befehlen in die Build-Pipeline-Konfiguration, wodurch die Pipeline so vergiftet wird, dass während des Build-Prozesses bösartiger Code ausgeführt wird. Wenn Sie die Pipeline-Anweisungsdatei nicht vor jedem Build überprüfen, tappen Sie höchstwahrscheinlich im Dunkeln darüber, dass Ihre Builds nicht mehr wie angegeben ausgeführt werden. Selbst eine geringfügige Änderung, beispielsweise der Aufruf einer Bibliothek gegenüber einer anderen, kann weitreichende Auswirkungen haben, beispielsweise die Einbeziehung von Hintertüren oder Krypto-Minern in das Endprodukt.
Eine Möglichkeit, PPE zu vermeiden, besteht darin, zu überprüfen, ob die Pipeline-Anweisungsdatei unverändert ist. Sie können die Datei kryptografisch signieren und die Signaturüberprüfung als ersten Schritt jeder Pipeline hinzufügen. Ein Tool, mit dem Sie Dateien signieren und überprüfen können, ist Valint, ein von Scribe Security veröffentlichtes Tool. Welches Tool zur Signierungsüberprüfung Sie auch verwenden, die Idee besteht darin, sicherzustellen, dass die Integrität Ihrer Befehlsdatei intakt bleibt.
Cache-/Abhängigkeitsvergiftung – CI/CD-Pipeline-Workflows werden häufig verwendet, um bestimmte Aktionen anzugeben, die ausgeführt werden müssen. Jeder Workflow besteht aus einer Reihe von einem oder mehreren Jobs, die als Abfolge von Aktionen charakterisiert werden. Die meisten Workflows teilen aus Sicherheitsgründen keine Ressourcen. Es gibt jedoch Workarounds für den Fall, dass die gemeinsame Nutzung von Ressourcen erforderlich wird. Ein Cache, auf den alle Workflows gleichermaßen zugreifen können, ist eine solche Problemumgehung. Da der Cache von mehreren Workflows gemeinsam genutzt wird, genügt ein Verstoß in einem Workflow mit der Berechtigung, ihn zu ändern, damit der Cache für alle nachfolgenden Workflow-Verwendungen schädlich wird. Ein einzelner vergifteter Cache kann sehr lange aktiv sein und sich auf unzählige Iterationen von Software-Builds auswirken, die in dieser Pipeline ausgeführt werden, da der Cache nur dann aktualisiert wird, wenn ein neues Artefakt oder Paket heruntergeladen werden muss.
Genau wie bei der Überprüfung der Pipeline-Anweisungsdatei können Sie diese verwenden Valint um Ihren Cache oder einen Ordner zu signieren und später zu überprüfen, der alle vorab genehmigten Abhängigkeiten enthält, die Ihre Pipeline benötigt. Wenn Sie der paranoide Typ sind, ist es ein todsicherer Weg, Ihrer Pipeline zu erlauben, sich unabhängig mit dem Internet zu verbinden und alle Bibliotheken herunterzuladen, die sie für erforderlich hält, um mehr Schwachstellen und mögliche Exploits in Ihren endgültigen Build zu integrieren.
SSH-Schlüssel – Ein SSH-Schlüssel ist eine Zugangsberechtigung für das Netzwerkprotokoll SSH (Secure Shell). Dieses Netzwerkprotokoll wird für die Fernkommunikation zwischen Maschinen auf einem verwendet Ungesichertes offenes Netzwerk. SSH wird für die Remote-Dateiübertragung, die Netzwerkverwaltung und den Remote-Betriebssystemzugriff verwendet. Mit SSH-Schlüsseln können Sie beispielsweise eine Verbindung zu GitHub herstellen, ohne bei jedem Besuch Ihren Benutzernamen und Ihr persönliches Zugriffstoken angeben zu müssen. Sie können Commits auch mit einem SSH-Schlüssel signieren. Sie können auch andere Anwendungen mit SSH-Schlüsseln wie z. B. mit Ihrem GitHub verbinden Bit Bucket und Gitlab.
Um die Sicherheit Ihres Kontos zu gewährleisten, sollten Sie Ihre SSH-Schlüsselliste regelmäßig überprüfen und alle ungültigen oder kompromittierten Schlüssel widerrufen/löschen. Für GitHub finden Sie Ihre Liste der SSH-Schlüssel auf der folgenden Seite:
Access Einstellungen > SSH- und GPG-Schlüssel
Ein Tool, das Ihnen helfen kann, den Überblick über Ihre SSH-Schlüssel zu behalten, ist ein Open-Source-Sicherheitsstatusbericht namens GitGat. Der GitGat-Bericht benachrichtigt Sie, wenn einer Ihrer konfigurierten SSH-Schlüssel abgelaufen oder ungültig ist. GitHub empfiehlt nicht nur, Ihre Schlüssel genau im Auge zu behalten und sie häufig zu wechseln, sondern warnt auch davor, einen SSH-Schlüssel, mit dem Sie nicht vertraut sind, sofort zu löschen und Kontakt aufzunehmen GitHub-Unterstützung für weitere Hilfe. Ein nicht identifizierter öffentlicher Schlüssel kann auf eine mögliche Sicherheitsverletzung hinweisen.
SLSA-Provenienz als unveränderliches Pipeline-Protokoll - SLSA steht für Supply Chain Levels for Software Artifacts und ist ein Framework, das von Google und anderen Industriepartnern entwickelt wurde, um die Sicherheit und Integrität von Software-Lieferketten zu verbessern.
SLSA definiert eine Reihe von vier Ebenen, von denen jede ein höheres Maß an Vertrauen und Sicherheit in der Software-Lieferkette darstellt. Jede Stufe stellt eine zunehmende Stufe der Sicherheitsanforderungen dar. Eine wichtige Anforderung ist die Notwendigkeit der Aktenherkunft. Für das SLSA-Framework:
Provenienz ist die überprüfbare Information über Softwareartefakte, die beschreibt, wo, wann und wie etwas hergestellt wurde. Da der Hauptzweck einer CI/CD-Pipeline darin besteht, etwas zu produzieren (normalerweise einen Build), ist die Möglichkeit, genau zu verfolgen, welche Dateien eingegangen sind und was mit ihnen passiert ist, eine Art unverfälschtes Maschinenprotokoll der Pipeline. Zu diesem Zweck ist es wichtig, dass die SLSA-Herkunft unabhängig von jedem Benutzer erstellt wird. Die Integrität von allem, was ein Benutzer unterbrechen oder ändern kann, kann fraglich sein.
Ein Tool, mit dem Sie eine SLSA-Herkunft in Ihrer Pipeline für eine Vielzahl von SCM-Systemen erstellen können, ist Valint (Ja, das gleiche Tool von Scribe – es ist ein sehr vielseitiges Tool). Der Link zeigt Ihnen, wie Sie Valint mit Ihrer GitHub-Pipeline verbinden, um für jeden Build-Lauf auf dieser Pipeline eine SLSA-Herkunft zu generieren. Sie können später auf jede Herkunftsdatei zugreifen und sie überprüfen, um festzustellen, ob etwas Unvorhergesehenes oder Unerwartetes passiert ist. Hier ist ein Ausschnitt aus einer solchen Provenienzdatei:
Die Herkunftsdatei ist nur eine JSON-Datei, aber da es (noch) keine automatisierten Tools zum Lesen von Herkunftsdateien gibt, liegt die Aufgabe, sie zu lesen und zu interpretieren, bei Ihnen.
Sichern Sie Ihr Endergebnis – Einer der bekanntesten Verstöße in der Software-Lieferkette der letzten Zeit ist der SolarWinds-Vorfall. Darin haben die Hacker Code auf dem Build-Server so geändert, dass jeder von der Firma veröffentlichte Build eine geheime Hintertür enthielt. Ein weiterer berühmter Fall der Verfälschung des Endergebnisses ist der sogenannte „Vietnam Government Certificate Authority (VGCA)“-Hack im Jahr 2020 Operation SignSight. Die Eindringlinge infiltrierten die VGCA-Website und leiteten Download-Links zu ihrer eigenen, mit Malware infizierten Version der Software um. In beiden Fällen hatten die Endbenutzer keine Möglichkeit zu überprüfen, ob die Software, die sie erhielten, die Software war, die das produzierende Unternehmen veröffentlichen wollte.
Ein einfacherer Angriff könnte darin bestehen, das am Ende der Pipeline erstellte endgültige Image durch ein böswilliges Image zu ersetzen und das fehlerhafte Image dorthin hochzuladen, wo es hingehört. Da bei den meisten dieser Angriffe das Bild angeblich von der produzierenden Firma stammt, reicht es nicht aus, selbst wenn diese Firma durch ein gültiges Zertifikat geschützt ist. Es würde die Fälschung nur noch glaubwürdiger machen.
Auch hier besteht die Lösung darin, das von der Pipeline letztendlich erzeugte Artefakt kryptografisch zu signieren und dem Endbenutzer die Überprüfung dieser Signatur zu ermöglichen.
Da ich bereits erwähnt habe Valint Ich schlage die Verwendung von Open Source vor Cosign von Sigstore. Ziel von Cosign ist es, das Signieren zu vereinfachen, indem es die Notwendigkeit einer wichtigen Infrastruktur überflüssig macht. Es ermöglicht dem Benutzer, seine online verifizierte Identität (z. B. Google, GitHub, Microsoft oder AWS) als Schlüssel zu verwenden. Sie können Cosign sowohl zum Signieren als auch zum Überprüfen von Bildern verwenden, was es ideal für das Signieren und spätere Überprüfen des endgültig erstellten Images einer Pipeline macht.
Unabhängig davon, ob Sie sich für die Verwendung von Valint oder Cosign entscheiden, ist es eine Idee, die Ihren Benutzern die Überprüfung einer kryptografischen Signatur auf Ihrem endgültigen Artefakt ermöglichen soll, um sicherzustellen, dass sie genau das erhalten, was Sie liefern wollten. Ich bin mir sicher, dass die meisten Endbenutzer die Idee zu schätzen wissen würden.
Pipeline-Sicherheit in der Zukunft
Es gibt natürlich auch andere Elemente in einer Build-Pipeline, die von zusätzlicher Sicherheit profitieren könnten. In diesem Artikel habe ich mich entschieden, einige der offensichtlicheren und einige der anfälligeren Pipeline-Elemente zu betrachten.
Unabhängig davon, welches Pipeline-Tool oder welche Infrastruktur Sie verwenden, stellen Sie sicher, dass Sie die Möglichkeit eines Verstoßes im Auge behalten. Vertrauen Sie niemals blind einem System, das Ihnen sagt, dass es absolut sicher ist.
Angesichts der zunehmenden Bedrohung durch Identitätsdiebstahl, Spear-Phishing und andere Formen der Fälschung legitimer Zugriffe sind wir der Meinung, dass der Sign-Verification-Mechanismus ein gutes, vielseitiges Tool für Ihren digitalen Werkzeugkasten ist.
Unabhängig davon, ob Sie ein Bild, eine Datei oder einen Ordner signieren müssen, lade ich Sie ein, sich Valint von Scribe Security als Komplettlösung für solche Anforderungen genauer anzusehen.
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
