GitHub Actions hat zwar einen Paketmanager, kann aber der schlechteste sein

• GitHub Actions nutzt in Workflow-Dateien die uses:-Syntax mit einer Struktur zum Deklarieren und Ausführen von Paketabhängigkeiten, wodurch es faktisch wie ein Paketmanager funktioniert
• Es fehlen jedoch grundlegend Funktionen, die andere Paketmanager standardmäßig bieten, wie Lockfile, Integritäts-Hash, transitive Dependency-Pinning, Sichtbarkeit des Abhängigkeitsbaums usw.
• Nach Recherchen führen die meisten GitHub-Actions-Nutzer nicht verifizierten externen Code aus, und es wurden Code-Injection-Schwachstellen in tausenden Workflows gefunden
• GitHub hat einige Gegenmaßnahmen eingeführt (immutable Releases, SHA-Pin-Policy usw.), doch Probleme mit transitiven Abhängigkeiten und Reproduzierbarkeit sind weiterhin ungelöst
• Diese strukturellen Mängel wirken sich auf die gesamte Software-Lieferkettensicherheit aus und verbreiten sich auf andere CI-Systeme, die auf GitHub Actions basieren

---

Paketverwaltungsstruktur und Probleme von GitHub Actions

• Die Syntax uses: actions/checkout@v4 ist eine Abhängigkeitsdeklaration, die GitHub auswertet, herunterlädt und ausführt
  • Das entspricht dem üblichen Verhalten eines Paketmanagers, aber ohne Lockfile kann bei jedem Lauf eine andere Version ausgewählt werden
• Im Vergleich zu anderen Paketmanagern (npm, Cargo, NuGet usw.) fehlen Actions Lockfile, transitive Pinning-Funktionen, Integritätsprüfung, Sichtbarkeit des Abhängigkeitsbaums und eine Auflösungs-Spezifikation vollständig
• Der zentrale Punkt ist das Fehlen eines Lockfiles, wodurch sich die Abhängigkeitsauflösung von Ausführung zu Ausführung ändert und nichtdeterministische Builds entstehen

Sicherheitsergebnisse und Schwachstellen

• Laut einer USENIX-Security-Studie von 2022 führen 99,7 % der Repositories externe Actions von Drittentwicklern aus, 97 % von nicht verifizierten Herausgebern, und 18 % weisen fehlende Sicherheitsupdates auf
• In einer Folgestudie wurden in über 4.300 von 2,7 Millionen Workflows Code-Injection-Schwachstellen entdeckt
• GitHub Actions bietet zentrale Sicherheitsattribute von CI/CD wie admittance control, execution control, code control und Zugriffskontrolle auf Secrets nicht ausreichend

Zentrale technische Schwächen

• Variabler Versionsaspekt: Tags wie @v4 können von Maintainer:innen mit einem neuen Commit erneut gesetzt werden, wodurch Code still verändert werden kann
  • Mit einem Lockfile könnte dokumentiert werden, welcher SHA für dieses Tag aufgelöst wurde
• Intransparenz transitiver Abhängigkeiten: Actions, die innerhalb einer Composite Action aufgerufen werden, sind nicht einsehbar und nicht kontrollierbar
  • Laut Studie enthalten 54 % der JavaScript-Actions Sicherheitslücken, wobei die meisten aus indirekten Abhängigkeiten stammen
  • Beim Vorfall tj-actions/changed-files führte ein Update transitiver Abhängigkeiten zu einem Secret-Leak-Angriff
• Fehlende Integritätsprüfung: npm oder Cargo speichern Hashes und validieren damit den Download, während Actions sich allein auf SHA-basierte Vertrauensannahmen verlässt
• Nicht reproduzierbare Wiederholung: GitHub gibt an, dass bei einem „force push“ auf eine Version die neueste Version gezogen wird, sodass dasselbe Workflow-Dokument unterschiedlichen Code ausführen kann
• Nicht sichtbarer Abhängigkeitsbaum: Funktionen wie npm ls in npm oder cargo tree in Cargo fehlen, daher gibt es keine Möglichkeit, die gesamte Abhängigkeitsstruktur einzusehen
• Intransparente Auflösungsregeln: Die Abhängigkeitsauflösung von Actions ist nicht dokumentiert und der Code in ActionManager.cs enthält nur eine einfache rekursive Download-Logik

Zusätzliche strukturelle Grenzen

• Fehlendes zentrales Registry: Actions befinden sich in Git-Repositories und verfügen über keinen zentralen Mechanismus für Sicherheits-Scans, Malware-Erkennung oder Typosquatting-Schutz
• Gemeinsame Umgebung: Mehrere Actions ändern dasselbe $PATH, sodass das Ergebnis je nach Ausführungsreihenfolge variiert
• Keine Offline-Ausführung: Bei jedem Lauf muss von GitHub heruntergeladen werden; ohne Netzwerk ist eine Ausführung nicht möglich
• Namespace-Schwachstellen: Der GitHub-Benutzername ist zugleich der Namespace und damit anfällig für Kontoübernahmen und Tippfehlerangriffe
  • Mit Lockfile und Integritäts-Hashes ließen sich Codeänderungen durch Buildfehler erkennen

