CI/CD-Workflows: Ist Ihre Umgebung durch einen neuen Angriff gefährdet?

CI/CD-Pipelines (Continuous Integration/Continuous Deployment) automatisieren zwar die Softwareentwicklung, das Testen und die Veröffentlichung, laufen aber auch mit erhöhten Berechtigungen, speichern Produktionsgeheimnisse und integrieren nicht vertrauenswürdigen Code aus externen Quellen. Sicherheitsforscher demonstrierten, dass für den Zugriff auf ein großes Open-Source-Projekt lediglich die Korrektur eines Tippfehlers erforderlich war. Anschließend konnte ein bösartiger Pipeline-Workflow in der Build-Infrastruktur verbleiben und Authentifizierungstoken exfiltrieren. Die empfohlene Vorgehensweise: Pipeline-Berechtigungen überprüfen, Geheimnisse in ein dediziertes Geheimnismanagementsystem auslagern, die Codesignierung aller Pipeline-Ausgaben erzwingen und die Build-Infrastruktur wie ein produktionsnahes System mit denselben Zugriffskontrollen behandeln.

Kurzantwort: Sind CI/CD-Umgebungen angreifbar?

Ja, und die Angriffsfläche ist größer, als den meisten Organisationen bewusst ist. Eine CI/CD-Pipeline ist nicht nur ein Build-Tool: Sie läuft mit erweiterten Berechtigungen auf der Build-Infrastruktur, hat Zugriff auf Codesignaturschlüssel, Zugangsdaten für die Produktionsbereitstellung und Cloud-API-Token und wird durch Ereignisse wie Pull Requests ausgelöst, die von jedem mit minimalen Repository-Zugriffsrechten initiiert werden können. Die Angriffe sind nicht theoretisch: Kompromittierung selbstgehosteter Runner, Abhängigkeitsmanipulation, Offenlegung von Geheimnissen durch Build-Logs und das Einschleusen bösartiger Workflows wurden bereits in dokumentierten Vorfällen ausgenutzt, die weit verbreitete Open-Source-Projekte und Unternehmensumgebungen betrafen. Der Sonatype-Bericht „State of the Software Supply Chain 2026“ prognostiziert über 454,600 neue bösartige Open-Source-Pakete im Jahr 2025 – ein Anstieg von 75 % gegenüber dem Vorjahr. Die meisten dieser Angriffe zielen auf die automatisierte Auflösung von Abhängigkeiten in Build-Pipelines ab.

Was ist CI/CD?

CI/CD steht für Continuous Integration und Continuous Deployment (oder Continuous Delivery). Es handelt sich um einen automatisierten Workflow, der Code vom Commit eines Entwicklers über die Build-, Test- und Deployment-Phasen bis hin zur Bereitstellung durchführt, ohne dass manuelle Übergaben zwischen den einzelnen Schritten erforderlich sind.

Continuous Integration (CI) automatisiert das Zusammenführen von Codeänderungen und das Ausführen von Tests. Jeder Commit in einem gemeinsamen Repository löst einen automatisierten Build und Testlauf aus, wodurch Integrationsfehler frühzeitig erkannt werden, anstatt sie erst bei der Veröffentlichung zu entdecken. Continuous Deployment (CD) erweitert dies durch die automatische Bereitstellung von Code, der die Tests bestanden hat, in Produktions- oder Staging-Umgebungen. Dadurch können Unternehmen mehrmals täglich anstatt in festen Release-Zyklen veröffentlichen.

Gängige CI/CD-Plattformen sind GitHub Actions , Jenkins , GitLab CI, CircleCI und Buildkite. Sie alle stehen vor derselben grundlegenden Sicherheitsherausforderung: Um ihre Aufgaben zu erfüllen, benötigen sie privilegierten Zugriff auf Build-Systeme, Deployment-Umgebungen, Signaturschlüssel und Produktionszugangsdaten.

Warum CI/CD-Pipelines ein wertvolles Angriffsziel darstellen

Ein erfolgreicher Angriff auf eine CI/CD-Pipeline gefährdet nicht nur eine einzelne Anwendung. Er untergräbt die Vertrauensinfrastruktur, auf die alle nachgelagerten Nutzer angewiesen sind. Kann ein Angreifer Code in eine Build-Pipeline einschleusen, ist jedes von dieser Pipeline erzeugte Artefakt potenziell schädlich, und jeder Benutzer oder jede Organisation, die diese Artefakte installiert, erhält den Schadcode über einen legitimen, vertrauenswürdigen Kanal.

