GitHub Actions hat Sicherheitsprobleme

Dieser Artikel ist Teil unseres XPRT Magazins #13. Lesen Sie das gesamte Magazin hier.

Ich bin fasziniert von den Sicherheitsaspekten der Verwendung von GitHub Actions für meine eigenen Workloads, seit ich damit begonnen habe, sie zu nutzen. Meine erste Konferenzsitzung zu diesem Thema fand im Januar 2021 auf der NDC London statt[1], und seitdem habe ich mich für diese Erkenntnisse eingesetzt. Deshalb habe ich auch beschlossen, meine üblichen Sicherheitsprüfungen für den gesamten Marktplatz durchzuführen, beginnend mit dem Forking der Actions, damit ich Dependabot für die geforkten Repositories aktivieren kann.

Der Marketplace zeigt uns fast 15 Tausend Aktionen, die für uns zur Verfügung stehen! Das bedeutet, dass die Community sehr engagiert ist, um diese Aktionen für uns zu erstellen, aber auch, dass es für böswillige Akteure ein großes Potenzial gibt, Aktionen zu erstellen, die zur Kompromittierung unserer Systeme verwendet werden können. Bitte beachten Sie, dass ich in diesem Beitrag nur Aktionen berücksichtige, die auf dem Marktplatz veröffentlicht wurden. Da jedes öffentliche Repo mit einer action.yml-Datei im Stammverzeichnis innerhalb eines Workflows verwendet werden kann, gibt es noch viele weitere Aktionen, die uns zur Verfügung stehen und nicht Teil dieser Untersuchung sind.

Analyse der Aktionen aus dem GitHub Actions Marketplace

Ich habe ein neues Repo[2] erstellt, um diese Prüfungen mit Hilfe von GitHub Actions durchzuführen, indem ich einen Workflow geplant habe, der jede Stunde abläuft und den Datensatz auf neue Actions prüft, die noch nicht an meine Validierungsorganisation geforkt wurden.

Einige Vorbehalte vorweg:

• Ich konnte nur die Informationen für 10,5 Tausend Aktionen laden. Bei allen anderen gibt es Probleme, so dass ich sie nirgendwo finden kann. Diese sind nicht im Datensatz für diese Analyse enthalten.
• Einige wurden von ihrem Betreuer archiviert, tauchen aber immer noch im Marketplace auf. Diese sind natürlich älter und weisen mehr Sicherheitsprobleme auf. Die Aktionen sind in dieser Analyse enthalten. Ich habe vor, diese zu entfernen, sobald sie nicht mehr im Marketplace angezeigt werden.
• Es gibt einige Aktionen, bei denen ich die Definitionsdatei (falls verwendet) nicht analysieren konnte, oft aufgrund von doppelten Schlüsseln in ihrer Definitionsdatei. Ich habe mich mit einigen der Betreuer in Verbindung gesetzt, um diese Probleme zu beheben, aber ich möchte auch meine Methode zum Laden dieser Art von Dateien verbessern. Derzeit unterstützt die Bibliothek, die ich dafür verwende, keine doppelten Schlüssel und gibt nicht behebbare Fehler aus, wenn sie diese findet.

Ich habe diese Informationen an GitHub zurückgemeldet und sie planen, die Aktualität der Daten auf dem Marktplatz zu verbessern. Dennoch sind dies gut zwei Drittel der Aktionen, die auf dem Marktplatz verfügbar sind, so dass es sich um einen repräsentativen Datensatz handelt. Beispiele für Aktionen, die auf dem Marktplatz erscheinen, aber eine Fehlermeldung ausgeben, wenn Sie die Detailinformationen dazu laden möchten, sind

• c-documentation-generator[3]
• cross-commit+[4]

Außerdem werden alle diese Analysen in der Standardverzweigung des Repositorys durchgeführt. Ich selbst habe zum Beispiel eine Aktion, die eine Dockerdatei im Hauptzweig verwendet, aber ich arbeite daran, sie in einem anderen Zweig in Node zu konvertieren. Diese Zahl sollte so gering sein, dass sie keinen wesentlichen Einfluss auf die Gesamtanalyse hat.

