Vier Sicherheitsfunktionen, die 2026 jede GitHub-Actions-Pipeline braucht

SolarWinds im Jahr 2020. Codecov 2021. event-stream 2018. Drei Supply-Chain-Angriffe, die sechs Jahre Denken über CI/CD-Sicherheit geprägt haben, und jeder einzelne begann im Build-Prozess. Am 26. März 2026 hat GitHub eine Sicherheits-Roadmap für Actions veröffentlicht, die genau auf diese Lücke zielt. Vier Funktionen, die ersten Public Previews in drei bis sechs Monaten, GA in sechs bis neun.

Die meisten Teams, mit denen wir arbeiten, schützen ihre Produktionsdatenbank mit einer Firewall, lassen ihren CI-Runner aber weit offen zum Internet. Genau in dieser Lücke agieren Angreifer.

Die Egress-Firewall verändert alles

Das ist die Funktion, auf die es am meisten ankommt. Fangen Sie hier an.

Wenn heute npm install in Ihrer Pipeline läuft, kann dieser Prozess jeden Server der Welt erreichen. Ein kompromittiertes Paket meldet sich nach Hause, exfiltriert Ihre CI-Secrets an einen externen Endpunkt, und Sie erfahren davon Tage später aus den Logs. Vielleicht. Oder Sie erfahren es nie.

GitHub führt eine Layer-7-Firewall ein, die außerhalb der Runner-VM läuft. Sie definieren eine Whitelist erlaubter Domains (registry.npmjs.org, github.com, Ihre private Registry), alles andere wird blockiert. Keine DNS-Auflösung, keine TCP-Verbindung, nichts.

Genau diese Platzierung ist der springende Punkt. Ein Angreifer, der Root auf dem Runner erlangt, kommt an der Firewall trotzdem nicht vorbei, weil die Regeln auf einer Ebene laufen, die er nie erreicht. Innerhalb der VM hätte Root die Diskussion beendet.

Was sich konfigurieren lässt:

• Erlaubte Domains und IP-Adressen
• Erlaubte HTTP-Methoden
• TLS-Anforderungen (Mindestversion, Certificate Pinning)

Wenn Sie clientseitige Sicherheit bereits sauber umsetzen, ist das die fehlende Hälfte. CSP-Header und SRI-Hashes verteidigen, was im Browser passiert. Die Egress-Firewall verteidigt, was im Build passiert. Lassen Sie eines davon weg, bleibt das Loch bestehen.

Ein typischer Supply-Chain-Angriff folgt immer derselben Form. Die kompromittierte Abhängigkeit meldet sich nach Hause, exfiltriert Tokens oder injiziert Schadcode in das Output-Bundle. Die Egress-Firewall killt das auf Netzwerkebene. Nicht durch Logging, nicht durch einen Alert. Die Verbindung kommt schlicht nicht zustande.

Runner-VMs haben derzeit uneingeschränkten Internetzugang. Das ist, als würde man eine Datenbank ohne Firewall betreiben und auf das Beste hoffen.

Die Public Preview der Egress-Firewall kommt um den Jahreswechsel von Q4 2026 auf Q1 2027, GA irgendwann in Q1 oder Q2 2027.

Dependency Locking über SHA

Auf diese Funktion warten wir seit Jahren. Sie funktioniert wie go.mod oder package-lock.json. Jede Action in Ihrem YAML bekommt einen SHA-Hash statt eines Tags.

Heute:

uses: actions/checkout@v4

Der Tag v4 ist nur ein Pointer. Er kann sich jederzeit auf einen anderen Commit verschieben. Ein Force-Push auf den Tag und Ihr nächster Build zieht völlig anderen Code. Ohne Vorwarnung.

Mit Locking:

uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

Eine Änderung des SHA erfordert künftig ein explizites Update, und ein Workflow mit einer nicht gesperrten Referenz läuft gar nicht erst an, weil die Validierung direkt in der Pipeline stattfindet. So weit kam Dependabot nie. Es kann SHA-Referenzen aktualisieren, ihre Verwendung aber niemandem aufzwingen. Ein Entwickler fügt eine neue Action mit einem Tag hinzu, Dependabot schweigt, niemandem fällt es auf.

