Software entsteht heute über automatisierte Pipelines: Code wird zusammengeführt, kompiliert, getestet und in Zielumgebungen ausgerollt — bei vielen Teams mehrmals täglich. Der Produktivitätsgewinn ist erheblich, doch die Bedrohungslage verschiebt sich mit. Die Pipeline hält Zugriff auf Quellcode und Zugangsdaten, oft auch auf Produktionsumgebungen.
Wer sie kompromittiert, muss keine einzelne Anwendung mehr angreifen: Der Schadcode wird von der unternehmenseigenen Automatisierung frei Haus ausgeliefert. CI/CD-Sicherheit stellt deshalb die Lieferkette der eigenen Software in den Mittelpunkt.
Was ist CI/CD-Sicherheit?
CI/CD-Sicherheit bündelt alle Maßnahmen, die die Integrität der automatisierten Build- und Auslieferungskette gewährleisten — vom Quellcode-Repository über Build-Server und Artefakt-Registries bis in die Zielumgebung. Auf einen Satz gebracht lautet das Ziel: In die Produktion gelangt ausschließlich geprüfter Code, dessen Entstehung sich nachvollziehen lässt. Dazu zählen technische Kontrollen wie Zugriffsbeschränkungen und Signaturen ebenso wie organisatorische Vorgaben, etwa verpflichtende Reviews für Änderungen an Pipeline-Definitionen. Der Begriff überlappt mit Software-Supply-Chain-Security, richtet den Blick aber auf den selbst betriebenen Teil der Lieferkette. Zu dieser Kette gehören auch die Werkzeuge selbst: Ein nicht aktualisierter Build-Server ist ein ebenso konkretes Risiko wie eine verwundbare Abhängigkeit im Code. Als Arbeitsweise, die Sicherheitsprüfungen fest im Entwicklungsalltag verankert, ist DevSecOps eng verwandt.
So funktioniert es
Wirksame Absicherung greift an mehreren Punkten der Kette zugleich:
- Rechte begrenzen: Jede Pipeline erhält nur die Berechtigungen, die ihr Zweck erfordert. Kurzlebige, automatisch rotierende Tokens lösen statische Zugangsdaten ab; Änderungen an geschützten Branches setzen ein Review voraus.
- Secrets zentralisieren: Zugangsdaten liegen in einem Secret-Store und werden erst zur Laufzeit bereitgestellt. Secret-Scanning stoppt Schlüssel, bevor sie im Quellcode landen, und spürt Altfälle in der Historie auf.
- Abhängigkeiten prüfen: Software Composition Analysis gleicht eingebundene Pakete mit bekannten Schwachstellen ab. Lockfiles und kuratierte interne Registries erschweren Angriffe wie Dependency Confusion oder Typosquatting.
- Artefakte signieren: Jeder Build erzeugt ein unveränderliches, signiertes Artefakt mit Herkunftsnachweis. Vor dem Deployment steht die Signaturprüfung: Ausgerollt wird nur, was erkennbar aus der eigenen Pipeline stammt; alles andere wird verworfen.
- Build-Umgebung isolieren: Runner laufen abgeschottet und kurzlebig, im Idealfall für jeden Job frisch aufgesetzt. Netzwerksegmentierung und kontrollierter Egress unterbinden, dass ein kompromittierter Job Daten abfließen lässt oder die Produktion erreicht.
- Aufzeichnen und alarmieren: Audit-Logs halten fest, wer Pipelines ändert und Deployments anstößt. Auffällige Muster — etwa Builds zu untypischen Zeiten — lösen eine Prüfung aus.
Warum es wichtig ist
- Die Pipeline wirkt als Generalschlüssel: Sie darf Code in die Produktion bringen und ist damit für Angreifer wertvoller als einzelne Server.
- Supply-Chain-Angriffe skalieren: Ein kompromittierter Build-Prozess verteilt Schadcode an sämtliche Abnehmer der Software gleichzeitig — im Zweifel bis zu den eigenen Kunden.
- Secrets sind ein bevorzugtes Einfallstor: Geleakte Tokens in Repositories oder Build-Logs zählen zu den häufigen Ursachen realer Vorfälle und lassen sich von Angreifern automatisiert aufspüren.
- Die Regulatorik fordert Nachweise: Vorgaben wie NIS-2 und DORA verlangen Kontrolle über die Software-Lieferkette; signierte Artefakte und lückenlose Build-Protokolle liefern die Belege.
- Vertrauen wird überprüfbar: Kunden und Partner fragen zunehmend danach, wie eingesetzte Software entsteht. Eine abgesicherte Pipeline macht die Antwort belastbar.
Typische Szenarien
Der Klassiker ist der versehentlich veröffentlichte Token: Ein Zugangsschlüssel gelangt in ein öffentliches Repository und ebnet den Weg in interne Systeme. Ähnlich verbreitet ist das übernommene Open-Source-Paket: Eine Abhängigkeit wechselt den Besitzer, die nächste Version bringt Schadcode mit, und die Pipeline verbaut ihn ungeprüft. In gewachsenen Umgebungen findet sich zudem oft ein zentraler Build-Server mit dauerhaftem Vollzugriff auf sämtliche Umgebungen — ein ideales Sprungbrett für Angreifer. Spätestens im Audit folgt schließlich die Frage, ob sich für ein produktives Artefakt zweifelsfrei belegen lässt, aus welchem Code und welchem Build es hervorging. Alle vier Fälle teilen dieselbe Wurzel: Die Pipeline galt als Werkzeug, wurde aber nie als schützenswertes System behandelt.
Abgrenzung: CI und CD
CI steht für Continuous Integration: Codeänderungen fließen laufend zusammen und durchlaufen automatisierte Builds und Tests. CD meint je nach Lesart Continuous Delivery — es entstehen jederzeit auslieferbare Stände — oder Continuous Deployment, bei dem jede erfolgreiche Änderung automatisch in die Produktion geht. Für die Sicherheit zählt die Unterscheidung, weil sich die Angriffsflächen unterscheiden: In der CI-Phase dominieren Risiken rund um Code und Abhängigkeiten, etwa manipulierte Pakete oder unsichere Build-Skripte. In der CD-Phase geht es um den Weg in die Produktion — um Deployment-Zugänge und die Integrität der ausgerollten Artefakte. Wer beide Phasen getrennt betrachtet, erkennt schneller, an welcher Stelle welche Kontrolle fehlt.
Die Rolle des Netzwerks
Ein erheblicher Teil der CI/CD-Sicherheit ist im Kern Netzwerksicherheit. Mikrosegmentierung beschränkt Build-Systeme und Produktionsumgebungen auf explizit erlaubte Verbindungen; ein kompromittierter Build-Job bleibt dadurch lokal begrenzt, statt zum Ausgangspunkt lateraler Bewegung zu werden. Schutzmechanismen zur Laufzeit — etwa Web Application Firewalls vor den ausgelieferten Anwendungen und APIs — ergänzen die Kontrollen in der Pipeline. In der Praxis übernehmen spezialisierte Managed-Service-Provider Aufbau und Betrieb solcher Kontrollen und passen die Regelwerke an, wenn sich Entwicklungsprozesse ändern — etwa bei gemanagter Mikrosegmentierung.
Häufige Fragen
Warum geraten CI/CD-Pipelines ins Visier von Angreifern?
Weil sie weitreichende Rechte bündeln: Pipelines lesen Quellcode, halten Zugangsdaten zu internen Systemen und dürfen Software in die Produktion bringen. Ein erfolgreicher Angriff verteilt Schadcode über einen vertrauenswürdigen Kanal und unterläuft damit viele klassische Schutzmaßnahmen. Hinzu kommt, dass Build-Systeme häufig schwächer gehärtet sind als Produktionsumgebungen — das erleichtert den Einstieg zusätzlich.
Wie werden Secrets in der Pipeline richtig verwaltet?
Zugangsdaten gehören in einen zentralen Secret-Store, niemals in Code oder Pipeline-Definitionen. Bewährt haben sich kurzlebige Tokens, die pro Lauf ausgestellt und automatisch entwertet werden, ergänzt um regelmäßige Rotation der verbleibenden statischen Schlüssel. Secret-Scanning in Repositories und Build-Logs deckt Verstöße auf. Wichtig bleibt der Blick zurück: Einmal veröffentlichte Schlüssel stehen weiter in der Git-Historie und müssen widerrufen werden.
Welchen Nutzen bringen signierte Artefakte?
Die Signatur belegt, dass ein Artefakt aus dem eigenen Build-Prozess stammt und seither unverändert blieb. Die Zielumgebung prüft sie vor dem Start und weist Unsigniertes ab. Manipulationen an Registries und eingeschleuste fremde Images laufen damit ins Leere. Zusammen mit Herkunftsnachweisen wie SBOM und Build-Provenance entsteht eine belastbare Kette vom Commit bis zur Produktion.
Was unterscheidet CI von CD?
Continuous Integration führt Codeänderungen fortlaufend zusammen und prüft sie automatisiert mit Builds und Tests. Continuous Delivery erzeugt daraus jederzeit auslieferbare Stände mit manueller Freigabe; Continuous Deployment rollt erfolgreiche Änderungen automatisch aus. Sicherheitsseitig betrifft CI vor allem Code und Abhängigkeiten, CD den kontrollierten Weg in die Produktion samt Deployment-Zugängen und Artefakt-Integrität.
Welche Bedeutung hat das Netzwerk für die Pipeline-Sicherheit?
Build-Runner benötigen definierte Kommunikationswege — zum Repository, zur Registry, zu den Zielumgebungen. Jede Verbindung darüber hinaus ist ein Risiko. Segmentierung verhindert, dass ein kompromittierter Job interne Systeme auskundschaftet oder Daten an beliebige Ziele sendet; kontrollierter Egress erschwert das Nachladen von Schadcode. Aus dem potenziellen Generalschlüssel wird so ein eng umgrenzter Arbeitsbereich.