Wie sichert man die CI/CD-Pipeline selbst ab?
Kurzantwort
Behandeln Sie die Pipeline wie Produktionsinfrastruktur: Sie hält die Zugangsdaten, um Code auszuliefern und die Produktion zu erreichen, sodass ihre Kompromittierung jede nachgelagerte Kontrolle umgeht. Härten Sie sie mit isolierten, kurzlebigen Runnern; Tokens mit minimalen Rechten und kurzer Lebensdauer (OIDC-Föderation statt langlebiger Secrets); geschützten Branches und geprüfter Pipeline-Konfiguration; per Digest gepinnten Drittanbieter-Actions; und vollständigem Audit-Logging. Die Pipeline ist ein erstklassiges Ziel, keine Klempnerei.
Eine CI/CD-Pipeline hält die Schlüssel zum Königreich: Sie kann Ihren gesamten Quellcode lesen, Artefakte bauen und signieren und in die Produktion deployen. Wenn ein Angreifer die Pipeline besitzt, ist jeder nachgelagerte Scanner und jedes Gate hinfällig. Deshalb verteidigen Sie sie wie die Produktion.
Runner isolieren und ephemer machen
Build-Runner führen beliebigen Code aus — bei öffentlichen Repos auch Code aus nicht vertrauenswürdigen Pull Requests. Verwenden Sie ephemere Runner, die nach jedem Job zerstört werden, sodass zwischen Builds nichts bestehen bleibt, und isolieren Sie sie von Ihrem internen Netzwerk und voneinander. Führen Sie nicht vertrauenswürdige PR-Builds niemals mit privilegierten Zugangsdaten aus.
Zugangsdaten mit minimalen Rechten und kurzer Lebensdauer
Der größte Gewinn ist die Beseitigung langlebiger Secrets. Statt einen permanenten Cloud-Schlüssel in der CI zu speichern, nutzen Sie die OIDC-Föderation: Die Pipeline präsentiert ein kurzlebiges, auf die Workload bezogenes Token, das der Cloud-Anbieter gegen temporäre Zugangsdaten eintauscht. Tokens sollten eng gefasst sein (dieser Job, diese Ressourcen, Lesen vs. Schreiben) und schnell ablaufen, sodass ein durchgesickertes Token nahezu wertlos ist.
Die Pipeline-Definition schützen
Die Pipeline-Konfiguration ist Code mit Produktionszugriff. Stellen Sie sie unter geschützte Branches mit erforderlicher Prüfung, damit niemand still einen Schritt hinzufügen kann, der Secrets exfiltriert. Pinnen Sie Drittanbieter-Actions/Plugins an einen Commit-Digest (kein veränderbares Tag) — eine ungepinnte Action kann auf bösartigen Code umgelenkt werden, der mit den Berechtigungen Ihrer Pipeline läuft. Genau so sind reale Lieferkettenvorfälle abgelaufen.
Alles auditieren
Protokollieren Sie, wer was ausgelöst hat, welche Zugangsdaten verwendet wurden und was deployt wurde. Sie können einen Pipeline-Missbrauch, den Sie nicht aufgezeichnet haben, weder erkennen noch untersuchen.
Worauf Interviewer achten
Sie wollen, dass Sie die Pipeline als erstklassiges Ziel einordnen, mit OIDC und minimalen Rechten statt gespeicherter Secrets führen und ephemere Runner sowie gepinnte Abhängigkeiten erwähnen — die Kontrollen hinter den jüngsten realen CI/CD-Kompromittierungen.
Wahrscheinliche Anschlussfragen
- Warum OIDC-Föderation dem Speichern langlebiger Cloud-Schlüssel in der CI vorziehen?
- Worin besteht das Risiko einer ungepinnten Drittanbieter-CI-Action?
- Wie kann ein bösartiger Pull Request einen schlecht konfigurierten Runner missbrauchen?