Analyse des GitHub-Marktplatzes - Sicherheit von Abhängigkeiten ist ein großes Thema

Ich bin seit der Beta-Phase Ende 2019 ein Fan von GitHub Actions. Und je mehr ich sie nutze und meine eigenen erstelle, desto mehr interessiert es mich, wie diese Aktionen erstellt werden, wie aktiv die Community ist und was wir tun können, um dieses Ökosystem zu verbessern. Also habe ich beschlossen, etwas zu recherchieren und zu sehen, was ich herausfinden kann. Ich habe bereits ein (jetzt inaktives) Twitter-Bot der die Marktplatz für GitHub-Aktionen und speichert diese Informationen zur späteren Verwendung (leider verfügt der Marktplatz über keine API, die Sie dafür verwenden können).

Foto von Ashes Sitoula auf Unsplash

Ich bin auch fasziniert von den Sicherheitsaspekten der Verwendung von GitHub Actions für meine Workloads. Meine erste Konferenzsitzung zu diesem Thema war auf der NDC London im Januar, 2021 und ich habe mich seither für diese Erkenntnisse eingesetzt. Deshalb habe ich mich auch entschlossen, meine üblichen Sicherheitsprüfungen für den gesamten Marktplatz durchzuführen, beginnend mit dem Forking, 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 böswillige Akteure viele Möglichkeiten haben, 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 im Stammverzeichnis (und ein paar weitere Optionen) innerhalb eines Arbeitsablaufs verwendet werden können, gibt es noch viele weitere Aktionen, die uns zur Verfügung stehen und nicht Teil dieser Untersuchung sind.

Hinweis: Ich habe die Analyse aktualisiert, um die DevDependencies außer Acht zu lassen, nachdem diese Informationen zur API hinzugefügt wurden. Das bedeutet, dass die Zahlen niedriger sind als die im ursprünglichen Beitrag: ein großer Teil der Alarme kam von DevDependencies.

Analyse der Aktionen aus dem GitHub Actions Marketplace

Ich habe eine neue Repo um diese Prüfungen mit GitHub Actions durchzuführen, indem ich einen Workflow plane, der stündlich abläuft und den Datensatz auf neue Aktionen prüft, die noch nicht zu meiner Validierungsorganisation geforkt wurden. Wenn Sie weitere Überprüfungen oder Informationen haben, die Sie gerne sehen möchten, dann sollten Sie Lassen Sie es mich wissen und ich werde sie in den Arbeitsablauf einfügen.

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 im Marketplace zu verbessern. Dennoch sind dies gut zwei Drittel der Aktionen, die auf dem Marktplatz verfügbar sind, also ein repräsentativer Datensatz, den man sich ansehen kann. Beispiele für Aktionen, die auf dem Marktplatz angezeigt werden, aber 404, wenn Sie die Detailinformationen dazu laden möchten:

• c-documentation-generator
• cross-commit+

Außerdem wird die gesamte Analyse in der Standardverzweigung des Repositorys durchgeführt. Ich 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.

Gesamtstatistiken - Aktionsart

Mein erstes Interesse galt der Analyse des Gesamtaufbaus der Aktionen. Sie können die Aktionen zum Beispiel auf mehrere Arten definieren: Durch das Ökosystem, das sie verwenden: Node-basiert (Typescript oder JavaScript), Docker-basiert oder es kann sich um ein zusammengesetzte Aktion.

Art der Aktion	Anzahl	Prozentsatz
Node basiert	4,7k	45%
Docker basiert	3.7k	35%
Komposit	1.6k	16%

Dies sagt uns, dass es eine eine Menge der Verwendung für Docker-basierte Aktionen! Das bedeutet, dass viele dieser Aktionen etwas Komplexeres tun, als Sie mit einer Node-basierten Aktion tun können. Sie haben sich für eine langsamere Aktion entschieden, da das Docker-Image erst erstellt oder heruntergeladen und dann hochgefahren werden muss. Vergleichen Sie das mit einer Node-basierten Aktion, die sofort gestartet wird. Aber Sie können die Sprache und das Ökosystem verwenden, die am besten zu Ihrer Aktion passen.