Der PyTorch-Vorfall hat dies eindrücklich verdeutlicht. PyTorch ist ein Framework für maschinelles Lernen mit einem Marktanteil von rund 21 % im ML-Bereich. Als Forscher im Rahmen eines Sicherheitsforschungsprojekts die CI/CD-Pipeline von PyTorch angriffen, demonstrierten sie, welch weitreichende Folgen eine Kompromittierung einer einzigen Pipeline haben kann: Jedes Projekt, jedes Unternehmen und jedes Modell, das auf PyTorch basiert, wäre potenziell betroffen gewesen, wenn die Forscher böswillig und nicht verantwortungsbewusst gehandelt hätten.

CI/CD-Pipelines vereinen mehrere Eigenschaften, die sie zu attraktiven Zielen machen. Sie führen automatisierte Prozesse mit erweiterten Berechtigungen aus, die nicht kontinuierlich von menschlichen Bedienern überwacht werden. Sie integrieren Code und Abhängigkeiten aus externen Quellen im Rahmen ihrer normalen Funktion. Sie speichern Zugangsdaten für Produktionssysteme. Und sie sind häufig mit permissiven Standardeinstellungen konfiguriert, die eher auf Benutzerfreundlichkeit als auf Sicherheit ausgelegt sind.

CI/CD-Bedrohungsmodell: Angriffsvektoren und Kontrollmaßnahmen

Angriffsvektor	So funktioniert’s	Beispiel aus der Praxis	Primäre Kontrolle
Kompromiss beim selbstgehosteten Runner	Angreifer erlangt Zugriff auf Mitwirkende, reicht Pull-Anfrage mit bösartigem Workflow ein; Runner führt diese aufgrund von Standardeinstellungen vor der Merge-Genehmigung aus.	Forscher demonstrierten dies anhand der GitHub Actions-Pipeline von PyTorch unter Verwendung selbstgehosteter Runner.	Deaktiviere den Zugriff von selbstgehosteten Runnern für Fork-Pull-Requests; fordere eine manuelle Genehmigung an, bevor Workflows von externen Mitwirkenden ausgeführt werden.
Abhängigkeitsvergiftung	Ein schädliches Paket wurde in einem öffentlichen Repository veröffentlicht (Typosquatting, Kontokompromittierung oder Abhängigkeitskonflikt); die CI-Pipeline lädt es herunter und führt es aus.	Sonatype identifizierte im Jahr 2025 mehr als 454,600 schädliche Open-Source-Pakete (75 % Steigerung gegenüber dem Vorjahr).	Abhängigkeitsfixierung mit Hash-Verifizierung; private Paketspiegelung; Software Composition Analysis (SCA) in der Pipeline
Offenlegung von Geheimnissen in Bauprotokollen	Pipeline protokolliert API-Schlüssel, Token oder Anmeldeinformationen während der Build-Schritte im Klartext; die Protokolle sind für alle Repository-Mitarbeiter zugänglich.	GitHub-Forscher identifizierten im März 2024 13 Millionen API-Geheimnisse, die über öffentliche Repositories offengelegt wurden.	Nutzen Sie die Geheimnisverwaltung der Plattform; geben Sie Geheimnisse niemals auf stdout aus; durchsuchen Sie Build-Protokolle nach Anmeldeinformationsmustern.
Schädliche Workflow-Einschleusung	Angreifer modifiziert Workflow-YAML-Dateien in einem Branch oder Fork, um Schritte hinzuzufügen, die Geheimnisse exfiltrieren oder Build-Ausgaben verändern.	Ähnliches Muster wie beim selbstgehosteten Runner-Angriff; Workflow-Dateien in Forks werden vor der Überprüfung ausgeführt.	Workflow-Dateien mit Zweigschutzregeln schützen; Workflow-Änderungen müssen vom Code-Inhaber genehmigt werden
Gefährdete Handlungen Dritter	Ein CI/CD-Workflow verweist auf eine externe Aktion, die später von einem kompromittierten Wartungskonto geändert wird.	Dokumentiertes Muster in der Lieferkettenforschung: Das Festlegen von SHA-Werten anstelle von Tags ist die Minderungsmaßnahme.	Alle Aktionen von Drittanbietern an bestimmte Commit-SHAs binden; alle externen Aktionen vor der Verwendung prüfen
Persistenz der Infrastruktur aufbauen	Der vom Runner ausgeführte Schadcode verbleibt auf dem Host-Rechner und beeinträchtigt zukünftige Builds, ohne dass der ursprüngliche Angriff erneut ausgelöst werden muss.	Wie die GitHub Actions-Studie gezeigt hat: Runner bleiben auf dem Host aktiv und beeinflussen weiterhin Builds.	Kurzlebige Runner, die bei jedem Build zerstört und neu erstellt werden; Runner-Isolation mithilfe von Containern oder VMs