Manche Teams pinnen SHAs manuell. Gut. Aber das von Hand zu pflegen ist zusätzliche Arbeit, und die meisten Teams geben es nach einer Weile auf (wie viele Leute in Ihrem Team wissen, auf welchen SHA actions/setup-node@v4 auflöst?). Native Plattformunterstützung löst das genauso, wie package-lock.json die npm-Abhängigkeiten gelöst hat.

Public Preview in Q3 oder Q4 2026, GA zwischen Q4 2026 und Q1 2027.

Policy Controls

Ein zentralisiertes Ruleset-Framework auf Organisationsebene. Admins legen fest, wer Workflows auslösen darf, welche Events erlaubt sind, welche Actions freigegeben sind, welche Runner-Labels vorgeschrieben sind. Eine Stelle statt 40 Pull Requests in 40 Repositories.

Heute wird das über ein Flickwerk aus Branch-Protection-Rules, CODEOWNERS-Dateien, Required Status Checks und Workarounds gelöst. Das Ergebnis ist fragmentiert und mühsam zu auditieren. Für regulierte Branchen (Banken, Gesundheitswesen, öffentlicher Sektor) deckt das neue Framework die Audit-Trail-Anforderungen ab, die wir im Kontext der slowakischen Cybersicherheitsstrategie für 2026 bis 2030 besprochen haben.

Nehmen Sie eine Bank. Produktions-Deployments dürfen dort nur von einem Mitglied des Release-Engineering-Teams ausgelöst werden, nur über den Main-Branch, nur mit einem genehmigten PR. Mit dem neuen Framework ist das eine Policy an einer Stelle. Die Public Preview kommt zusammen mit Dependency Locking in Q3 oder Q4 2026.

CI/CD-Telemetrie

Actions Data Stream, Telemetrie nahezu in Echtzeit an S3 oder Azure Event Hub. GitHub deutet außerdem künftige Sichtbarkeit auf Prozessebene an. Nicht nur „Step X dauerte 45 Sekunden“, sondern „Step X hat die Prozesse A, B, C gestartet und Netzwerkverbindungen zu diesen Adressen geöffnet“.

Wenn ein Step, der normalerweise 30 Sekunden dauert, plötzlich 5 Minuten läuft, hat sich etwas geändert. Streaming an S3/Azure Event Hub bedeutet, dass Sie ohne eigene Skripte an Ihr bestehendes SIEM (Splunk, Elastic, Datadog) anbinden. Nützlich für Compliance-Audits und die forensische Untersuchung nach Vorfällen. Die Public Preview erstreckt sich über Q4 2026 und Q1 2027, GA gemeinsam mit der Egress-Firewall in Q1 oder Q2 2027.

Was jetzt zu tun ist

Pinnen Sie Ihre SHAs mit pinact oder pin-github-action, das ist ein halber Tag Arbeit und senkt das Supply-Chain-Risiko drastisch. Prüfen Sie die Berechtigungen der Workflow-Tokens, denn die meisten Workflows brauchen kein write auf contents oder packages, stellen Sie den Standard also auf read. Werfen Sie Third-Party-Actions von unbekannten Autoren mit 50 Sternen raus. Weniger Abhängigkeiten, kleinere Angriffsfläche. Und finden Sie heraus, wie viele Secrets Ihre Organisation hat und wann sie zuletzt rotiert wurden.

Zwei brauchbare Ausgangspunkte sind GitHubs Security-Hardening-Guide und die OWASP CI/CD Security Top 10.

Beim letzten Audit einer Kunden-Pipeline fanden wir 14 Abhängigkeiten ohne SHA-Pinning. Ein halber Tag zum Beheben. Ohne das Audit wüssten sie es bis heute nicht. Wenn Sie herausfinden möchten, wo Ihre Pipelines stehen, melden Sie sich.