123% mehr gemeldete CVEs pro Tag in 2026 als im Vorjahr.

CI/CD-Sicherheit

Exfiltration aus GitHub Actions mit einer Egress-Richtlinie stoppen

Ein CI-Job verfügt über Secrets und führt Code aus, den er vor einer Minute geladen hat: Actions, Pakete und deren Install-Skripte. Ist irgendetwas davon bösartig, lassen sich die Secrets am einfachsten stehlen, indem man sie an einen Server sendet. Eine Egress-Richtlinie legt fest, welche Server ein Job erreichen darf, und blockiert den Rest.

Aktualisiert am

Wie Secrets einen CI-Job verlassen

Ein Job hat Zugriff auf das Repository-Token, die ihm übergebenen Secrets und alle Cloud-Zugangsdaten, die er übernimmt. Code, der im Job läuft, kann sie lesen. Danach kann er sie auf mehreren Wegen hinausbringen:

  • Über das Netzwerk. Eine Anfrage an einen Server, den der Angreifer kontrolliert. Das ist der Kanal, den eine Egress-Richtlinie schließt.
  • Über Logs. Secrets werden, oft kodiert, in das Job-Log geschrieben. Im März 2025 berichtete CISA, dass die kompromittierte Action tj-actions/changed-files Secrets auf diese Weise offengelegt hat.
  • Über Ausgaben. Artefakte, Caches oder Commits, die mit dem Token des Jobs gepusht werden.

Der Code muss kein bösartiges Paket sein. Ein KI-Agent im Workflow lässt sich durch Prompt Injection kapern, die in einem Issue oder Pull Request versteckt ist, und nutzt dann dieselben Kanäle.

Was eine Egress-Richtlinie leistet

Die meisten Jobs müssen nur eine kurze Liste von Zielen erreichen: Paket-Registries, Container-Registries, Quellcode-Hosts und einige Dienste. Eine Egress-Richtlinie erlaubt diese Liste und blockiert alles andere. Mit einer Default-Deny-Richtlinie schlägt eine Anfrage an einen unbekannten Host fehl, und die Secrets bleiben im Job.

What happens when malware in a build tries to send your secrets out Left, a runner that allows all outbound traffic: the build reaches its package registry and publishes its output, then a malicious install hook sends the build's secrets to an attacker's server, and they arrive. Right, CRACI with a default-deny egress policy: the registry and publish connections are allowed, the connection to the attacker's server is blocked at the policy, and an alert is sent. The policy allows only what the build needs, so it works even against an attack nobody has seen before. Any outbound allowed build job holds your tokens and keys malicious install hook runs no egress policy package registry publish output attacker server allowed allowed secrets sent to the attacker CRACI default-deny egress policy build job on CRACI holds your tokens and keys malicious install hook runs egress policy: only what the build needs package registry publish output attacker server allowed allowed blocked blocked, and you get an alert
The policy allows only what the build needs, instead of looking for known-bad hosts, so it stops a new attack the first time it runs.

Sie schließt nicht jede Tür:

  • Sie verhindert nicht, dass Secrets in Logs geschrieben werden. Halten Sie Logs privat und pinnen Sie Actions auf Commit-SHAs.
  • Auch über ein erlaubtes Ziel können Daten abfließen, halten Sie die Allowlist also eng.
  • Sie sagt Ihnen nicht, welche Pakete bösartig waren. Das ist die Aufgabe von Paket-Screening und einer SBOM.

Drei Wege, sie durchzusetzen

  • Ein Agent auf dem Runner. StepSecurity Harden-Runner wird als erster Schritt eines Jobs hinzugefügt. Es ordnet jede Verbindung dem Schritt zu, der sie aufgebaut hat, erstellt im Audit-Modus eine Baseline und blockiert Egress zu allem, was nicht auf der Allowlist steht.
  • Ein Runner mit integrierter Richtlinie. CRACI setzt die Richtlinie als Runner selbst durch. Auch andere Runner-Anbieter bieten Netzwerkkontrollen, etwa Egress-Filterung auf den Linux-Runnern von Depot und blockierende oder nur beobachtende Egress-Richtlinien bei Namespace.
  • Ihr eigenes Netzwerk. Selbst gehostete Runner hinter einer Firewall oder einem Proxy, die Sie selbst konfigurieren und pflegen.