So funktioniert der Self-Hosted Runner Attack: Schritt für Schritt

Sicherheitsforscher demonstrierten eine spezifische Angriffskette gegen selbstgehostete GitHub Actions-Runner, die die strukturelle Schwachstelle in Standard-Pipeline-Konfigurationen verdeutlicht. Der Angriff verläuft wie folgt:

1. Erreichen Sie den Status eines Mitwirkenden: Die Forscher erlangten Mitwirkendenstatus in einem großen Open-Source-Projekt, indem sie einen Tippfehler in der Dokumentation korrigierten. Die Korrektur eines Tippfehlers genügt in vielen großen Projekten, um den Mitwirkendenstatus zu erhalten.
2. Reichen Sie einen Pull Request mit einem schädlichen Workflow ein: Mit dem Status eines Mitwirkenden erstellt der Angreifer einen Fork und fügt eine manipulierte GitHub Actions-Workflow-Datei hinzu. Standardmäßig löst ein Pull Request eines Mitwirkenden den CI/CD-Workflow des Projekts aus, einschließlich des Zugriffs auf den selbstgehosteten Runner, bevor der Pull Request geprüft oder genehmigt wird.
3. Führe bösartigen Code auf dem Runner aus: Der schädliche Workflow läuft auf dem selbstgehosteten Runner, der auf dem Host-Rechner mit erhöhten Berechtigungen ausgeführt wird. Der Runner kann nicht zwischen einem legitimen und einem schädlichen Workflow unterscheiden, da beide im gleichen YAML-Format vorliegen und über denselben Pull-Request-Mechanismus übermittelt werden.
4. Protokollierung der Authentifizierungstoken: Der schädliche Workflow erfasst die in der Runner-Umgebung verfügbaren Authentifizierungstoken. Diese Token ermöglichen den vollständigen Zugriff auf das Repository, einschließlich der Berechtigung, Code zu übertragen, Releases zu ändern, auf Geheimnisse zuzugreifen und zusätzliche Workflows auszulösen.
5. Bleiben Sie auf der Build-Maschine: Da die Runner zwischen den Builds auf dem Host-Rechner verbleiben, kann Schadcode aktiv bleiben und zukünftige Builds beeinträchtigen, ohne dass der Angreifer den Angriff erneut auslösen muss. Dies ermöglicht eine unbemerkte, kontinuierliche Kompromittierung aller nachfolgenden Pipeline-Ausgaben.
6. Pipeline-Artefakte im Hintergrund manipulieren: Durch den dauerhaften Zugriff kann der Angreifer Hintertüren in Build-Artefakte einfügen, die Auflösung von Abhängigkeiten verändern oder Signaturschlüssel exfiltrieren, was alle nachgelagerten Konsumenten der Projekt-Releases beeinträchtigt.

Der Angriff zielte auf ein öffentliches Repository ab, aber ähnliche Schwachstellen existieren auch in privaten Repositories, wo jeder Mitarbeiter oder Auftragnehmer mit minimalem Repository-Zugriff die gleiche Kette auslösen kann.

Zugriffskontrollen: Absicherung von Pipeline-Berechtigungen

