CI/CD-Sicherheit

Warum Pipelines ein Ziel sind

• Sie verwahren die Schlüssel. Cloud-Zugangsdaten, Registry-Tokens und Signaturschlüssel laufen alle durch das CI.
• Sie führen fremden Code aus. Jede Abhängigkeit, jedes Install-Skript und jede Action von Dritten läuft auf dem Runner.
• Sie erreichen die Produktion. Was aus der Pipeline kommt, gilt als vertrauenswürdig, wird signiert und ausgeliefert. Ein Angreifer im Build erreicht alle Kunden auf einmal.
• Nur wenige beobachten sie. Workflow-Dateien ändern sich selten und werden weniger geprüft als Anwendungscode.

Die tj-actions-Kompromittierung und der npm-Wurm Shai-Hulud hatten es beide auf Secrets im CI abgesehen. Wie solche Angriffe ablaufen, lesen Sie unter Was ist ein Lieferkettenangriff.

Die größten CI/CD-Sicherheitsrisiken

Die OWASP Top 10 CI/CD Security Risks sind die Standardreferenz. Gruppiert danach, was schiefgeht:

Bereich	OWASP-Risiken	Wie es aussieht
Wer was ändern kann	Unzureichende Flusskontrolle, unzureichendes Identitäts- und Zugriffsmanagement	Code erreicht die Produktion ohne Prüfung, oder alte Konten behalten ihren Zugriff
Was in der Pipeline läuft	Missbrauch der Abhängigkeitskette, Poisoned Pipeline Execution	Ein bösartiges Paket oder ein geänderter Workflow läuft mit den Rechten des Jobs
Was ein Job erreichen kann	Unzureichende Pipeline-basierte Zugriffskontrollen, unzureichende Hygiene bei Zugangsdaten	Ein Job kann jedes Secret lesen, und Tokens gelten jahrelang
Wie es eingerichtet ist	Unsichere Systemkonfiguration, unkontrollierte Nutzung von Drittanbieterdiensten	Ungepatchte Runner und Integrationen mit mehr Zugriff als nötig
Was Sie nachweisen können	Fehlerhafte Prüfung der Artefaktintegrität, unzureichende Protokollierung und Sichtbarkeit	Niemand kann sagen, was in ein Release eingeflossen ist oder womit sich ein Job verbunden hat

Jedes Risiko, zugeordnet zu Runner-Kontrollen, finden Sie unter Runner-Sicherheit im Vergleich.

Best Practices für CI/CD-Sicherheit

1. Behandeln Sie Pipeline-Definitionen wie Produktionscode. Verlangen Sie Reviews für Workflow-Dateien, und halten Sie nicht vertrauenswürdige Pull Requests von Secrets fern.
2. Begrenzen Sie, was jeder Job darf. Geben Sie Tokens die geringsten nötigen Rechte, und ziehen Sie kurzlebige Zugangsdaten gespeicherten Secrets vor.
3. Pinnen Sie Actions von Dritten auf einen Commit-Hash. Tags lassen sich auf anderen Code verschieben.
4. Isolieren Sie Jobs. Lassen Sie jeden Job in einer frischen Umgebung laufen, damit nichts in den nächsten übergeht.
5. Kontrollieren Sie ausgehenden Datenverkehr. Ein Build braucht bekannte Quellen und bekannte Ziele. Alles andere zu blockieren verhindert, dass gestohlene Secrets abfließen. Siehe GitHub-Actions-Egress-Richtlinie.
6. Zeichnen Sie auf, was passiert ist. Bewahren Sie eine SBOM jedes Builds und ein Protokoll seiner Netzwerkaktivität auf, damit Sie Fragen im Nachhinein beantworten können.

Die Schritt-für-Schritt-Version finden Sie in der Sicherheitscheckliste für CI/CD-Pipelines.

Arten von CI/CD-Sicherheitstools

