Moderne Softwareentwicklung läuft über automatisierte Pipelines: Code wird zusammengeführt, gebaut, getestet und in Zielumgebungen ausgerollt, oft mehrmals am Tag. Diese Automatisierung ist ein enormer Produktivitätsgewinn, verändert aber die Bedrohungslage. Die Pipeline besitzt Zugriff auf Quellcode und Zugangsdaten, häufig auch auf Produktionsumgebungen. Ein Angreifer, der sie kompromittiert, muss keine einzelne Anwendung mehr knacken: Er lässt seinen Schadcode bequem von Ihrer eigenen Automatisierung ausliefern. CI/CD-Sicherheit rückt deshalb die Lieferkette der Software in den Mittelpunkt.
Was ist CI/CD-Sicherheit?
CI/CD-Sicherheit umfasst alle Maßnahmen, die die Integrität der automatisierten Build- und Auslieferungskette schützen: vom Quellcode-Repository über Build-Server und Artefakt-Registries bis zur Zielumgebung. Das Ziel lässt sich in einem Satz fassen: Nur geprüfter, nachvollziehbar gebauter Code erreicht die Produktion. Dazu gehören technische Kontrollen wie Zugriffsbeschränkungen und Signaturen ebenso wie organisatorische Regeln, etwa Review-Pflichten für Änderungen an Pipeline-Definitionen. Der Begriff überschneidet sich mit Software-Supply-Chain-Security, konzentriert sich aber auf den Teil der Lieferkette, den Sie selbst betreiben. Zur Kette gehören dabei auch die Werkzeuge selbst: Ein veralteter Build-Server ist ein ebenso reales Risiko wie eine verwundbare Abhängigkeit im Code.
So funktioniert es
Wirksamer Schutz setzt an mehreren Stellen der Kette gleichzeitig an:
- Zugriffe minimieren: Jede Pipeline erhält nur die Rechte, die sie für ihren Zweck braucht. Kurzlebige, automatisch rotierte Tokens ersetzen statische Zugangsdaten, Änderungen an geschützten Branches erfordern ein Review.
- Secrets zentral verwalten: Zugangsdaten liegen in einem Secret-Store und werden erst zur Laufzeit eingeblendet. Secret-Scanning verhindert, dass Schlüssel im Quellcode landen, und findet Altlasten in der Historie.
- Abhängigkeiten kontrollieren: Software Composition Analysis prüft eingebundene Pakete auf bekannte Schwachstellen. Lockfiles und kuratierte interne Registries erschweren Angriffe wie Dependency Confusion oder Typosquatting.
- Artefakte signieren: Jeder Build erzeugt ein unveränderliches, signiertes Artefakt samt Herkunftsnachweis. Vor dem Deployment wird die Signatur geprüft: Was erkennbar aus der eigenen Pipeline stammt, darf ausgerollt werden, alles andere wird verworfen.
- Build-Umgebung härten: Runner laufen isoliert und kurzlebig, idealerweise pro Job frisch erzeugt. Netzwerksegmentierung und kontrollierter Egress verhindern, dass ein kompromittierter Build-Job Daten abfließen lässt oder auf die Produktion zugreift.
- Protokollieren und alarmieren: Audit-Logs zeichnen auf, wer Pipelines ändert und wer Deployments auslöst. Ungewöhnliche Muster, etwa Builds zu untypischen Zeiten, lösen eine Prüfung aus.
Warum es wichtig ist
- Die Pipeline ist ein Generalschlüssel: Sie darf Code in die Produktion bringen. Genau deshalb ist sie für Angreifer wertvoller als einzelne Server.
- Supply-Chain-Angriffe skalieren: Wird ein Build-Prozess kompromittiert, erreicht der Schadcode alle Abnehmer der Software gleichzeitig, im Zweifel auch Ihre Kunden.
- Secrets sind ein bevorzugtes Einfallstor: Geleakte Tokens in Repositories oder Build-Logs gehören zu den häufigen Ursachen realer Vorfälle und sind für Angreifer leicht automatisiert auffindbar.
- Regulatorik zieht nach: Vorgaben wie NIS2 und DORA verlangen Kontrolle über die Software-Lieferkette. Signierte Artefakte und lückenlose Build-Protokolle liefern die geforderten Nachweise.
- Vertrauen wird prüfbar: Kunden und Partner fragen zunehmend, wie Ihre Software entsteht. Eine abgesicherte Pipeline macht die Antwort belegbar.
Typische Szenarien
Der Klassiker ist der geleakte Token: Ein Zugangsschlüssel landet versehentlich in einem öffentlichen Repository und öffnet den Weg zu internen Systemen. Ebenso verbreitet ist das kompromittierte Open-Source-Paket: Eine Abhängigkeit wechselt den Besitzer und liefert in der nächsten Version Schadcode mit, den die Pipeline ungeprüft einbaut. In gewachsenen Umgebungen findet sich zudem oft ein zentraler Build-Server mit dauerhaften Vollzugriffen auf sämtliche Umgebungen, ein ideales Sprungbrett für Angreifer. Und spätestens im Audit stellt sich die Frage, ob sich für ein produktives Artefakt lückenlos belegen lässt, aus welchem Code und welchem Build es stammt. Alle vier Fälle haben dieselbe Wurzel: Die Pipeline wurde als Werkzeug betrachtet, aber nie als schützenswertes System behandelt.
CI und CD: die Abgrenzung
CI steht für Continuous Integration: Codeänderungen werden laufend zusammengeführt und automatisiert durch Builds und Tests geprüft. CD steht je nach Lesart für Continuous Delivery, bei der jederzeit auslieferbare Stände entstehen, oder für Continuous Deployment, bei dem jede erfolgreiche Änderung automatisch in die Produktion geht. Für die Sicherheit ist die Unterscheidung relevant, 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, also um Deployment-Zugänge und um die Integrität der ausgerollten Artefakte. Wer beide Phasen getrennt betrachtet, erkennt schneller, welche Kontrolle wo fehlt.
So unterstützt KAEMI
Viele Kontrollen der CI/CD-Sicherheit sind im Kern Netzwerkkontrollen. KAEMI segmentiert Build-Umgebungen mit Mikrosegmentierung , sodass Build-Systeme und Produktionsumgebungen ausschließlich über explizit erlaubte Verbindungen kommunizieren. Ein kompromittierter Build-Job bleibt damit lokal begrenzt, statt zum Ausgangspunkt für laterale Bewegung zu werden. Ergänzend schützt Application Security die Anwendungen und APIs, die Ihre Pipeline ausliefert, im laufenden Betrieb. Als Managed Service Provider übernimmt KAEMI Aufbau und Betrieb dieser Kontrollen und passt die Regelwerke an, wenn sich Ihre Entwicklungsprozesse ändern. Über Kontakt erreichen Sie unser Team für eine Bestandsaufnahme Ihrer Build-Infrastruktur.