CI/CD für ein Open-Source-Projekt absichern: Kontrolle darüber, wer was ausführt

TL;DR

Cilium hat Maßnahmen ergriffen, um die Sicherheit seiner CI/CD-Pipeline zu erhöhen und die Risiken bei der Nutzung von Open-Source-Software zu minimieren. Die wichtigsten Kontrollen umfassen Einschränkungen bei Workflow-Auslösern, zwei Phasen bei der Codeausführung, SHA-pinning von Abhängigkeiten und die Signierung von Releases. Diese Praktiken sind für jedes Open-Source-Projekt von Bedeutung und können auf ähnliche CI/CD-Umgebungen angewendet werden.

Hauptinhalt

In den letzten zwölf Monaten gab es mehrere bedeutende Sicherheitsvorfälle in der Open-Source-Lieferkette, die auf die Verwundbarkeit von CI/CD-Umgebungen hinweisen. Angriffe auf Pakete in Repositories wie npm und PyPI haben dazu geführt, dass bösartige Software in ansonsten legitime Releases eingeschleust wurde. Diese Vorfälle verdeutlichen die Notwendigkeit, Open-Source-Projekte gegen solche Bedrohungen abzusichern, insbesondere für Projekte wie Cilium, das in der Netzwerkebene von Millionen von Kubernetes-Pods eingesetzt wird.

Cilium hat verschiedene Sicherheitsmaßnahmen implementiert, um sicherzustellen, dass nur autorisierte Personen Builds auslösen und dass der ausgeführte Code sicher ist. Eine zentrale Komponente ist Ariane, ein In-House-Tool, das die Ausführung von CI-Workflows aus PR-Kommentaren steuert. Nur Mitglieder der Organisation mit überprüften Berechtigungen können CI-Workflows auslösen, und die erlaubten Workflows sind in einer Konfigurationsdatei festgelegt.

Um zu gewährleisten, dass nur vertrauenswürdiger Code ausgeführt wird, verwendet Cilium ein zweistufiges Checkout-Verfahren für Pull-Requests. Dabei wird der vertrauenswürdige Code aus dem Basis-Branch geladen, während der Code des PR-Kopfes lediglich als Docker-Build-Kontext dient und nicht als Skript ausgeführt wird.

Die Überprüfung von CI-Änderungen erfolgt durch die CODEOWNERS-Datei, die sicherstellt, dass Änderungen im Verzeichnis .github/ von einem sicherheitsfokussierten CI-Team überprüft werden. Zudem werden alle Abhängigkeiten, die in CI verwendet werden, durch SHA-Pinning gesichert, was bedeutet, dass jede verwendete Referenz auf einen spezifischen Commit verweist.

Ein weiteres Sicherheitsmerkmal ist die Verwendung von vendored Go-Abhängigkeiten, die sicherstellen, dass alle Abhängigkeiten überprüft und im vendor/-Verzeichnis gespeichert werden. Dies reduziert das Risiko, dass ein gehacktes oder typosquatted Modul unentdeckt bleibt.

Die CI-Umgebung ist von Produktionsumgebungen isoliert, sodass CI-Anmeldeinformationen nur auf Entwicklungs-Tags zugreifen können. Produktionsanmeldeinformationen sind in einer geschützten Umgebung gespeichert, die eine Genehmigung durch einen Maintainer erfordert.

Technische Details/Implikationen

Die Implementierung dieser Sicherheitsmaßnahmen erfordert eine sorgfältige Planung und kontinuierliche Überwachung. Die Verwendung von SHA-Pinning und vendored Abhängigkeiten bietet eine zusätzliche Sicherheitsebene, die in vielen Projekten noch nicht standardmäßig implementiert ist. Die Isolation von CI- und Produktionsanmeldeinformationen ist entscheidend, um das Risiko einer Kompromittierung zu minimieren.

Die Herausforderungen, die Cilium noch zu bewältigen hat, umfassen das Fehlen von SLSA-Provenienz, die Notwendigkeit einer PR-Zeit-Abhängigkeitsüberprüfung und die Implementierung von govulncheck in CI. Diese Aspekte sind wichtig, um die Sicherheitsstandards weiter zu erhöhen und die Integrität der Software zu gewährleisten.

Fazit/Ausblick

Die Sicherheitspraktiken von Cilium bieten wertvolle Einblicke in die Absicherung von CI/CD-Pipelines für Open-Source-Projekte. Die kontinuierliche Verbesserung und Anpassung dieser Maßnahmen wird entscheidend sein, um zukünftigen Bedrohungen in der Software-Lieferkette proaktiv zu begegnen.