Entwurfsgrundlage und Auswirkungen

• Der Actions-Runner wurde ursprünglich auf Azure DevOps aufgebaut und für eine intern vertrauensvolle Umgebung konzipiert
  • Als GitHub dies zu einem öffentlichen Marktplatz ausweitete, wurde das Vertrauensmodell nicht neu entworfen
• Dadurch wurden Basisfunktionen wie Lockfile, Integritätsprüfung, transitive Pinning-Mechanismen, Sichtbarkeit von Abhängigkeiten weggelassen
• Mit der Ausbreitung der OIDC-basierten automatisierten Paketverteilung wirkt sich der Sicherheitsmangel von Actions auf die gesamte Supply-Chain-Sicherheit von Paketregistries aus
• Während GitLab CI das Schlüsselwort integrity für Hash-Verifikation eingeführt hat, schloss GitHub einen vergleichbaren Antrag mit dem Vermerk „No plans“ ab
• GitHub-kompatible CI-Systeme wie Forgejo Actions müssen dieselbe Struktur beibehalten, wodurch sich diese Schwächen auf das gesamte Ökosystem ausdehnen

Verbesserungsvorschläge und aktueller Stand

• Die Community hat in Issue #2195 Lockfile-Unterstützung gefordert, doch GitHub schloss es 2022 mit dem Hinweis „No plans“
• Eine Studie von Palo Alto zeigte, dass ein reines SHA-Pinning keine transitive Abhängigkeit absichert
• Einige Teams kompensieren dies mit Dependabot-Updates, eigenem Repository-Vendoring und dem Security-Scanner zizmor
• Die grundlegende Abhilfe wäre die Einführung eines Lockfiles, das SHA- und Integritäts-Hashes für alle Actions und deren transitive Abhängigkeiten speichert
• Solange GitHub dies nicht übernimmt, ist eine belastbare Sicherung der CI/CD-Lieferkette nicht möglich

[holywork]

Wahrscheinlich begreift man es erst, wenn man selbst gehackt wurde.

[GN⁺]

Hacker-News-Kommentar

• Ich will GHA (GitHub Actions) nicht verteidigen, aber in der Dokumentation steht ausdrücklich, dass zur Stabilität und Sicherheit empfohlen wird, Commit-SHAs festzupinnen
  Man kann das zwar direkt wie eine Lock-Datei umsetzen, aber transitive dependencies lassen sich damit nicht kontrollieren, also ist es nicht vollständig
  Am Ende entsteht der Aufwand, Security-Patches nachzuverfolgen und Hashes zu aktualisieren, und vermutlich deshalb ist hashbasiertes Pinning nicht weit verbreitet

  • GitHub kannte dieses Problem schon kurz nach dem Start von Actions, hat die Versions-Pinning-Funktion aber praktisch nicht verbessert
    Die meisten Nutzer erkennen das Problem nicht, und selbst die, die es erkennen, verwenden SHA fast nie
    Ich persönlich mag Actions und pflege ein paar davon, aber wenn man sich öffentliche Repositories ansieht, verwenden 90 % @v1, 9 % @v1.2 und nur 1 % Commit-SHAs
    Mit nur wenig Investition hätte GitHub eine Lock-Datei-Lösung bauen können
  • Die Strategie in der Dokumentation löst das Problem der transitive dependencies nicht und ist deshalb in der Praxis keine grundlegende Lösung
  • Die Behauptung, dass das Festpinnen auf Commit-SHAs stabil sei, ist in der Realität falsch
    Oft hängt es von einer bestimmten Node-Version oder API-Version ab, sodass ich die Erfahrung gemacht habe, dass @main manchmal sogar besser gewesen wäre
  • Ich halte die Verwendung von SHA eher für ein Anti-Pattern
    Man glaubt, eine „fixierte Version“ zu bekommen, aber tatsächlich ist das nicht so
    Ich habe das erst nach zwei Problemen begriffen — entweder es gibt eine Lock-Datei oder eben nicht

• GitHub wartet die eigenen Actions kaum, sodass man sich sogar bei Grundfunktionen auf inoffizielle Forks verlassen muss
  Das gesamte Ökosystem wirkt, als würde es nur mit Provisorien am Laufen gehalten

  • Es sieht nicht so aus, als würde sich das so bald bessern
    GitHub hat angekündigt, die Migration zu Azure höher zu priorisieren als die Weiterentwicklung von Features
    Artikel dazu
  • Interessant ist, dass GitHub ein ziemlich teurer Dienst ist
    Selbst unser kleines Unternehmen zahlt monatlich mehr als 200 Dollar
    Es wirkt, als würde das als neue Einnahmequelle betrachtet, die wichtiger ist als Windows
  • Die Qualität der setup- actions* ist spürbar gesunken, und es gibt immer mehr seltsame Entscheidungen
    Vermutlich haben die ursprünglichen Autoren das Unternehmen längst verlassen
  • Davon höre ich zum ersten Mal; ich würde gern wissen, ob es konkrete Beispiele gibt
  • Hat GitHub nicht kürzlich angekündigt, die Entwicklung allgemeiner Features zu verlangsamen, um sich auf AI-Entwicklung zu konzentrieren?