• Deaktivierung des Zugriffs auf Fork-Pull-Requests für selbstgehostete Runner: In GitHub Actions ist standardmäßig die Verwendung von selbstgehosteten Runnern für Fork-Pull-Requests aktiviert. Dies sollte für alle Repositories, die selbstgehostete Runner verwenden, deaktiviert werden. Nutzen Sie stattdessen die von GitHub bereitgestellten temporären Runner für Pull-Request-Workflows von externen Mitwirkenden und reservieren Sie selbstgehostete Runner für Workflows, die erst nach dem Merge ausgeführt werden.
• Manuelle Genehmigung für Workflows externer Mitwirkender erforderlich: Konfigurieren Sie das Repository so, dass ein autorisierter Verantwortlicher Workflow-Ausführungen von neuen oder externen Mitwirkenden genehmigen muss, bevor diese ausgeführt werden. Dadurch wird eine zusätzliche Sicherheitsmaßnahme zwischen der Einreichung von nicht vertrauenswürdigem Code und der Pipeline-Ausführung eingeführt.
• Pipeline-Tokens sollten nach dem Prinzip der minimalen Berechtigungen verwaltet werden: GitHub Actions-Workflow-Token erhalten Berechtigungen, die in der Workflow-Datei definiert sind. Beschränken Sie die Token-Berechtigungen jedes Workflows explizit auf die für den jeweiligen Workflow erforderlichen Berechtigungen (z. B. Lesezugriff auf Repository-Inhalte für einen Test-Workflow; Schreibzugriff für einen Deployment-Workflow). Vermeiden Sie die Verwendung des Standardtokens mit allen Berechtigungen.
• Workflow-YAML-Dateien mit Zweigschutz und Code-Eigentümern schützen: Jegliche Änderung an Workflow-Dateien erfordert die Zustimmung des Code-Eigentümers. Dies verhindert, dass ein Angreifer, der Zugriff auf einen Feature-Branch erlangt hat, die CI/CD-Konfiguration ändert, ohne dass ein Maintainer die Änderung überprüft.
• Verwenden Sie kurzlebige Runner: Die Runner sollten so konfiguriert werden, dass sie für jeden Build zerstört und als saubere Umgebung neu erstellt werden. Dadurch wird die Persistenzgefahr beseitigt: Schadcode, der in einem Build ausgeführt wird, kann zukünftige Builds nicht beeinträchtigen, da die Runner-Umgebung ersetzt wird.

Geheimnisverwaltung in CI/CD-Pipelines

Geheimnisse (API-Schlüssel, Bereitstellungszugangsdaten, Signaturschlüssel, Datenbankpasswörter, Cloud-Zugriffstoken), die in CI/CD-Umgebungen gespeichert sind, stellen das primäre Ziel von Pipeline-Angriffen dar. Effektives Geheimnismanagement erfordert, jedes Geheimnis als potenzielles Angriffsziel zu behandeln und sowohl die Anzahl der Geheimnisse in der Umgebung als auch die Angriffsfläche für deren Offenlegung zu minimieren.

• Geheimnisse niemals fest im Quellcode oder in Konfigurationsdateien verankern: Fest codierte Zugangsdaten sind dauerhaft für jeden zugänglich, der Zugriff auf das Repository hat, einschließlich externer Mitwirkender, Forks und aller, die das Projekt klonen. Verwenden Sie plattformspezifische Geheimnisspeicher (GitHub Actions Secrets, GitLab CI-Variablen, Jenkins-Zugangsdaten) oder spezialisierte Lösungen wie HashiCorp Vault, um Geheimnisse nur zur Laufzeit einzufügen.
• Beschränken Sie die Geheimnisse auf den minimal erforderlichen Pipeline-Schritt: Ein Geheimnis, das nur für den Bereitstellungsschritt benötigt wird, sollte während der Build- oder Testschritte nicht verfügbar sein. Stufenbezogene Geheimnisse verringern das Zeitfenster, in dem ein kompromittierter Schritt auf bestimmte Anmeldeinformationen zugreifen kann.
• Geheimnisse nach einem festgelegten Zeitplan und sofort bei Verdacht auf Kompromittierung rotieren: Langlebige Geheimnisse, die nie rotiert werden, sind bei Exfiltration dauerhaft gefährdet. Definieren Sie einen Rotationsplan für alle Pipeline-Geheimnisse und automatisieren Sie die Rotation, wo immer möglich.
• Durchsuchen Sie Build-Protokolle nach Anmeldeinformationsmustern: Pipeline-Schritte, die versehentlich Umgebungsvariablen ausgeben oder Debug-Ausgaben erzeugen, können Geheimnisse in den Build-Protokollen offenlegen. Verwenden Sie Tools zum Scannen von Protokollen, um Anmeldeinformationsmuster in der Pipeline-Ausgabe zu erkennen und Warnungen auszugeben.
• Speichern Sie die Codesignaturschlüssel in einem HSM, nicht in der Pipeline-Umgebung: Signaturschlüssel, die als Dateien oder Umgebungsvariablen in der Build-Umgebung gespeichert sind, können exfiltriert werden. HSM als Service Speichert Signaturschlüssel in FIPS 140-3 validierter Hardware und führt Signaturvorgänge innerhalb des HSM durch, sodass der private Schlüssel niemals in die Pipeline-Umgebung gelangt.

