Checkliste für CI/CD-Pipeline-Sicherheit

Workflows

• Pinnen Sie Actions von Drittanbietern auf einen vollständigen Commit-SHA. GitHub bezeichnet das als derzeit einzige Möglichkeit, eine Action als unveränderliches Release zu nutzen. Ein Tag lässt sich so ändern, dass es auf anderen Code zeigt. Im März 2025 meldete CISA, dass jede Version von tj-actions/changed-files drei Tage lang kompromittiert war.
• Geben Sie GITHUB_TOKEN die geringsten nötigen Rechte. Setzen Sie Inhalte standardmäßig auf Nur-Lesen und vergeben Sie mehr pro Job.
• Checken Sie in pull_request_target keinen nicht vertrauenswürdigen Code aus. Diese Workflows laufen mit Secrets und erhöhten Berechtigungen.
• Halten Sie nicht vertrauenswürdige Eingaben aus Skripten heraus. Übergeben Sie Titel, Branch-Namen und andere von Nutzern kontrollierte Werte über eine Umgebungsvariable, statt sie in einem Shell-Befehl zu expandieren.
• Prüfen Sie Änderungen an Workflow-Dateien. Verlangen Sie für .github/workflows ein Review durch die Code Owner.

Secrets

• Bevorzugen Sie kurzlebige Zugangsdaten. Nutzen Sie OpenID Connect, damit Jobs kurzlebige, eng begrenzte Tokens von Ihrem Cloud-Anbieter erhalten statt langlebiger Schlüssel, die als Secrets gespeichert sind.
• Begrenzen Sie Secrets auf Environments. Legen Sie Produktions-Zugangsdaten hinter ein Environment mit erforderlichen Reviewern.
• Rotieren Sie nach einem Vorfall. CISA riet nach der tj-actions-Kompromittierung, offengelegte Secrets als kompromittiert zu behandeln und sofort zu rotieren.

Runner

• Nutzen Sie ephemere Runner. Eine frische Maschine pro Job hinterlässt nichts für den nächsten.
• Halten Sie selbst gehostete Runner von öffentlichen Repositories fern. Laut GitHub sollten sie dort fast nie verwendet werden, weil jeder einen Pull Request gegen das Repository öffnen kann.
• Isolieren Sie Jobs. Ein Job sollte den Workspace oder die Zugangsdaten eines anderen Jobs nicht lesen können.

Netzwerk

• Kontrollieren Sie den ausgehenden Datenverkehr. Erlauben Sie die Paketquellen und Dienste, die ein Job braucht, und blockieren Sie den Rest, damit eine kompromittierte Abhängigkeit keine Secrets nach außen senden kann. Wie eine Egress-Richtlinie Exfiltration stoppt
• Zeichnen Sie Verbindungen auf. Bewahren Sie einen Trace dessen auf, womit sich jeder Job verbunden hat, damit Sie später nachforschen können.

Abhängigkeiten

• Committen Sie Lockfiles. Builds sollten jedes Mal dieselben Versionen auflösen.
• Prüfen Sie neue Abhängigkeiten. Kontrollieren Sie, was ein Pull Request hinzufügt, bevor er gemergt wird.
• Machen Sie Builds von Befunden abhängig. Blockieren Sie einen Build, wenn er ein Paket mit einer bekannten kritischen Schwachstelle lädt, bevor das Artefakt ausgeliefert wird.

Build-Nachweise

• Zeichnen Sie eine SBOM dessen auf, was der Build geladen hat. Ein nachträglicher Scan von Dateien beschreibt, was deklariert wurde, nicht, was der Build verwendet hat.
• Signieren Sie die Provenienz. Verknüpfen Sie jedes Artefakt mit dem Build, der es erzeugt hat, damit Sie später prüfen können, ob das, was läuft, auch das ist, was gebaut wurde.
• Überwachen Sie das Ausgelieferte. Prüfen Sie veröffentlichte Builds erneut, wenn neue Schwachstellen bekannt werden.

Welche Tools welche Punkte abdecken

Scanner decken die Punkte zu Abhängigkeiten ab, Tools zur Pipeline-Härtung die Punkte zu Workflows, und Agenten auf dem Runner oder ein sicherer Runner die Punkte zu Netzwerk und Nachweisen. CRACI ist der Runner: Es setzt eine Egress-Richtlinie durch, die im Fehlerfall blockiert, zeichnet eine SBOM dessen auf, was jeder Job geladen hat, lässt Policy-Gates einen Build anhand von Befunden blockieren und liefert SBOMs, Netzwerk-Traces und Provenienz über seine API. Code oder Workflows scannt es nicht. Welches Tool was abdeckt, zeigt CI/CD-Sicherheitstools im Vergleich.

CI/CD-Pipeline-Sicherheit: häufig gestellte Fragen

Was ist CI/CD-Pipeline-Sicherheit?

Sie bedeutet, die Systeme zu schützen, die Ihre Software bauen und ausliefern: die Workflow-Definitionen, die verwendeten Secrets, die ausführenden Runner, die geladenen Abhängigkeiten und die erzeugten Artefakte. Eine kompromittierte Pipeline kann unter Ihrem Namen Schadcode ausliefern, ohne Ihren Quellcode anzutasten.

Warum sollten Sie GitHub Actions auf einen Commit-SHA pinnen?

Tags lassen sich so ändern, dass sie auf anderen Code zeigen. Laut GitHub ist das Pinnen einer Action auf einen vollständigen Commit-SHA derzeit die einzige Möglichkeit, eine Action als unveränderliches Release zu nutzen. Im März 2025 meldete CISA, dass jede Version von tj-actions/changed-files drei Tage lang kompromittiert war.

Welche Berechtigungen sollte GITHUB_TOKEN haben?

Die minimal nötigen für jeden Job. Setzen Sie die Standardeinstellung für Repository-Inhalte auf Nur-Lesen und vergeben Sie mehr pro Job, nur wo ein Job es braucht.

Brauche ich eine Kontrolle des ausgehenden Netzwerkverkehrs im CI?

Wenn Ihre Jobs Secrets enthalten und Drittanbieter-Code ausführen, ja. Die meisten Jobs müssen nur eine bekannte Menge von Paket-Registries und Diensten erreichen. Eine Egress-Richtlinie blockiert alles andere, sodass eine kompromittierte Abhängigkeit keine Secrets an den Server eines Angreifers senden kann.