Einführung, ohne Builds kaputtzumachen

  1. Beobachten. Zeichnen Sie über einige Läufe jede Verbindung auf, die ein Job aufbaut.
  2. Erlauben. Erstellen Sie die Allowlist aus dem, was der Job tatsächlich braucht.
  3. Blockieren. Wechseln Sie zu Default Deny und achten Sie auf Verstöße.
  4. Prüfen. Behandeln Sie jeden neuen Verstoß entweder als fehlende Quelle oder als Vorfall.

Wie CRACI das umsetzt

Bei CRACI ist die Egress-Richtlinie Teil des Runners. Sie wird vor dem Start des Jobs validiert, unbekannte Felder werden abgelehnt, und sie blockiert im Zweifel (fail closed). Integrierte Presets decken gängige Paketquellen ab, benutzerdefinierte Quellen und Verbindungen ergänzen den Rest. Der Job-Trace listet jede Verbindung auf und jede blockierte als Verstoß mit ihrem Grund. Weil der Proxy paketbewusst ist, wird dieselbe Aufzeichnung zur SBOM des Jobs. Die API liefert SBOMs, Netzwerk-Traces und Provenienz.

CRACI hat noch keinen eigenen Audit-Modus; er ist auf der Roadmap. Ohne Netzwerkrichtlinie wird der Datenverkehr eines Jobs erlaubt und im Trace aufgezeichnet, sodass Sie sehen, was eine Richtlinie braucht, bevor Sie sie durchsetzen. CRACI führt GitHub-Actions-Jobs auf Linux aus. Siehe CI/CD-Sicherheitstools im Vergleich und CRACI vs. StepSecurity.

Egress-Richtlinien im CI: häufig gestellte Fragen

Was ist eine Egress-Richtlinie im CI?

Ein Regelwerk für die ausgehenden Netzwerkverbindungen, die ein CI-Job aufbauen darf. Der Job erreicht die Paket-Registries und Dienste, die er braucht, und jedes andere Ziel wird blockiert.

Hätte eine Egress-Richtlinie die Kompromittierung von tj-actions gestoppt?

Allein nicht. In diesem Fall wurden Secrets laut CISA über Workflow-Logs offengelegt und nicht an einen externen Server gesendet. Eine Egress-Richtlinie schließt den Netzwerkkanal; das Pinnen von Actions auf Commit-SHAs und private Logs sichern den Log-Kanal ab.

Macht das Blockieren von Egress Builds kaputt?

Das kann passieren, wenn der Richtlinie eine Quelle fehlt, die der Build braucht. Zeichnen Sie zuerst auf, womit sich der Job verbindet, erstellen Sie daraus die Allowlist und blockieren Sie dann. Bei CRACI decken integrierte Presets gängige Paketquellen ab, und eine blockierte Verbindung erscheint mit dem Grund im Job-Trace.

Kann ich eine Egress-Richtlinie auf GitHub-gehosteten Runnern nutzen?

Ja, mit einem Agenten, der dem Job hinzugefügt wird, etwa StepSecurity Harden-Runner. Oder Sie verlagern den Job auf einen Runner, der die Richtlinie selbst durchsetzt, etwa CRACI.

Stellen Sie einen Job hinter eine Egress-Richtlinie

Lassen Sie einen Workflow auf CRACI laufen und sehen Sie jede aufgebaute Verbindung, welche eine Default-Deny-Richtlinie blockieren würde, und die SBOM des Geladenen.

Demo buchen