Was sind die Lieferketten-Risiken in Cloud-CI/CD und wie reduziert man sie?
Kurzantwort
CI/CD ist hochwertig, weil sie Deployment-Anmeldedaten hält und nicht vertrauenswürdigen Code ausführt. Risiken umfassen kompromittierte Abhängigkeiten und Build-Actions, geleakte oder zu weit gefasste Secrets, veränderliche Drittanbieter-Actions sowie überprivilegierte Runner oder OIDC-Vertrauen. Reduziere sie mit fixierten und verifizierten Abhängigkeiten, kurzlebiger OIDC-Föderation statt langlebiger Schlüssel, geringsten Rechten eingegrenzt auf konkrete Repos/Branches, isolierten ephemeren Runnern und signierten Artefakten mit nachverfolgter Provenienz (SLSA).
Die CI/CD-Pipeline ist eines der attraktivsten Ziele in einer Cloud-Umgebung: Sie hält normalerweise die Anmeldedaten, die in die Produktion deployen können, und sie führt routinemäßig Code aus vielen Quellen aus. Kompromittiere die Pipeline und du kannst eine Hintertür mit der eigenen Signatur des Projekts ausliefern.
Woher das Risiko kommt
- Abhängigkeiten und Build-Actions. Ein vergiftetes npm-/PyPI-Paket oder eine gekaperte Drittanbieter-CI-Action läuft innerhalb deiner vertrauenswürdigen Pipeline. Veränderliche Tags (
actions/checkout@v4) können nach deiner Übernahme auf bösartigen Code umgebogen werden. - Secrets in der Pipeline. Langlebige Cloud-Admin-Schlüssel, die als CI-Secrets gespeichert sind, sind ein einzelnes hochwertiges Ziel; sie lecken über Logs, Forks oder Pull-Request-Workflows.
- Überprivilegierte Runner und Vertrauen. Ein geteilter Runner, der viele Repos verarbeitet, oder eine zu weit gefasste OIDC-Vertrauensrichtlinie lässt ein kompromittiertes Repo weit über sich hinausreichen.
Wie man es reduziert
- Fixieren und verifizieren. Fixiere Abhängigkeiten und Drittanbieter-Actions auf unveränderliche Digests / Commit-SHAs und verifiziere Prüfsummen oder Signaturen, sodass ein umgebogener Tag keinen neuen Code einschmuggeln kann.
- Nutze OIDC-Föderation, keine statischen Schlüssel. Der Runner tauscht ein signiertes OIDC-Token gegen kurzlebige Cloud-Anmeldedaten ein, eingegrenzt auf ein konkretes Repo und einen konkreten Branch. Nichts Langlebiges liegt in CI zum Stehlen.
- Geringste Rechte und Isolation. Grenze die Cloud-Rolle der Pipeline genau auf das ein, was ein Deployment braucht, und nutze ephemere Einweg-Runner, sodass Build-Zustand nie zwischen Jobs leckt.
- Artefakte signieren und Provenienz nachverfolgen. Erzeuge signierte Build-Provenienz (SLSA), sodass Konsumenten verifizieren können, dass ein Artefakt aus deiner echten Pipeline stammt und nicht ausgetauscht wurde.
Worauf Interviewer achten
Die Pipeline als ein anmeldedaten-haltendes, code-ausführendes Asset erkennen, kurzlebige OIDC-Anmeldedaten statt statischer Schlüssel, Digest-Fixierung und Artefakt-Provenienz/Signierung nennen.
Wahrscheinliche Anschlussfragen
- Warum ist das Fixieren einer GitHub Action auf einen vollständigen Commit-SHA sicherer als auf einen Tag?
- Wie beseitigt OIDC-Föderation den Bedarf an langlebigen Cloud-Schlüsseln in CI?
- Was ist Build-Provenienz / SLSA und gegen welchen Angriff schützt sie?