GitHub Actions & npm: So sichert ihr eure Open-Source-Sup...
TL;DR: Angreifer kompromittieren zunehmend GitHub-Actions-Workflows, um CI/CD-Secrets zu stehlen und darüber Malware in npm-Pakete einzuschleusen. GitHub hat daraufhin eine umfangreiche Security-Roadmap für 2026 vorgelegt – mit SHA-Locking, Egress-Firewalls und Policy Controls. Was ihr jetzt tun könnt, was GitHub liefern wird und wie Trusted Publishing die Angriffsfläche dauerhaft reduziert.
Am 1. April 2026 veröffentlichte Zachary Steindler (Principal Software Engineer bei GitHub) einen Lagebericht zur Sicherheit der Open-Source-Supply-Chain auf GitHub. Der Beitrag ist eine direkte Reaktion auf eine Angriffswelle, die in den vergangenen Monaten Entwicklungsteams weltweit getroffen hat – und gibt konkrete Handlungsempfehlungen sowie einen Ausblick auf die GitHub Security Roadmap 2026.
Die wichtigsten Punkte
- 📅 Veröffentlicht: 1. April 2026 (GitHub Blog)
- 🎯 Zielgruppe: Alle Teams, die GitHub Actions für CI/CD einsetzen – unabhängig von Technologie oder Teamgröße
- 💡 Kernproblem: Angriffe zielen auf Secrets-Exfiltration in Actions-Workflows, um darüber Paket-Repositories zu kompromittieren
- 🔧 Tech-Stack: GitHub Actions, npm, CodeQL, Dependabot, OpenID Connect (Trusted Publishing)
Was steckt hinter den aktuellen Angriffen?
Das wiederkehrende Muster ist eindeutig: Angreifer kompromittieren populäre GitHub Actions (zuletzt etwa tj-actions/changed-files und reviewdog/action-setup, CVE-2025-30066 und CVE-2025-30154), injizieren Schadcode über manipulierte Repository-Tags und leiten Nutzer auf maliziöse Commits um. Der eigentliche Schaden entsteht danach: Der injizierte Code exfiltriert CI/CD-Secrets aus Workflow-Logs – API-Keys, Tokens, Credentials – und nutzt diese, um kompromittierte Pakete von einem Angreifer-kontrollierten System zu veröffentlichen.
npm ist mit über 30.000 täglich neu veröffentlichten Paketen besonders exponiert. Täglich werden laut GitHub Hunderte neu publizierter Pakete als bösartig erkannt. Jüngster prominenter Fall: Am 30./31. März 2026 wurde das npm-Paket axios (~83 Millionen wöchentliche Downloads) über einen kompromittierten Maintainer-Account angegriffen.
Für Teams bedeutet das: Jeder Workflow, der mit mutable Tags auf externe Actions verweist, ist potentiell angreifbar – unabhängig davon, ob es sich um ein Open-Source-Projekt oder ein internes Enterprise-Repository handelt.
Was ihr heute konkret tun könnt
GitHub nennt drei sofort umsetzbare Maßnahmen:
1. CodeQL für eure Actions-Workflows aktivieren
Die wichtigste Einzelmaßnahme: CodeQL zur Überprüfung eurer GitHub-Actions-Workflow-Implementierungen aktivieren (direkt in den Repository-Einstellungen). CodeQL prüft Workflows automatisch auf Security Best Practices und ist für öffentliche Repositories kostenlos verfügbar.
2. SHA-Pinning für alle Third-Party Actions
Statt auf mutable Tags wie actions/checkout@v4 zu verweisen, solltet ihr Actions auf einen vollständigen Commit-SHA pinnen. Vertrauenswürdige Tools wie Dependabot können diese Pins automatisch pflegen und per Pull Request aktualisieren. Wichtig: Seid misstrauisch gegenüber externen Pull Requests, die diese SHA-Pins verändern – das ist ein bekannter Angriffsvektor.
3. Keine pull_request_target-Trigger für ungeprüfte Forks
Der pull_request_target-Event-Trigger gibt Forks Zugriff auf Repository-Secrets. Vermeidet ihn, sofern ihr keinen konkreten Grund habt und die Implikationen vollständig versteht. Achtet zudem auf Script-Injection bei der Verarbeitung von nutzergenerierten Inhalten in Workflow-Schritten.
Ergänzend empfiehlt GitHub die regelmäßige Prüfung der GitHub Advisory Database und den Einsatz von Dependabot (ebenfalls kostenlos für öffentliche Repositories), der automatisch über kompromittierte oder verwundbare Dependencies informiert.
Was GitHub bereits umgesetzt hat: Trusted Publishing
Der strukturell wichtigste Schritt ist der Wechsel von langlebigen Secrets hin zu kurzlebigen OpenID-Connect-Tokens (Trusted Publishing). Statt einem statischen API-Key enthält ein OIDC-Token die Workload Identity des konkreten Workflows – und wird nach Abschluss des Jobs wertlos.
GitHub hat Trusted Publishing gemeinsam mit der OpenSSF in den wichtigsten Paket-Repositories implementiert: npm, PyPI, NuGet, RubyGems und Crates unterstützen das Verfahren bereits. Der Nebeneffekt ist ebenfalls wertvoll: Wenn ein Paket plötzlich aufhört, Trusted Publishing zu verwenden, ist das ein messbares Warnsignal – die Community kann diesen Wechsel direkt als Indiz für eine potentielle Kompromittierung werten.
GitHub Security Roadmap 2026: Was kommt in den nächsten Monaten?
Als Reaktion auf die aktuelle Angriffswelle hat GitHub seine Actions-Security-Roadmap beschleunigt. Die Maßnahmen gliedern sich in drei Ebenen:
Ecosystem-Ebene (Dependencies sichern)
-
Workflow-level Dependency Locking: Eine
dependencies:-Sektion im Workflow-YAML fixiert direkte und transitive Action-Dependencies per SHA – vergleichbar mitgo.mod/go.sumin Go. Bei einem Hash-Mismatch schlägt der Build fehl, bevor Schadcode ausgeführt werden kann. - Sichere Publishing-Mechanismen für das Paket-Ökosystem
Angriffsflächen-Ebene (Execution kontrollieren)
- Policy-driven Execution via Rulesets: Organisationsweite Richtlinien, welche Actions unter welchen Bedingungen ausgeführt werden dürfen
- Scoped Secrets: Secrets werden nur noch den Workflows zugänglich gemacht, die sie tatsächlich benötigen
- Secure Defaults: Systematische Reduktion von Over-Permissions und Schutz gegen „Pwn Request”-Angriffsvektoren
Infrastruktur-Ebene (Observability)
- Actions Data Stream: Echtzeit-Telemetrie für laufende Workflows (Ausgabe an S3 oder Event Hub)
- Egress-Firewalls: Kontrolle über ausgehende Netzwerkverbindungen aus Workflow-Jobs
- Process- und Filesystem-Monitoring innerhalb von Runner-Umgebungen
Preview dieser Fähigkeiten ist für die nächsten 3–6 Monate angekündigt, General Availability in 6–9 Monaten. Feedback kann direkt im GitHub Community Discussion Post eingebracht werden.
Was bedeutet das für Teams?
Die Botschaft von GitHub ist klar: Open Source ist ein globales Gemeingut, und Angriffe auf die Supply Chain werden nicht aufhören. Die Schutzmaßnahmen entwickeln sich von reaktiven Patches hin zu strukturellen, deterministischen Absicherungen.
Für Teams in der Praxis zeigt sich folgende Priorisierung:
- Sofort: CodeQL für Actions-Workflows aktivieren, SHA-Pinning einführen, Dependabot aktivieren
- Kurzfristig (Q2/Q3 2026): Migration auf Trusted Publishing für npm/PyPI/NuGet – Secrets aus Build-Pipelines eliminieren
- Mittelfristig: GitHub Actions Security Roadmap verfolgen und frühzeitig in Previews einsteigen, um Workflow-Dependency-Locking zu implementieren
Die Lernkurve für SHA-Pinning und Trusted Publishing ist überschaubar – der Sicherheitsgewinn hingegen erheblich. Besonders in Teams mit vielen parallelen Projekten zahlt sich eine zentrale Policy (z.B. über GitHub Rulesets) schnell aus.