• Mich würde interessieren, ob jemand ArgoCD schon als CI-Pipeline verwendet hat

• Ich halte GHA für ein Beispiel des Scheiterns der Philosophie „less is more“
  Dass es zum Industriestandard geworden ist, ist das größte Problem
  Mit ein wenig Aufwand hätte man ein deutlich besseres CI bauen können, und es fühlt sich an, als würde Microsoft die Fehler aus der IE6-Zeit wiederholen
  Inzwischen erkennt eine jüngere Generation von Engineers ohne Vergleichserfahrung diese Grenzen nicht einmal mehr

  • Alle sind sich einig, dass GHA wirklich miserabel ist, aber wegen der kostenlosen Compute-Ressourcen benutzen es trotzdem alle weiter
    Ich überlege, einen ausgemusterten Laptop als Woodpecker-Server laufen zu lassen. Mich würde interessieren, wie ein CI aussieht, das die Leute nicht hassen
  • Ich gehöre noch zu der Generation, die VSS benutzen musste, und deshalb fühlt sich sogar das heutige GitHub im Vergleich zu damals deutlich besser an
  • Ich erledige die meisten Dinge lieber direkt lokal
    Im Vergleich dazu scheint mir GHA keinen besonderen Mehrwert zu bieten

• Als das Unternehmen von Jenkins/Ansible auf GHA umsteigen wollte, war ich dagegen, und jetzt scheint das die richtige Entscheidung gewesen zu sein
  CI bringt immer hohen Wartungsaufwand mit sich, und insbesondere Mac-Umgebungen sind nach wie vor schwer zu handhaben

• Auf die Frage „Vertraust du darauf, dass GitHub den korrekten SHA-Code liefert?“ gilt:
  Wenn man sieht, dass die meisten GitHub-gehostete Runner verwenden, dann hat man bereits ein viel größeres Problem, falls man dem nicht vertrauen kann

• Ich frage mich, wie es wäre, wenn GitHub Actions local-first aufgebaut wäre und Nix-basiertes Locking unterstützen würde
  cachix/cloud.devenv.sh

  • Ironischerweise wird sogar dieser Code auf GitHub gehostet

• Viele Third-Party-Actions verweisen in ihrer Dokumentation oder in Beispielen direkt auf den master-Branch
  Ein einziger böswilliger Push könnte in zahllosen Repositories Datenabfluss verursachen
  Selbst Tags sind keine vollständige Verteidigung, weil sie verschiebbar sind

• Als ich die vier zentralen Sicherheitsmerkmale von CI/CD sah, von denen Forscher sprachen — Authentifizierung, Ausführung, Code und Zugriff auf Secrets — kam mir eine Frage
  Muss CI/CD wirklich auf Secrets zugreifen können?
  Ich denke, es sollte reichen, nur die Berechtigung für API-Aufrufe zu haben
  Ein ideales System sollte Secrets nicht direkt behandeln, sondern sie indirekt über einen Adapter wie eine Secure Enclave verarbeiten

  • Die Aussage „Gutes CI sollte keine Secrets unterstützen“ schlägt letztlich nur eine komplexere Form des Secret-Managements vor
    In der Praxis brauchen die meisten Kunden weiterhin Secrets
  • Theoretisch stimmt das, aber in der Realität kommen die Leute nicht darum herum, Secrets in CI/CD zu hinterlegen
    Die Plattform sollte zumindest einen sicheren Mechanismus zur Secret-Verwaltung bereitstellen
    Gerade Open-Source-Projekte wollen direkt aus dem CI heraus deployen
  • Unser Unternehmen verwendet kommerzielle Tools wie den QNX-Compiler oder Coverity, und diese benötigen Secrets für den Zugriff auf Lizenzserver
    Ich würde gern genauer verstehen, worin sich so ein „Secure-Enclave-Ansatz“ konkret unterscheidet
  • Wenn CI/CD vollständig in die Infrastruktur integriert wäre, könnte Deployment auch ohne Secrets möglich sein,
    aber in der Realität ist das je nach Umgebung unterschiedlich und teuer in der Umsetzung, weshalb sich meist der Ansatz Container + Umgebungsvariablen durchgesetzt hat
  • Um die Kompatibilität mit mehreren Cloud-Datenbanken zu testen, braucht man Zugangsdaten für jede dieser Datenbanken
    Wenn man solche Tests automatisieren will, sind Secrets unvermeidlich

• Wenn man die Lock-Datei ins Repository committen muss, entsteht beim ersten Erstellen ein Bootstrapping-Problem
  Um das zu lösen, bräuchte man eine Möglichkeit, Actions lokal auszuführen
  Es gibt Werkzeuge wie nektos/act, aber diese dienen hauptsächlich dem Debugging
  Wahrscheinlich wäre ein separater Mechanismus auf Basis statischer Analyse nötig