Sicherheitswarnungen für Abhängigkeiten der Aktionen

Ich habe die Action Repos in meiner eigenen Organisation geforkt und Dependabot für sie aktiviert, um einen Eindruck von den verwundbaren Abhängigkeiten zu bekommen, die sie verwenden. Bei dieser Analyse gibt es einige Vorbehalte:

• Nicht jede Abhängigkeit landet in der Aktion selbst, so dass ein hoher Alarm von Dependabot auf eine "möglicherweise" verwundbare Aktion hinweist. Da Sie nicht automatisch feststellen können, ob dies der Fall ist, können wir nicht sicher sein, dass die Aktion selbst angreifbar ist.
• Dies funktioniert nur für Node-basierte Aktionen, das sind 4,7k, also fast 50% der analysierten Aktionen. Dependabot unterstützt Docker derzeit nicht.
• Ich lade nur die gefährdeten Alarme von Dependabot zurück, die einen Schweregrad von Hoch oder Kritisch haben.

Ich plane, so etwas wie einen Trivy-Container-Sicherheitsscan in das Setup einzubauen, damit wir auch daraus einige Erkenntnisse gewinnen.

Ergebnisse der Sicherheitsüberprüfung

Von den 10488 gescannten Aktionen haben 3130 davon mindestens 1 hohe oder kritische Warnung! Das ist viel mehr, als ich erwartet hatte, und sehr beängstigend! Und dies gilt nur für Composite- oder Node-basierte Aktionen! Wie können wir erwarten, dass Ihre Aktion sicher ist, wenn Ihre Abhängigkeiten bereits nicht auf dem neuesten Stand sind und somit Sicherheitslücken aufweisen? Das sind 30% der Aktionen, die eine oder mehrere hohe oder kritische Warnungen zu ihren Abhängigkeiten haben.

Der Vollständigkeit halber: Ich habe die Warnungen nicht auf ein bestimmtes Ökosystem heruntergefiltert. Da GitHub Actions eines der Ökosysteme ist, für die Dependabot Warnungen ausgibt, besteht die Möglichkeit, dass diese Warnungen beispielsweise von einer Abhängigkeit von einer verwundbaren Aktion stammen, was unfair wäre (da diese nicht in der Aktion landen, die ich überprüfe). Da es nur 3 Aktionen in der GitHub Advisories Database[5] gibt, gehe ich davon aus, dass dies keine Bedeutung hat, aber dennoch: es ist erwähnenswert.

Eintauchen in die Sicherheitsergebnisse

Ich habe auch die Repos mit mehr als 10 (hoch + kritisch) Alarmen in einer separaten Berichtsdatei protokolliert und diese Datei enthält mehr als 600 Aktionen!

Die höchste Anzahl von Warnmeldungen in einer einzigen Aktion ist 58. Da es sich bei diesem Projekt um ein archiviertes Projekt handelt, sollte es nicht auf dem Marktplatz für Aktionen zu finden sein, und es sollte auch nicht verwendet werden. Glücklicherweise wird es nur von einer kleinen Anzahl von Workflows verwendet. Ich würde mir wünschen, dass der Runner zumindest Warnungen in die Protokolle einfügt, wenn er Aktionen aufruft, die archiviert sind.

Die höchste Anzahl von kritischen Alarmen in einer einzigen Aktion ist 16. Dieses Repository wird auch nur von weniger als 10 anderen Repositorys verwendet, so dass es keine großen Auswirkungen hat. Da es keine API für die Ermittlung der Abhängigkeiten gibt, die Dependabot findet, kann ich nicht ohne weiteres herausfinden, wie viele Workflows davon betroffen sind.

