Reifegrad der sicheren Nutzung von GitHub-Aktionen

Ich habe schon vor einiger Zeit darüber gesprochen, wie man GitHub Actions auf sichere Weise nutzen kann (siehe und ich habe eine Frage dazu erhalten, wie Sie die Nutzung von Aktionen verbessern können. Ich wollte diese Informationen in einer einfach zu befolgenden Reihe von Schritten zusammenfassen, also los geht's:

1. Standard-Demobeispiele: Versions-Pinning oder nach Zweig
2. Prüfen Sie den Quellcode und vertrauen Sie dem Herausgeber / der Aktion
3. SHA-Hashes
4. Dependabot für Aktionen
5. Forken Sie das Repo und übernehmen Sie die Kontrolle
6. github-fork-updater
7. Interner Marktplatz
8. Aktionen anfordern Prozess

Foto von Markus Spiske auf Unsplash

Im Folgenden gehe ich auf jede dieser Kategorien ein und gebe Ihnen weitere Informationen. Damit sollten Sie in der Lage sein, festzustellen, wo Sie oder Ihr Unternehmen in dieser Größenordnung stehen. Ich würde gerne wissen, was Ihr nächster Schritt sein wird, also lassen Sie es mich bitte wissen auf Twitter!

1) Standard-Demobeispiele: Versions-Pinning oder nach Zweig

Hier beginnen derzeit alle Demos: Verwenden Sie Versions-Pinning (jetzt erforderlich) oder nach Zweig:

    - uses: actions/checkout@v1
    - uses: actions/checkout@main

Die Engine und die Benutzeroberfläche zwingen Sie nun, eine dieser Möglichkeiten zu nutzen, oder Sie können den Workflow nicht starten oder speichern.

Die erste Zeile verweist auf eine Version, die verwendet wurde, um die Aktion als Release zu veröffentlichen. Sie finden alle veröffentlichten Versionen im Repository der Aktion selbst: Link. Häufig enthält die Version Versionshinweise und eine Liste der Commits, die es in die neue Version geschafft haben. Folgende Aktionen sollten durchgeführt werden semantische Versionierung was bedeutet, dass Sie mit v2 immer die neueste kompatible Version mit v2 zu verwenden. Wenn der Herausgeber also v2.14.17 veröffentlicht, verwendet der Runner diese Version.

Die zweite Zeile verweist auf einen bestimmten Zweig im Repository der Aktionen.

Bei beiden Optionen laden die Runner das gesamte Repository herunter, indem sie entweder git checkout aufrufen (wenn git auf dem Runner installiert ist) oder den Status des Repositorys als Tarball herunterladen. Die runner ist quelloffen, so dass Sie die Schritte mitverfolgen können, die er unternimmt.

Das Problem bei der Verwendung von beidem ist, dass Sie damit beliebigen Code aus dem Internet einspeisen! Selbst wenn Sie die Best Practices, sollten Sie sich ansehen, was die Aktion für Sie tut. Bei GitHub gibt es keinen dokumentierten Prozess für die Veröffentlichung einer Aktion oder eine Sicherheitsüberprüfung: Jeder kann ein öffentliches Repository mit dem richtigen Inhalt einrichten und dann kann es jeder nutzen. Das ist sehr hilfreich, um schnell loszulegen, aber die Sicherheit ist nicht Teil dieses Bildes!

Warum ist diese erste Stufe so schlecht?

Wie ich bereits sagte, verwenden die obigen Methoden immer eine Version der Aktion, wie sie ist. Bei der Verzweigungsmethode wird die Version verwendet, die zuletzt in die Verzweigung übertragen wurde. Selbst wenn Sie die Aktion gerade erst überprüft haben und mit der Verwendung beginnen, kann es also sein, dass eine neuere Version in diesen Zweig verschoben wurde. Dies geschieht ohne dass Sie davon wissen es überhaupt nicht! In der Zeit zwischen der Überprüfung und der Verwendung kann alles Mögliche passieren. Es könnte eine Sicherheitslücke in einem Paket gefunden werden, das die Aktion verwendet, oder der Betreuer beschließt, alle Umgebungsvariablen auf seinen eigenen Server zu exportieren. Oder vielleicht übergibt der Betreuer den Code sogar an einen Dritten, damit dieser die Wartung übernimmt. Man kann nie wissen, aber vielleicht wird eine Aktion in der Produktion verwendet, die nicht Ihren Vorstellungen entspricht.