Aktionsdefinition einrichten

Als Nächstes analysierten wir die Einrichtung der Aktion selbst. Sie können sie auf verschiedene Arten im Stammverzeichnis Ihres Repositorys definieren:

• action.yml - Dies ist die Standardmethode zur Definition einer Aktion. Es handelt sich um eine YAML-Datei, die alle Informationen über die Aktion enthält.
• action.yaml - Dies ist eine alternative Möglichkeit, eine Aktion zu definieren, die zu Beginn von GitHub Actions verfügbar war und daher immer noch unterstützt wird.
• Dockerfile - Dies ist eine weitere Möglichkeit, eine Docker-basierte Aktion zu definieren. Wenn Sie keine action.yml oder action.yaml Datei haben, wird diese Datei übernommen. Diese Dockerdatei wird vom Runner verwendet und in der Ausführungsumgebung erstellt, wenn die Aktion verwendet wird. Eine andere Möglichkeit besteht darin, den Dockerfile-Link in der Datei action.yml (oder yaml) Datei. Ich habe keine spezifische Übersicht erstellt, die angibt, wie viele Docker-basierte Aktionen in der action.yml Datei und wie viele eine separate Dockerdatei haben.

Definition der Aktion	Anzahl	Prozentsatz
action.yml	9.2k	89%
action.yaml	700	7%
Dockerdatei	144	1%
Unbekannt	300	3%

Dies zeigt uns, dass fast 90% der Aktionen mit der Datei action.yml definiert wurden, was in der Tat der Weg ist, der in den meisten Dokumentationen und Demos gezeigt wird.

Docker-basierte Aktionen

Bei den Docker-basierten Aktionen war ich daran interessiert, zu sehen, wie viele Aktionen ein vorgefertigtes Image aus einer Container-Registry verwenden und wie viele nicht. Wenn sie eine lokale Dockerdatei verwenden, hat dies möglicherweise große Auswirkungen auf die Startzeit der Aktion. Noch schlimmer ist, dass es schwieriger ist, diese auf GitHub Enterprise Server zu unterstützen, da diese Umgebungen in der Regel aus berechtigten Sicherheitsgründen vom Internet abgeschottet sind. Wenn Sie eine dieser Aktionen unterstützen, müssen Sie auch die verwendeten Ökosysteme unterstützen, angefangen beim Basis-Container-Image (führen Sie Sicherheitsscans durch, Leute!) und dann alles, was es verwendet: apt-get, yum, yarn/npm, pip, usw. Das bedeutet einen erheblichen Mehraufwand für das Support-Team. Ich würde einem Maintainer eher empfehlen, ein Remote-Image zu verwenden, vorzugsweise die GitHub Container Registry, da diese direkt mit dem Repo verknüpft ist und dann ohne (erhebliche) Ratenbegrenzung heruntergeladen werden kann.

Docker-basierte Aktion	Anzahl	Prozentsatz
Entferntes Bild	550	15%
Lokale Dockerdatei	3.1k	85%

Daraus lernen wir, dass das Onboarding und die Validierung dieser Docker-basierten Aktionen wahrscheinlich viel Arbeit machen und erhebliche Auswirkungen auf die Einrichtung Ihres Runners haben wird: Bei jeder Verwendung wird das Basis-Image heruntergeladen und dann die Aktion darauf aufgebaut. Das bedeutet viel Overhead für den Runner und verlangsamt die Ausführung des Workflows. Außerdem kostet es den Runner unnötig viel Bandbreite und zusätzliche Rechenleistung, was sich auf die Umwelt auswirkt. All dies ist eher unnötig, wenn der Betreuer ein Remote-Image verwendet, das der Runner-Host lokal zwischenspeichern kann. Seien Sie sich dessen besonders bewusst, wenn Sie ephemere Runner hosten, die gelöscht werden, nachdem sie einen Workflow-Auftrag ausgeführt haben.