Ich habe einige der Repos mit vielen Alarmen überprüft und ein Beispiel gefunden, das 14 Alarme mit hohem Schweregrad und 2 kritische Alarme aufweist. Diese Aktion wird von 34 verschiedenen öffentlichen Repos genutzt (in privaten Repos könnte die Nutzung sogar noch höher sein!). Eines dieser abhängigen Repos ist ein Repos mit 425 Sternen und ein anderes hat 6015 Sterne. Letztere produziert ein serverloses CMS, das als 48 verschiedene Pakete in das NPM-Ökosystem geliefert wird. Eines dieser Pakete wird mehr als 1000 Mal pro Woche heruntergeladen! Das ist eine Menge Einfluss für eine einzige Aktion, die durch die Aktivierung von Dependabot verhindert werden könnte. Natürlich ist in diesem Fall eine genauere Analyse erforderlich, um festzustellen, ob die Warnmeldungen tatsächlich für die Aktion relevant sind. Das hängt davon ab, was die Aktion tut und wie sie die Abhängigkeiten nutzt.

Übersicht

Kurz gesagt, dies ist ein Überblick über die Sicherheitsergebnisse auf höchster Ebene:

Von allen Aktions-Repos, die ich scannen konnte, haben 30% mindestens 1 Schwachstellenalarm mit einem Schweregrad von hoch oder kritisch.

Knotenbasierte Aktionen

Wenn Sie dies auf die Node-Aktionstypen herunterfiltern, wird es noch viel erschreckender:

Das sind 58% der Node-Aktionen, die mindestens 1 Schwachstellenalarm mit einem Schweregrad von hoch oder kritisch haben! Und alle Demos und Dokumentationen weisen immer noch darauf hin, dass Sie die Aktionen so verwenden können, wie sie sind, und deuten nur an, welche Auswirkungen das auf die Sicherheit hat!

Möchten Sie erfahren, wie Sie Ihre Sicherheit bei der Verwendung von Aktionen verbessern können? Schauen Sie sich diesen Leitfaden an, den ich erstellt habe: GitHub Actions Maturity Levels[6].

Fazit

Das Ökosystem der Aktionen kann noch sehr viel verbessert werden. Ich würde mir wünschen, dass GitHub hier eine aktivere Rolle übernimmt, zum Beispiel durch:

• Setzen Sie bestimmte Best Practices durch, bevor Sie eine Aktion auf dem Marktplatz veröffentlichen können
• Bereinigung des Marktplatzes, wenn das Repo einer Aktion archiviert wird (daran wird gearbeitet)
• Fügen Sie dem Marktplatz eine Sicherheitsbewertung hinzu, so dass Benutzer sehen können, wie sicher eine Aktion ist. Führen Sie zumindest diese Art von Scans auf dem Aktions-Repo durch und melden Sie dies dem Endbenutzer.
• Fügen Sie eine Prüfung hinzu, die bestätigt, dass Sie auch eine neue Version der Aktion veröffentlicht haben, um zu verhindern, dass Maintainer Dependabot hinzufügen und ihre (anfälligen) Abhängigkeiten auf dem neuesten Stand halten, aber nicht wirklich eine neue Version der Aktion veröffentlichen.
• Fügen Sie APIs nicht nur für den Marktplatz, sondern auch für Dependabot hinzu. Diese Informationen sollten öffentlich zugänglich sein, aber derzeit musste ich sie von den Webseiten abkratzen.

Brauchen Sie Hilfe bei der Sicherung Ihrer GitHub-Aktionen oder möchten Sie mehr darüber erfahren? Wir freuen uns auf ein unverbindliches Gespräch mit Ihnen und zeigen Ihnen, wie wir Ihnen helfen können.

Fußnoten:

1. GitHub-Aktionen NDC London - DevOps Journal
2. GitHub-Aktionen Marktplatz-Prüfungen - Rajbos
3. Dokumentation Generator Actions - GitHub-Marktplatz
4. Übergreifende Commit-Aktionen - GitHub Marketplace
5. Überprüfte Ökosystem-Aktionen - GitHub Advisories
6. GitHub-Aktionen Reifegrade - DevOps Journal