Codesignierung als Sicherheitsmaßnahme in CI/CD

Die Codesignierung in einer CI/CD-Pipeline erfüllt zwei Sicherheitsfunktionen. Erstens gewährleistet sie die Integrität der Artefakte: Jede von der Pipeline erzeugte Binärdatei, jedes Container-Image und jedes Paket wird kryptografisch signiert. Nachgelagerte Nutzer können die Signatur überprüfen, um sicherzustellen, dass das Artefakt authentisch und seit seiner Erzeugung durch die Pipeline unverändert ist. Sollte ein Angreifer die Build-Umgebung kompromittieren und ein Artefakt nach der Signierung verändern, schlägt die Signaturprüfung bei der Installation fehl.

Zweitens bietet es eine Herkunftsnachweis-Bestätigung für den Build: Das Signaturereignis protokolliert Metadaten zum Build, einschließlich Pipeline-Phase, Commit-SHA, Build-Zeitstempel und Signaturidentität. Dadurch entsteht ein nachvollziehbarer Nachweis darüber, woher jedes Release-Artefakt stammt, was für Untersuchungen zur Lieferkettensicherheit und Compliance-Audits unerlässlich ist.

CodeSign Secure von Encryption Consulting lässt sich direkt in GitHub Actions , Jenkins und Azure DevOps- Pipelines integrieren. Alle Signaturvorgänge werden innerhalb eines HSM durchgeführt, sodass private Schlüssel niemals in die Pipeline-Umgebung gelangen. Die rollenbasierte Zugriffskontrolle legt fest, welche Pipeline-Phasen und Benutzer ein Signaturereignis auslösen können. Jeder Signaturvorgang wird protokolliert, um die von Sicherheitsteams und Compliance-Frameworks geforderte Audit-Trail-Dokumentation zu gewährleisten. Für GitLab CI und andere Plattformen bietet CodeSign Secure zudem Integrationspfade, die unabhängig von der verwendeten CI/CD-Plattform dasselbe HSM-basierte Schlüsselschutzmodell beibehalten.

Abhängigkeitssicherheit und Kontrollen der Software-Lieferkette

• Abhängigkeiten an bestimmte Versionen und Hashwerte binden: Die Angabe einer exakten Versionsnummer reicht nicht aus, da ein Angreifer ein neues Paket mit derselben Versionsnummer veröffentlichen kann. Abhängigkeiten sollten daher an kryptografische Hashwerte (SHA-256-Hashes) gebunden werden, sodass der Build fehlschlägt, wenn der heruntergeladene Hashwert nicht mit dem erwarteten Wert übereinstimmt – unabhängig von der Versionsnummer.
• Software Composition Analysis (SCA) in der Pipeline einsetzen: SCA-Tools scannen Abhängigkeitsbäume auf bekannte Schwachstellen und schädliche Pakete und vergleichen diese vor der Installation mit Datenbanken bekanntermaßen schädlicher Pakete. Integrieren Sie SCA als obligatorischen Pipeline-Schritt, der Builds blockiert, sobald kritische Schwachstellen erkannt werden.
• Verwenden Sie private Paketspiegel für kritische Abhängigkeiten: Ein privater Spiegelserver speichert geprüfte und validierte Versionen von Paketen im Cache. Die Pipeline löst Abhängigkeiten vom privaten Spiegelserver anstatt direkt von öffentlichen Registries auf, wodurch Typosquatting und Abhängigkeitsverwirrungsangriffe verhindert werden.
• Überprüfung von CI/CD-Aktionen und -Plugins von Drittanbietern: CI/CD-Workflows, die Aktionen von Drittanbietern referenzieren, führen Code externer Entwickler mit denselben Berechtigungen wie der Workflow selbst aus. Binden Sie alle externen Aktionen an spezifische Commit-SHAs anstatt an veränderliche Tags oder Branches und prüfen Sie den Code jeder Aktion vor der Verwendung.
• Pflege einer Software-Stückliste (SBOM): Für jedes Release-Artefakt wird ein SBOM (Structured Security Object Model) erstellt und veröffentlicht, das alle Abhängigkeiten anhand von Name, Version und Hash dokumentiert. Ein SBOM ermöglicht es nachgelagerten Nutzern, ihr Risiko einzuschätzen, wenn eine Schwachstelle oder ein schädliches Paket identifiziert wird. Es wird zunehmend von staatlichen Beschaffungsrichtlinien und Frameworks wie NIST SSDF gefordert.