Für das Anpinnen von Versionen gilt das gleiche Prinzip: Sie könnten sogar eine bestimmte Version anpinnen, z.B. v2.1.4, und denken, dass Sie jetzt sicher sind: Das sind Sie nicht! Die Version einer Veröffentlichung stammt aus einer Git-Tag. Git-Tags können wiederverwendet werden! Sie sind vom Design her flexibel, so dass der Betreuer Code markieren und als v2.1.4 veröffentlichen kann. Und dann, Monate später, beschließt er, neuen Code hinzuzufügen, vielleicht eine Schwachstelle einzubauen und das gleiche Tag wieder zu verwenden! Dann wird der Runner die Version des Repositorys herunterladen wie es mit diesem Tag ist verknüpft und Sie führen in Ihrem Arbeitsablauf Code aus, den Sie nie beabsichtigt haben.

2) Prüfen Sie den Quellcode und vertrauen Sie dem Herausgeber / der Aktion

Der erste Schritt zur sicheren Verwendung von Aktionen besteht darin, den Quellcode zu prüfen: Sie müssen wissen, was die Aktion für Sie tut! Das Repo ist Open Source, also gehen Sie zum Repo:

Wussten Sie, dass Sie sogar die Aktion selbst aufrufen können, um das Repo zu finden? Die uses-Anweisung kann teilweise hinter github.com kopiert werden, um den direkten Link zum Repo zu erhalten! Also dies uses: actions/checkout@v1 wird dies github.com/actions/checkout!

Suchen Sie nun die action.yml im Stammverzeichnis und finden Sie deren Einstiegspunkt unter runs , z.B. die Checkout-Aktion:

runs:
  using: node12
  main: dist/index.js
  post: dist/index.js

Die using zeigt an, dass diese Aktion unter Node läuft, also JavaScript-basiert ist. Es kann sich dabei um kompiliertes TypeScript handeln. Der nächste Schritt besteht also darin, den Einstiegspunkt zu suchen und herauszufinden, wie er erreicht wurde. Oft finden Sie eine src Ordner und die darin enthaltenen TypeScript-Dateien (*.ts). Normalerweise ist die Startdatei dann main.ts oder index.ts.