Art	Was sie leistet	Beispiele
Runner-Sicherheit	Isoliert Jobs und steuert, was sie während der Ausführung erreichen können	CRACI, StepSecurity
Posture-Management	Findet riskante Pipeline- und Repository-Einstellungen	Legit Security, Cycode, Apiiro, OX Security
Code- und Abhängigkeitsscans	Prüft Code, Abhängigkeiten und Secrets bei jeder Änderung	GitHub Advanced Security, Snyk, Semgrep
SBOM und Nachweise	Zeichnet auf, was in jedes Release eingeflossen ist	CRACI, Syft, Anchore

Diese Tools arbeiten in unterschiedlichen Phasen, deshalb kombinieren die meisten Teams sie. Ein Scanner betrachtet Dateien vor dem Build, Posture-Tools betrachten Einstellungen, und Runner-Sicherheit wirkt, während der Job läuft, also dann, wenn ein bösartiges Paket aktiv wird. Siehe Tools für Software-Lieferkettensicherheit im Vergleich und DevSecOps-Tools im Vergleich.

Wo CRACI ansetzt

CRACI sichert den Build ab, während er läuft. Es ersetzt Ihre GitHub-gehosteten Runner durch schnellere, günstigere: Jeder Job läuft in seiner eigenen isolierten virtuellen Maschine, eine Egress-Richtlinie blockiert Verbindungen, die der Build nicht braucht, und jedes Paket, das der Job lädt, landet in einer SBOM. Weil die Richtlinie nur zulässt, was der Build braucht, schützt sie Sie selbst vor einem Angriff, den noch niemand gesehen hat.

CRACI prüft weder Ihre Workflow-Konfiguration noch scannt es Quellcode oder Secrets, und es signiert keine Provenienz. Behalten oder ergänzen Sie dafür also Tools. GitHub Actions ist heute das unterstützte CI-System, weitere CI-Systeme stehen auf der Roadmap.

CI/CD-Sicherheit: häufig gestellte Fragen

Was ist CI/CD-Sicherheit?

Es ist die Praxis, die Pipelines zu schützen, die Software bauen, testen und ausliefern, einschließlich ihrer Zugangsdaten, des Codes, den sie ausführen, und der Artefakte, die sie erzeugen.

Was sind die größten CI/CD-Sicherheitsrisiken?

Bösartige Abhängigkeiten und Actions von Dritten, vergiftete Pipelines, Tokens mit zu vielen Rechten und langlebige Secrets sowie fehlender Einblick in das, was ein Build getan hat. Die OWASP Top 10 CI/CD Security Risks sind die Standardliste.

Was ist Poisoned Pipeline Execution?

Ein Angreifer ändert, was eine Pipeline ausführt, etwa indem er über einen Pull Request eine Workflow-Datei oder ein von ihr aufgerufenes Skript bearbeitet, sodass sein Code mit den Rechten der Pipeline läuft.

Wie sichern Sie eine CI/CD-Pipeline ab?

Prüfen Sie Pipeline-Änderungen, geben Sie jedem Job nur den nötigen Zugriff, pinnen Sie Actions von Dritten per Commit-Hash, isolieren Sie Jobs, schränken Sie ausgehenden Datenverkehr ein und zeichnen Sie auf, was jeder Build getan hat.

Was ist der Unterschied zwischen CI/CD-Sicherheit und DevSecOps?

DevSecOps ist die breitere Praxis, Sicherheit in die Softwareentwicklung einzubauen. CI/CD-Sicherheit konzentriert sich auf die Pipeline selbst, auf die auch DevSecOps-Tools angewiesen sind.

Braucht GitHub Actions zusätzliche Sicherheit?

GitHub bietet Kontrollen wie Token-Berechtigungen und Secret-Scanning, doch Sie müssen sie konfigurieren, und gehostete Runner schränken ausgehenden Datenverkehr standardmäßig nicht ein. Die meisten Teams ergänzen Pinning, Review-Regeln und Runner-Kontrollen.