Compliance-Mapping: CI/CD-Sicherheitsanforderungen

Unser Ansatz	Relevante Anforderung	CI/CD-Implikationen
NIST SP 800-218 (SSDF)	Sichere Softwareentwicklungspraktiken, einschließlich sicherer Build-Umgebungen, Artefaktintegrität und Abhängigkeitsmanagement	Verlangt von Organisationen, Build-Tools und -Umgebungen zu schützen, die Integrität der Build-Artefakte zu überprüfen und Softwarekomponenten von Drittanbietern zu verwalten.
SLSA (Supply Chain Levels für Softwareartefakte)	Vier Stufen von Garantien für die Herkunft des Build-Prozesses, von der grundlegenden Dokumentation des Build-Prozesses (L1) bis hin zur HSM-gestützten Signierung und hermetischen Builds (L3+)	Bietet einen Fahrplan zur schrittweisen Erhöhung der Pipeline-Sicherheit; Stufe 2 erfordert eine signierte Herkunftsbestätigung; Stufe 3 erfordert isolierte, gehärtete Build-Umgebungen
PCI DSS v4.0 (Anforderung 6)	Webbasierte Anwendungen und Softwareentwicklungsprozesse müssen geschützt werden; Anforderung 6.3 verlangt die Identifizierung und Behebung von Sicherheitslücken.	CI/CD-Pipelines, die Software zur Verarbeitung von Karteninhaberdaten produzieren, müssen sichere Entwicklungspraktiken und ein effektives Schwachstellenmanagement implementieren.
SOC 2 Typ II	Vertrauenswürdige Dienstkriterien für Sicherheit: logische Zugriffskontrollen, Änderungsmanagement und Überwachung	CI/CD-Zugriffskontrollen, Genehmigungsworkflows für Codeänderungen und Pipeline-Audit-Logs werden im Rahmen der SOC-2-Änderungsmanagementkontrollen bewertet.
HIPAA-Sicherheitsregel	Technische Sicherheitsvorkehrungen für Software, die auf elektronische Gesundheitsdaten zugreift; Prüfkontrollen und Zugriffsmanagement	CI/CD-Pipelines, die Software erzeugen, die auf elektronische Gesundheitsdaten (ePHI) zugreift, müssen Zugriffskontrollen, Audit-Protokollierung und Kontrollen zur Artefaktintegrität beinhalten.

Einschränkungen: Was Pipeline-Sicherheitskontrollen nicht leisten können