In diesem Fall sehen wir eine main Eigenschaft, die den Startpunkt angibt, an dem diese Aktion beginnt, also index.js im dist Ordner. Dies ist bereits eine gute Chance, dass diese Aktion mit TypeScript erstellt wurde. Sie können oft herausfinden, wo sie tatsächlich beginnt, indem Sie die packages.json Akte. Für diese Aktion finden wir "main": "lib/main.js" in there, so we can find where it actually starts . For TypeScript the file names just have the .ts` Erweiterung.

Wir haben hier auch eine post Definition, was bedeutet, dass ein Teil der Aktion auch am Ende eines Laufs ausgeführt wird:

Zusammenfassend lässt sich sagen, dass es keine Verifizierung oder Sicherheitskennzeichnung gibt, bevor jemand eine Aktion verwenden kann, also müssen Sie selbst Ihre Sorgfaltspflicht erfüllen! Prüfen Sie, was die Aktion macht und treffen Sie eine fundierte Entscheidung, ob Sie der Aktion vertrauen können.

3) SHA-Hashes

Jetzt, da Sie den Quellcode der Aktionen überprüft haben, müssen Sie sicherstellen, dass Sie immer diese spezielle Version der Aktion verwenden. An dieser Stelle kommen die SHA-Hashes ins Spiel. Jeder Git-Commit erhält seinen eigenen, eindeutigen SHA-Hash, der auf dem Inhalt des Commits basiert. Dieser SHA-Hash ist eindeutig! Es ist zwar möglich, denselben SHA-Hash mit unterschiedlichen Inhalten zu generieren, aber sehr schwer zu bewerkstelligen. Wenn Sie den Inhalt des Repos als vorgegebenes Setup haben (zum Beispiel mit einer 'action.yml'-Datei), ist es sehr unwahrscheinlich, dass Sie denselben SHA-Hash für unterschiedlichen Code erhalten (wir nennen das SHA-Kollisionen). Das bedeutet, dass wir den SHA-Hash verwenden können, um eine bestimmte Version der Aktion anzugeben, die wir verwenden werden. Der Runner erkennt den SHA-Hash und verwendet ihn, um das Repository der Aktionen zur Laufzeit zu überprüfen. Da das Hinzufügen oder Ändern des Codes im Repository einen neuen SHA-Hash bedeutet, werden Sie immer die Version verwenden, die Sie überprüft haben.

Sie finden die SHA-Hashes in der Historie des Repo, indem Sie die Commit-Historie aufrufen. Verwenden Sie nicht die kurze Version des Hashes. Diese war unsicher (Kollisionen wahrscheinlicher) und funktioniert nicht mehr.

Den vollständigen SHA-Hash finden Sie dann hier:

4) Dependabot für Aktionen

Dependabot unterstützt auch Aktionen als Ökosystem. Er kann nach einem Zeitplan laufen und alle Workflows in Ihrem Repository auf die von Ihnen verwendeten Aktionen überprüfen. Wenn Sie die Version 2.1.5 einer Aktion verwenden und der Herausgeber die Version 2.1.6 veröffentlicht hat, erstellt Dependabot einen Pull Request für Sie, der die Aktion auf die neueste Version aktualisiert (Haupt- und Nebenaktualisierungen konfigurierbar).

Dependabot unterstützt alle Verwendungsoptionen für die Aktionen, die eine Version angeben:

• eigentümer/aktion@pinned-version
• Besitzer/Aktion@SHA-hash

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: ".github/workflows/"
    schedule:
      # Check for updates to GitHub Actions every weekday
      interval: "weekly"

Der einzige Nachteil ist, dass Sie im Dependabot Pull Request nur die Änderung der Versionsnummer (oder des SHA-Hashes) im PR sehen. Wenn der Herausgeber Commits oder Release Notes hinzugefügt hat, finden Sie diese auf der Registerkarte 'Conversation' des PR. Es liegt an Ihnen, die tatsächlichen Codeänderungen zu überprüfen!

5) Forken Sie das Repo und übernehmen Sie die Kontrolle

Nun, da Sie zumindest eine sicherere Möglichkeit haben, Aktionen zu verwenden (indem Sie deren Code überprüfen und an die von Ihnen überprüfte Version anheften), sind Sie bereit für den nächsten Schritt: die volle Kontrolle über die Aktion und alle Aktualisierungen daran. Dies ist einer der beste Praktiken für die Verwendung von Aktionen und war immer die erste Anleitung für ihre Verwendung: Fork the repo!

Durch das Forking der Aktion haben Sie eine vollständige Kopie davon. Falls also etwas passiert (neuere Versionen oder der Betreuer löscht das Repo), werden Ihre Arbeitsabläufe weiterhin problemlos ihre Arbeit verrichten. Sie haben jetzt auch die Kontrolle über alle eingehenden Aktualisierungen. Mehr dazu auf der nächsten Ebene. Ich verwende immer eine Organisation namens org-name-actions damit ich einen einzigen Ort für alle Aktionen habe, die wir verwenden, und eine einfache Möglichkeit, die Verwendung ALLER öffentlichen Aktionen einzuschränken (siehe nächster Absatz). Insbesondere in einer Arbeitsumgebung möchten Sie nicht, dass Ihre GitHub-Benutzer einfach jede Aktion aus dem öffentlichen Internet, müssen Sie diese Dinge zuerst überprüfen!

Das Schöne daran ist, dass Sie jetzt durchsetzen können, dass die Benutzer in Ihrem Unternehmen nur die von Ihnen kontrollierten Aktionen verwenden. Gehen Sie zu Ihrer Organisation -> permissions -> actions permissions und wählen Sie 'Allow select actions':

Sie können nun die Aktionen eingeben, die Sie für die ausgewählten Repositories in Ihrer Organisation zulassen möchten (Sie können dies auch auf Repo-Ebene tun). Wenn jemand einen Workflow auslöst, der sich nicht an diese Einschränkungen hält, wird eine Fehlermeldung ausgegeben und wird nicht gestartet. Es werden auch keine Aktions-Repos auf einen Runner heruntergeladen.

Bei dieser Liste können Sie völlig verrückt werden:

Hinweis: 'Eigentümer' kann hier entweder eine Organisation oder ein Benutzerkonto sein.

6) github-fork-updater

Nun, da Sie einen Fork des Repo haben, müssen Sie diesen Fork pflegen. Das geht am besten, indem Sie alle Änderungen, die Sie vornehmen, an den Herausgeber der Aktion weitergeben (ja, für Open Source), indem Sie klar mitteilen, was Sie geändert haben und warum. Schicken Sie dann einen Pull Request ein.

Außerdem möchten Sie eingehende Änderungen des Herausgebers wieder in die Abspaltung einfließen lassen. Sie können warten, bis jemand die Meldung auf dem Repository entdeckt, die besagt, dass Sie x Commits hinter dem übergeordneten Repository zurückliegen, aber das skaliert natürlich nicht. Es gibt auch eine große Schaltfläche auf dem Banner, mit der Sie alle Aktualisierungen automatisch einspielen können.

VERWENDEN SIE DIESE SCHALTFLÄCHE NICHT! Verwenden Sie zuerst den Vergleich in der Dropdown-Liste!

Sie würden blindlings alle Änderungen aus dem übergeordneten Projektarchiv übernehmen! Ich denke, die Erklärung von Stufe 2 war klar: Überprüfen Sie, was die Aktion für Sie tut! Das bedeutet, dass Sie die eingehenden Änderungen überprüfen müssen!

Um diesen Prozess zu skalieren, habe ich die github-fork-updater Repository, das den Prozess für Sie zentralisiert. Es überprüft alle Forks nach einem bestimmten Zeitplan und erstellt eine Ausgabe für Sie, wenn es Aktualisierungen gibt. Sie können dann die eingehenden Änderungen überprüfen und entscheiden, ob Sie den Fork aktualisieren möchten. Mehr dazu erfahren Sie in diesem Blogpost.

7) Interner Marktplatz

Die nächste Reifegradstufe ist eine Einrichtung, mit der die Benutzer in Ihrer GitHub-Organisation die Aktionen finden können, die Sie in Ihrer actions-org zur Verfügung stellen. Sie können die Organisation natürlich mit den normalen Suchoptionen durchsuchen, aber das bedeutet, dass sie den gesamten Code in den Repos durchsuchen müssen, um etwas zu finden, was die Aktion tun soll. Sie wollen nur in der action.yml und in der Readme suchen. Ein besseres Sucherlebnis ist daher eine gute Möglichkeit, Ihre Benutzer an einen zentralen Ort zu schicken: die internen Marktplatz. All diese Daten an einem einzigen Ort zu haben, hat noch weitere Vorteile. Dazu später mehr.

Der interne Marktplatz fasst alle Ihre (internen/privaten oder öffentlichen) Aktionen an einem Ort zusammen, mit den Informationen aus der action.yml und der Readme, nach denen Benutzer suchen können. Auf diese Weise können Sie Ihre Benutzer hierher schicken, um die Aktionen zu finden, die in Ihrer Organisation bereits genehmigt wurden. Lesen Sie mehr über den internen Marktplatz unter devopsjournal.io/blog/2021/10/14/GitHub-Actions-Internal-Marketplace .

Hinweis: Dies ist noch in Arbeit. Eines der Dinge, die ich noch hinzufügen möchte, sind Links zu den internen Verwendungen der Aktionen für den Fall, dass eine Schwachstelle gefunden wird oder für Implementierungsbeispiele.

8) Aktionen anfordern Prozess

Die letzte Reifegradstufe besteht darin, einen guten Governance-Prozess einzurichten, um den internen Marktplatz um Aktionen zu erweitern. Weitere Informationen finden Sie in meinem Blogpost dazu hier. Wir haben eine Repo wo wir hingehen können und:

1. Benutzer erstellen ein Problem, um eine öffentliche Aktion in den internen Marktplatz aufzunehmen
2. Ein sicherheitsbewusster (und geschulter!) Ingenieur führt eine erste manuelle Überprüfung des Quellcodes der Aktionen durch.
3. Der Techniker kann einen automatischen Scan anfordern
4. Der Scan leitet die Aktion an eine Testorganisation weiter und aktiviert Dependabot für die Schwachstellenwarnungen
5. Führt einen CodeQL-Scan durch
6. Überprüft das Actions Repo auf seine eigene Dependabot- und CodeQL-Einrichtung
7. Führt einen Trivy-Scan für alle verwendeten Container durch
8. Legt die Ergebnisse der Scans wieder in die Anfrageausgabe zurück
9. Der Ingenieur kann in voller Kenntnis der Sachlage entscheiden, ob er das Risiko der Anwendung der Aktion eingehen möchte
10. Nach der Genehmigung wird die Aktion automatisch an die org-actions-Organisationen weitergeleitet, wo sie verwendet und vom internen Marktplatz übernommen werden kann.

Zusammenfassung

Die acht Reifegrade sind etwas, das hoffentlich jeder Benutzer von Actions durchläuft, wenn er über die Risiken bei der Verwendung von Actions nach dem Auspacken informiert wird. Weitere Einblicke in die Verwendung von Aktionen mit Blick auf die Sicherheit erhalten Sie in meinem GitHub Universe Sitzung zu genau diesem Thema.