Ein kompromittierter Build-Runner, ein Token mit zu weitreichenden Rechten oder eine manipulierte Abhängigkeit reichen aus, um aus einer Delivery-Strecke einen Angriffsweg zu machen. Eine DevSecOps Pipeline abzusichern bedeutet deshalb nicht, möglichst viele Scanner einzuschalten. Entscheidend ist, ob Du nachvollziehen und erzwingen kannst, wer welchen Code unter welchen Bedingungen gebaut, geprüft, freigegeben und ausgeliefert hat.
Das verändert auch die Perspektive auf Verantwortung. Security ist nicht bloß ein Quality Gate kurz vor Produktion. Sie ist eine Eigenschaft der gesamten Lieferkette – von der lokalen Entwicklungsumgebung über das Quellcode-Repository und die Build-Infrastruktur bis zur Laufzeitplattform. Für CISOs und IT-Leitung geht es dabei um steuerbare Risiken und belastbare Nachweise. Für Plattformteams und Engineers um Kontrollen, die sich automatisieren lassen, nachvollziehbar bleiben und den Delivery Flow nicht unnötig bremsen.
Warum die Pipeline ein besonders lohnendes Ziel ist
Eine CI/CD-Pipeline verarbeitet besonders wertvolle Artefakte: Quellcode, Secrets, Zugangsdaten, Paketquellen, Container-Images und oft Berechtigungen für Zielumgebungen. Wer an einer Stelle dieser Kette Kontrolle gewinnt, kann unter Umständen weitreichender wirken als durch den Angriff auf einen einzelnen Workload.
Die Gefahr liegt nicht nur in externen Angreifern. Fehlkonfigurationen, dauerhaft gültige Tokens, unklare Administratorrechte und intransparente Ausnahmen erzeugen dieselben Schwachstellen. Gerade gewachsene Toolchains sind betroffen: Ein zentral betriebenes Repository, Cloud-Runner verschiedener Teams, externe Paketregistries und mehrere Deployment-Wege können eine Lieferkette schaffen, deren Sicherheitsmodell niemand vollständig überblickt.
Deshalb beginnt die Arbeit nicht mit der Frage nach dem nächsten Tool. Sie beginnt mit einer Architekturentscheidung: Welche Vertrauensgrenzen gibt es? Welche Identität darf einen Build starten? Welcher Build darf ein Artefakt signieren? Und welche Instanz darf es in eine produktive Umgebung bringen?
DevSecOps Pipeline absichern: Identitäten zuerst
In vielen Pipelines sind Zugangsdaten das schwächste Glied. Statische Zugangsschlüssel in Variablen, Konfigurationsdateien oder Entwickler-Workstations sind bequem, aber schwer zu kontrollieren. Werden sie kopiert oder abgegriffen, bleibt oft unklar, ob und wo sie weiter verwendet werden.
Setze daher auf kurzlebige, an den konkreten Job gebundene Identitäten. Der Build-Job sollte nur die Berechtigungen erhalten, die er für seine Aufgabe braucht. Ein Job, der Tests ausführt, benötigt keinen Zugriff auf Produktionssysteme. Ein Deployment-Job sollte nicht automatisch Code verändern oder neue Pipeline-Konfigurationen schreiben dürfen.
Besonders kritisch sind privilegierte Runner und Service Accounts. Prüfe, ob sie gemeinsam von Projekten mit unterschiedlichem Schutzbedarf genutzt werden. Ein Build aus einem weniger vertrauenswürdigen Repository darf nicht über denselben Runner auf Geheimnisse oder Artefakte eines hochkritischen Produkts zugreifen können. Getrennte Runner-Pools, restriktive Netzwerkpfade und sauber abgegrenzte Berechtigungen reduzieren hier die Angriffsfläche deutlich.
Auch menschliche Identitäten bleiben relevant. Erzwinge Multi-Faktor-Authentisierung für administrative Rollen, begrenze die Zahl der Personen mit Änderungen an Pipeline-Definitionen und dokumentiere zeitlich begrenzte Notfallzugriffe. Vier-Augen-Freigaben sind sinnvoll, wenn sie für kritische Änderungen gelten – nicht als pauschale Hürde für jeden kleinen Commit.
Code, Konfiguration und Abhängigkeiten als Einheit behandeln
Eine sichere Anwendung kann durch unsichere Pipeline-Konfiguration kompromittiert werden. Deshalb gehören Pipeline-Dateien, Infrastructure-as-Code und Deployment-Manifeste in dieselbe Governance wie Anwendungsquellcode. Änderungen müssen reviewbar sein, geschützt in den Hauptbranch gelangen und einer nachvollziehbaren Historie folgen.
Branch-Schutz allein genügt allerdings nicht. Prüfe, wer Regeln ändern, Reviews umgehen oder Build-Variablen bearbeiten kann. Diese Funktionen sind administrative Eingriffe in den Auslieferungsprozess und verdienen dieselbe Aufmerksamkeit wie Produktionszugriffe.
Bei Abhängigkeiten gilt: Scanning findet bekannte Schwachstellen, beantwortet aber nicht automatisch die Vertrauensfrage. Du solltest wissen, aus welchen Registries Pakete stammen, welche Versionen tatsächlich eingebunden wurden und ob Build-Prozesse unerwartet Code nachladen. Lockfiles, intern kontrollierte Repositories und klar definierte Freigabeprozesse für neue Quellen schaffen Transparenz, ohne jede Bibliothek manuell prüfen zu müssen.
Eine Software Bill of Materials kann dabei helfen, Bestandteile eines Releases strukturiert zu dokumentieren. Ihr Nutzen hängt jedoch von Qualität und Einbindung ab. Eine SBOM, die erst nach dem Deployment erzeugt wird und keinen Bezug zum ausgelieferten Artefakt hat, ist eher Inventar als Sicherheitskontrolle. Wertvoll wird sie, wenn sie reproduzierbar aus dem Build entsteht, einem konkreten Artefakt zugeordnet ist und in Incident- sowie Vulnerability-Prozesse einfließt.
Nicht jeder Scan ist ein Gate
Statische Codeanalyse, Secret Scanning, Dependency Scanning, Container-Prüfungen und Infrastructure-as-Code-Checks haben jeweils eine Berechtigung. Ihre Ergebnisse unterscheiden sich aber deutlich in Qualität, Kontext und Dringlichkeit. Wer jede Meldung sofort zum Release-Blocker macht, produziert Frustration, Umgehungen und eine wachsende Liste ungeklärter Ausnahmen.
Lege stattdessen je Kontrolltyp fest, welche Befunde blockieren, welche einen begründeten Ausnahmeprozess benötigen und welche als technische Schuld verfolgt werden. Dabei zählen nicht nur Schweregrad und CVSS-Wert. Erreichbarkeit, Exponierung, Datenkritikalität, vorhandene Kompensationsmaßnahmen und die Funktion des betroffenen Systems verändern das Risiko.
Für Teams bedeutet das: Sicherheitsregeln müssen früh sichtbar sein. Feedback in Pull Requests ist meist wirksamer als ein Fehler kurz vor dem Release. Für die Security-Organisation bedeutet es: Ausnahmen brauchen Eigentümer, Ablaufdatum und eine überprüfbare Begründung. Eine Ausnahme ohne Ende ist faktisch eine akzeptierte Schwachstelle ohne Entscheidung.
Artefakte signieren, Herkunft nachweisen
Der zentrale Übergabepunkt einer Pipeline ist das Artefakt. Ob Container-Image, Paket, Binärdatei oder Infrastructure Bundle: In Produktion sollte nur landen, was aus einem kontrollierten Build stammt und unverändert geblieben ist.
Signaturen und Herkunftsnachweise sind dafür ein starkes Muster. Sie ermöglichen, die Freigabe eines Artefakts an eine vertrauenswürdige Build-Identität und einen definierten Prozess zu koppeln. Laufzeitplattformen oder Deployment-Werkzeuge können dann prüfen, ob ein Artefakt aus der erwarteten Quelle kommt. Frameworks wie SLSA geben hierfür eine Orientierung, ohne dass jedes Unternehmen sofort jede Reifestufe vollständig erreichen muss.
Der praktische Einstieg ist überschaubar: Baue Artefakte einmal, veröffentliche sie in einem kontrollierten Registry- oder Repository-Kontext und befördere genau dieses Artefakt durch die Umgebungen. Ein erneuter Build für Produktion erzeugt zwar häufig dieselbe Funktion, aber nicht zwingend denselben Nachweis. Reproduzierbare Builds sind ideal, jedoch nicht in jeder Legacy-Landschaft kurzfristig erreichbar. Wichtig ist zunächst, dass Herkunft, Build-Parameter und Freigabe nachvollziehbar bleiben.
Die Laufzeitumgebung muss die Pipeline-Regeln durchsetzen
Eine gute Pipeline-Kontrolle verliert ihren Wert, wenn sich Artefakte oder Konfigurationen später direkt in Produktion ändern lassen. GitOps-Ansätze können helfen, weil sie den Sollzustand versioniert und prüfbar machen. Sie ersetzen aber keine Berechtigungskonzepte: Wer den deklarativen Zielzustand ändern darf, besitzt weiterhin eine hochprivilegierte Rolle.
Definiere daher klare Regeln für Deployment-Identitäten, Zielumgebungen und Notfalländerungen. Produktionszugänge für Entwickler können in Ausnahmefällen nötig sein, etwa bei Störungen. Dann müssen sie zeitlich begrenzt, protokolliert und nachträglich überprüft werden. Entscheidend ist nicht die dogmatische Trennung von Dev und Ops, sondern dass privilegierte Eingriffe sichtbar und steuerbar bleiben.
Auch Netzwerk- und Laufzeitkontrollen gehören dazu. Build-Systeme brauchen nicht automatisch freien Zugriff auf alle internen Systeme. Deployment-Jobs benötigen in der Regel nur die Verbindungen, die für ihr Ziel erforderlich sind. Segmentierung begrenzt den Schaden, falls ein Runner oder ein Token kompromittiert wird.
Governance als Betriebsmodell, nicht als Freigabegremium
NISTs Secure Software Development Framework und der OWASP Software Supply Chain Security Guidance bieten sinnvolle Bezugspunkte für Prozesse und technische Maßnahmen. Entscheidend ist jedoch die Übersetzung in Dein Betriebsmodell. Ein zentral vorgegebenes Regelwerk ohne Plattformunterstützung führt häufig zu Ticketprozessen und lokalen Workarounds. Vollständig dezentrale Entscheidungen führen dagegen oft zu uneinheitlichen Sicherheitsniveaus.
Sinnvoll ist ein gemeinsames Modell: Die Plattform stellt sichere Standardwege bereit, etwa verwaltete Runner, geheime Parameter, geprüfte Basis-Images und zentrale Artefakt-Repositories. Produktteams bleiben verantwortlich für ihren Code, ihre Abhängigkeiten und die Risikobehandlung ihrer Services. Security definiert Mindestkontrollen, beobachtet Wirksamkeit und unterstützt bei Ausnahmen sowie Incident Response.
Messbar wird das über wenige aussagekräftige Kennzahlen: Anteil signierter Releases, Anzahl dauerhaft privilegierter Service Accounts, Alter offener kritischer Findings, Anteil der Deployments außerhalb des Standardwegs und Zeit bis zur Rotation kompromittierter Credentials. Solche Kennzahlen zeigen nicht nur Compliance. Sie machen sichtbar, wo die Lieferkette organisatorisch oder technisch brüchig ist.
Die richtige Frage lautet am Ende nicht, ob jede Pipeline identisch abgesichert ist. Kritische Systeme, regulierte Daten und externe Exponierung verlangen strengere Kontrollen als ein internes Experiment. Aber für jeden Pfad sollte klar sein, welches Risiko akzeptiert wurde, wer es verantwortet und wie Du es wieder reduzierst. Genau diese Transparenz macht schnelle Softwarelieferung und belastbare Sicherheit miteinander vereinbar.