• Die Codesignierung überprüft die Integrität, nicht die Korrektheit: Ein signiertes Artefakt beweist, dass es nach der Signierung unverändert aus der Pipeline stammt. Es beweist jedoch nicht, dass der von der Pipeline erstellte Code frei von Sicherheitslücken oder Schadcode ist. Codesignierung und Anwendungssicherheitstests ergänzen sich, sie ersetzen sich nicht.
• Geheimnismanagement schützt nicht vor Insiderbedrohungen durch autorisierte Benutzer: Ein autorisierter Entwickler mit legitimen Zugriffsrechten auf Pipeline-Geheimnisse kann diese dennoch missbrauchen. Geheimnismanagement in Kombination mit Zugriffsprotokollierung, dem Prinzip der minimalen Berechtigungen und Geheimnisrotation reduziert das Insiderrisiko, beseitigt es aber nicht vollständig.
• SCA-Tools sind auf bekanntermaßen fehlerhafte Datenbanken angewiesen: Die Software Composition Analysis (SCA) erkennt Pakete mit bekannten Sicherheitslücken oder bekanntem schädlichem Verhalten. Ein neuartiges, schädliches Paket, das am selben Tag veröffentlicht wird, an dem es in eine Pipeline eingebunden wird, befindet sich noch nicht in der SCA-Datenbank. Zusätzlich zur SCA ist eine mehrschichtige Verteidigung erforderlich, die unter anderem das Festlegen von Abhängigkeiten und die Hash-Verifizierung umfasst.
• Ephemere Runner verringern das Persistenzrisiko, erhöhen aber die Infrastrukturkomplexität: Die Erstellung einer neuen Runner-Umgebung für jeden Build beseitigt zwar die Angriffsmöglichkeit durch Persistenz, erfordert jedoch eine Infrastrukturautomatisierung und verlängert die Build-Zeiten. Dieser Kompromiss ist für Pipelines mit hohen Sicherheitsanforderungen angemessen, aber möglicherweise nicht für alle Umgebungen praktikabel.

Wie Verschlüsselungsberatung helfen kann

• CodeSign Secure: CodeSign Secure Integriert die Codesignierung direkt in CI/CD-Pipelines mit HSM-gestützter Schlüsselspeicherung, rollenbasierter Zugriffskontrolle für Signaturen, obligatorischer Zeitstempelung und vollständiger Protokollierung. Unterstützt werden GitHub Actions, Jenkins, Azure DevOps, GitLab CI und weitere Plattformen, wobei das gleiche Schlüsselschutzmodell für alle Pipeline-Integrationen beibehalten wird.
• CertSecure Manager: CertSecure Manager verwaltet den Zertifikatslebenszyklus für Zertifikate, die bei der Pipeline-Authentifizierung, mTLS zwischen Pipeline-Diensten und der Codesignierung verwendet werden, einschließlich der automatischen Erneuerung, um zu verhindern, dass ein Zertifikatsablauf den Pipeline-Betrieb stört.
• HSM als Dienstleistung: HSM als Service bietet FIPS 140-3 validierte Hardware-Schlüsselspeicherung für Codesignaturschlüssel und Pipeline-Authentifizierungsdaten und stellt so sicher, dass selbst eine vollständige Kompromittierung des Build-Servers die privaten Schlüssel, mit denen Pipeline-Ausgaben signiert werden, nicht extrahieren kann.
• Verschlüsselungsberatungsdienste: UNSERE Verschlüsselungsberatung Bewertung der Pipeline-Sicherheitsarchitektur, Identifizierung von Lücken in der Zugriffskontrolle und Schwächen im Geheimnismanagement sowie Erstellung eines Abhilfeplans, der Authentifizierung, Artefaktintegrität, Abhängigkeitssicherheit und Compliance-Anpassung umfasst.

Fazit

CI/CD-Pipelines sind kein Randaspekt der Software-Lieferkette. Sie stellen in den meisten Unternehmen das privilegierteste automatisierte System dar: Sie erstellen, signieren und verteilen die Software, der Benutzer und Kunden vertrauen. Eine kompromittierte Pipeline erzeugt über einen vertrauenswürdigen Kanal kompromittierte Software, und die weitreichenden Folgen können, wie die PyTorch-Forschung gezeigt hat, ein ganzes Branchenökosystem erfassen.

Die Maßnahmen zur Risikominderung in Pipelines sind bekannt: Deaktivierung des Standardzugriffs für externe Workflow-Beteiligte, Durchsetzung des Prinzips der minimalen Berechtigungen für Pipeline-Token, Auslagerung von Geheimnissen in dedizierte Managementsysteme, Signierung aller Pipeline-Artefakte mit HSM-gesicherten Schlüsseln, Festlegung von Abhängigkeiten auf hash-verifizierte Versionen und Auditierung aller Drittanbieter-Pipeline-Komponenten. Dies sind keine theoretischen Best Practices, sondern konkrete Sicherheitslücken, die in dokumentierten Angriffen ausgenutzt wurden.

