Dein Blog zum Thema digitales Business

GitHub Actions ist für viele kleine Softwarehäuser die zentrale Pipeline. Code landet im Repo, ein Workflow baut, testet und deployt. Das ist praktisch und genau deshalb gefährlich: Die Pipeline hat Zugriff auf Secrets, Cloud-Konten und Produktivumgebungen. Wer sie kompromittiert, braucht den Server nicht mehr anzugreifen. Hier sind fünf Schwachstellen, die in der Praxis immer wieder auftauchen, und was dagegen hilft.

1. Actions über Tags statt Commit-SHA eingebunden

Die meisten Workflows binden fremde Actions per Tag ein, etwa uses: actions/checkout@v4. Ein Tag ist aber kein fester Stand. Wer Schreibrechte auf das Action-Repo bekommt, kann den Tag auf neuen Code umbiegen, und der läuft beim nächsten Build mit allen Secrets der Pipeline. Genau so liefen mehrere Supply-Chain-Vorfälle der letzten Jahre ab. Die Gegenmaßnahme ist einfach: Actions auf den vollen Commit-SHA pinnen, also uses: actions/checkout@<sha>. Dann ist der Stand reproduzierbar und kann nicht hinter dem Rücken ausgetauscht werden.

2. pull_request_target mit Checkout des Fork-Codes

Der Trigger pull_request_target läuft im Kontext des Ziel-Repos und hat damit Zugriff auf die Secrets. Wer in so einem Workflow den Code aus dem Pull Request auscheckt und ausführt, gibt einem fremden Beitragenden faktisch die Schlüssel. Ein präparierter Fork-PR kann dann Secrets auslesen und nach außen schicken. Wenn du den Trigger brauchst, etwa um PRs zu labeln, dann checke niemals den PR-Code aus und führe ihn nicht aus. Für Builds, die den Fork-Code testen, ist pull_request der richtige Trigger, weil er ohne Secrets läuft.

3. GITHUB_TOKEN mit zu weiten Rechten

Das automatisch erzeugte GITHUB_TOKEN hat je nach Repo-Einstellung Schreibrechte auf fast alles. Die meisten Jobs brauchen nur Lesen. Setze die Berechtigungen explizit und eng, am besten global auf permissions: read-all und pro Job nur das, was er wirklich braucht. Das begrenzt den Schaden, falls ein Schritt kompromittiert wird, und macht im Workflow sichtbar, welcher Job überhaupt schreiben darf.

4. Secrets, die im Log landen

GitHub maskiert bekannte Secret-Werte in den Logs, aber nur, wenn sie exakt so auftauchen. Sobald ein Secret transformiert, base64-kodiert oder Teil einer längeren Ausgabe wird, greift die Maskierung nicht mehr. Ein echo zum Debuggen oder ein Tool, das seine Konfiguration ausgibt, reicht. Logs sind in vielen Repos breit einsehbar. Gib Secrets nie bewusst aus, reiche sie nur über Umgebungsvariablen an die Schritte, die sie brauchen, und prüfe Build-Logs stichprobenartig auf versehentliche Lecks.

5. Self-hosted Runner ohne Isolation

Selbst gehostete Runner sind attraktiv, weil sie schneller und billiger sein können. Das Problem: Sie sind persistent. Was ein Job auf der Maschine ablegt, findet der nächste Job. Hängt so ein Runner an einem öffentlichen Repo, kann ein Fork-PR Code auf deiner Infrastruktur ausführen und sich dort festsetzen. Self-hosted Runner gehören nie an öffentliche Repos ohne strenge Freigabe. Wenn du sie brauchst, dann ephemer, also für jeden Job eine frische Maschine, die danach verworfen wird.

Worauf es ankommt

Keine dieser fünf Schwachstellen braucht ein ausgeklügeltes Angriffsszenario. Sie entstehen aus Bequemlichkeit und Standardeinstellungen, die für offene Zusammenarbeit gedacht sind, nicht für den Schutz von Produktiv-Secrets. Die gute Nachricht: Alle fünf lassen sich an einem Nachmittag prüfen und meistens mit wenigen Zeilen im Workflow schließen.

GitSecOps QuickCheck: Wir prüfen deine Pipeline systematisch auf genau diese Lücken und liefern einen priorisierten Befundbericht. Festpreis 1.990 € netto, Ergebnis in 3 Werktagen. Kontakt: mm@crank.zone.