Einer der nächsten Schritte besteht darin, die ferngehosteten Bilder auf zu analysieren, wo diese gehostet werden.

Repo-Alter

Das nächste, was ich wissen wollte, war das Alter des Repositorys: Was können wir darüber sagen, wann das Repository das letzte Mal (überhaupt!) aktualisiert wurde? Wenn die Aktion überhaupt nicht gepflegt wird, ist die Wahrscheinlichkeit groß, dass etwas nicht stimmt (entweder in Bezug auf die Funktionalität, die Sicherheit oder das Hinzufügen neuer Funktionen).

Ich muss tiefer in die Materie eintauchen, um zu sehen, ob es irgendwelche Muster im Alter des Repo gibt:

• Senken die 267!!! archivierten Repos das Durchschnittsalter erheblich?
• Stimmen die am meisten gefährdeten Repos mit den ältesten Repos überein?
• Was ist mit der letzten Version, die gemacht wurde? Alle Demos zeigen, dass Sie die Version in der uses Das letzte Mal, dass die Aktion veröffentlicht wurde, könnte also auch von Bedeutung sein.

Sicherheitswarnungen für Abhängigkeiten der Aktionen

Ich habe auch 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 die Node-basierten Aktionen, das sind 4,7k, also fast 50% der analysierten Aktionen. Dependabot unterstützt Docker derzeit nicht.
• Ich lade nur die verwundbaren Alarme von Dependabot zurück, die einen Schweregrad von High oder Critical haben.

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

Sicherheitsergebnisse

Von den 10488 gescannten Aktionen haben 3130 einen hohen oder kritischen Alarm. Und das, obwohl nur die Node-basierten und Composite-Aktionen gescannt wurden, da die Docker-basierten Aktionen noch nicht gescannt wurden. Das ist viel mehr, als ich erwartet hatte, und sehr beängstigend! Wenn Ihre Abhängigkeiten bereits nicht auf dem neuesten Stand sind und somit Sicherheitslücken aufweisen, wie können wir dann erwarten, dass Ihre Aktion sicher ist? Das sind 30 % der Aktionen, die eine oder mehrere hohe oder kritische Warnungen für ihre 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 zum Beispiel 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, ich erwarte, dass dies keine Bedeutung hat, aber dennoch: gut zu erwähnen.

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 Repository um Archived handelt, sollte es sich nicht auf dem Marktplatz für Aktionen befinden und auch nicht verwendet werden. Glücklicherweise wird sie 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 verwendet (es könnten also auch mehr sein!). Eines dieser abhängigen Repos ist ein Repos mit 425 Sternen und ein anderes hat 6015 Sterne. Letzteres stellt ein serverloses CMS her, das als 48 verschiedene Pakete in das NPM-Ökosystem eingespeist werden soll. 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 oberster Ebene: Für haben alsoalle Action Repos, die ich scannen konnte, 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 lernen, wie Sie Ihre Sicherheitslage mit Aktionen verbessern können? Schauen Sie sich diesen Leitfaden an, den ich erstellt habe: GitHub-Aktionen Reifegrade.

Fazit

Es gibt eine Menge Verbesserungen für das Ökosystem der Aktionen vorzunehmen. Ich würde mir wünschen, dass GitHub dabei 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 zum Marktplatz, sondern auch zu Dependabot hinzu. Als Betreuer von Aktionen sind wir natürlich auch mit von der Partie! Es liegt in unserer Verantwortung, dafür zu sorgen, dass unsere Aktionen sicher sind und dass wir sie auf dem neuesten Stand halten. Ich hoffe, dieser Beitrag hilft Ihnen zu verstehen, warum Sie das tun sollten!

Anhang

Vielleicht kann ich eine Scanner-Aktion schreiben, die diese Informationen auswertet, und diese in die Verwendete Aktionen laden Aktion, die ich erstellt habe.

Ich muss diese Art von Informationen zum Beispiel in die Private Actions Marketplace Einrichtung aufnehmen.