Nutzt Ihr Unternehmen CI/CD und benötigt eine Sicherheitsbewertung Ihrer Pipeline-Architektur, Zugriffskontrollen und Integritätskontrollen, wenden Sie sich an Encryption Consulting . Unser Team analysiert Ihre aktuelle Konfiguration, identifiziert die wichtigsten Sicherheitslücken und integriert Codesignierung und kryptografische Kontrollen, die Ihre Pipeline schützen, ohne Ihre Release-Geschwindigkeit zu beeinträchtigen.

Häufig gestellte Fragen

Was ist eine CI/CD-Pipeline und warum stellt sie ein Sicherheitsrisiko dar?

Eine CI/CD-Pipeline ist ein automatisierter Workflow für Build, Test und Deployment, der mit erhöhten Berechtigungen ausgeführt wird, Produktionsgeheimnisse speichert und externen Code über Abhängigkeiten einbindet. Sie stellt ein Sicherheitsrisiko dar, da eine Kompromittierung zu manipulierten Builds führt, die über einen vertrauenswürdigen Kanal an nachgelagerte Benutzer ausgeliefert werden und potenziell alle Nutzer des betroffenen Projekts betreffen können.

Was ist ein selbstgehosteter Runner-Angriff auf GitHub Actions?

Standardmäßig löst ein Pull Request eines Mitwirkenden den selbstgehosteten Runner aus, bevor der PR geprüft wird. Ein Angreifer, der den Status eines Mitwirkenden erlangt (was nachweislich nur die Korrektur eines Tippfehlers erfordert), kann einen Pull Request mit einem schädlichen Workflow einreichen, der auf dem Runner ausgeführt wird, Authentifizierungstoken abfängt und sich auf dem Build-Rechner einnistet, um alle nachfolgenden Builds zu beeinträchtigen.

Was versteht man unter Abhängigkeitsvergiftung im Kontext von CI/CD?

Dependency Poisoning tritt auf, wenn ein schädliches Paket unter einem Namen in einem öffentlichen Repository veröffentlicht wird, den die Build-Pipeline herunterlädt. Dies kann durch Tippfehler, die Kompromittierung des Kontos des Paketbetreuers oder durch Abhängigkeitskonflikte geschehen. Die Pipeline führt das schädliche Paket dann im Rahmen ihres normalen Build-Prozesses aus. Allein im Jahr 2025 identifizierte Sonatype über 454,600 schädliche Pakete.

Wie schützt die Codesignierung eine CI/CD-Pipeline?

Die Codesignierung gewährleistet die Integritätsprüfung von Artefakten (nachgelagerte Nutzer können bestätigen, dass das Artefakt unverändert aus der Pipeline stammt) und die Herkunftsnachweise (ein nachvollziehbarer Nachweis darüber, in welcher Pipeline-Phase und bei welchem ​​Commit das Artefakt erzeugt wurde). Um einen Schlüsselabfluss bei einer kompromittierten Pipeline zu verhindern, müssen die Schlüssel in einem HSM und nicht in der Build-Umgebung gespeichert werden.

Worin besteht der Unterschied zwischen Geheimnisverwaltung und fest codierten Anmeldeinformationen?

Fest codierte Zugangsdaten sind im Quellcode oder in Konfigurationsdateien eingebettet und somit dauerhaft für jeden mit Repository-Zugriff zugänglich. Die Geheimnisverwaltung speichert Zugangsdaten in einem verschlüsselten Geheimnisspeicher und fügt sie zur Laufzeit nur dem autorisierten Pipeline-Schritt hinzu, der sie benötigt. Dadurch erscheinen sie niemals im Quellcode, in Build-Protokollen oder in Pipeline-Artefakten.

Welche Compliance-Frameworks regeln die Sicherheit von CI/CD-Pipelines?

NIST SP 800-218 (SSDF) fordert sichere Build-Umgebungen und die Integrität von Artefakten. SLSA definiert vier Stufen der Herkunftsgarantie für Builds. PCI DSS v4.0 Anforderung 6 fordert sichere Softwareentwicklungsprozesse. SOC 2 Typ II bewertet CI/CD-Zugriffskontrollen und Änderungsmanagement. HIPAA fordert Zugriffskontrollen und Audit-Protokollierung für Pipelines, die Software erzeugen, welche auf elektronische Gesundheitsdaten (ePHI) zugreift.