Blog
Schützen Sie das Repository, das Ihre GitHub-Aktion hostet

Es ist keine Überraschung, dass die Lösung für Tags und Zweige zur Versionierung von GitHub Actions bestenfalls schwach ist. Es gab Gerüchte über die Umstellung von Actions auf ein anderes Modell (GitHub Container Registry), aber das ist noch nicht in Sicht.
Der GitHub Actions Wurm: Kompromittierung von GitHub Repositories über den Actions Dependency TreeDer GitHub Actions Wurm kompromittiert GitHub-Repositories über Aktionsabhängigkeiten in einem neuartigen Angriffsvektor, der es Angreifern ermöglicht, Malware über Repositories zu verteilen, wie Untersuchungen zeigen.
Um Ihr GitHub Actions Repository zu schützen, sollte der Autor einer Action ein paar Dinge tun.
1. 2FA einrichten
Der Autor einer GitHub-Aktion sollte immer 2FA für sein Konto aktivieren.
Sie könnten in Erwägung ziehen, alle Ihre Aktionen in einer GitHub-Organisation anstelle Ihres persönlichen Kontos abzulegen , was eine Reihe zusätzlicher Richtlinien (wie erzwungene 2FA) ermöglicht. Dies ermöglicht Ihnen auch, den ✅ verifizierten Ersteller auf Ihrem Marktplatzeintrag zu aktivieren.
2. Beschränken Sie die Standardfunktionen von Aktionen in Ihrem Repo
In den Einstellungen für Aktionen können Sie einschränken, was Aktionen standardmäßig tun können, so dass der Autor explizite Berechtigungen festlegen muss, wodurch die Standardberechtigungen Ihrer Arbeitsabläufe reduziert werden.
Beschränken Sie die Aktionen, die das Repository ausführen darf, auf die genaue Liste der von Ihrem Repository verwendeten Aktionen:

Sie können weiter einschränken, was ein GitHub Actions Workflow tun kann. Empfohlene Einstellungen:
- Erfordern Sie eine Genehmigung für alle externen Mitarbeiter
- Repository-Inhalte und Paketberechtigungen lesen
- GitHub-Aktionen nicht erlauben , Pull Requests zu erstellen und zu genehmigen

3. Tag-Schutz einrichten
Richten Sie geschützte Tags ein, um einzuschränken, wer Ihre Tags überschreiben kann. Dadurch wird verhindert, dass GitHub Actions Workflows bestehende Tags überschreiben. Die Erstellung neuer Unterversionen wird dadurch jedoch nicht verhindert. Hauptversionen müssen von einem Repository-Besitzer oder einem GitHub App-Token mit Repository-Admin-Berechtigungen aktualisiert werden.
Leider unterstützt das Tag-Namensformat keine regulären Ausdrücke. Um die Erstellung eines Tags namensverify-sanityoder eines anderen Tag-Namens, der mitvbeginnt, nicht zu blockieren, habe ich die Schutzmaßnahmen für alle Möglichkeiten, wie ein Versions-Tag in GitHub Actions benannt werden kann, hinzugefügt.
Erstellen Sie ein geschütztes Tag für v0 bis v9 sowie für v. und v..*.

4. Abzweigschutz einrichten
Mit der neuen Funktion Regelsatz können Sie die Zweige, die erstellt werden können, einschränken. GitHub Actions bevorzugt eine Verzweigung mit dem Namen
Leider unterstützt das Branch-Format keine regulären Ausdrücke. Um die Erstellung eines Zweigs mit dem Namenverify-sanityoder eines anderen Zweignamens, der mitvbeginnt, nicht zu blockieren, habe ich die Schutzmaßnahmen für alle Möglichkeiten, wie ein Versions-Tag in GitHub Actions benannt werden kann, hinzugefügt.
Erstellen Sie eine neue Regel namens "Versionierte Zweige nicht zulassen" und eine Regel für v0 auf v9:

Konfigurieren Sie die Richtlinie so:
- Erstellung einschränken
- Updates einschränken
- Blockkraft drückt

Stellen Sie außerdem sicher, dass Sie einen Zweigschutz für Ihren Hauptzweig einrichten. Ich persönlich habe die folgenden Regeln aufgestellt:


Wenn Sie mehr als einen Betreuer haben, verhindern Sie, dass jeder diese Regeln umgeht. Wenn Sie ein einsamer Betreuer wie ich sind, müssen Sie sich erlauben, diesen Schutz zu umgehen.

5. Einrichten der Sicherheitsfunktionen von GitHub
Aktivieren Sie Secret Scanning und Push-Schutz:

Aktivieren Sie Dependabot-Warnungen und Versions-Updates:

Fügen Sie dem Repository Ihrer Aktionen eine .github/dependabot.yml hinzu:
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/" # Location of package manifests
schedule:
interval: "weekly"
6. Verwenden Sie GitHub App Token oder feinkörnige Zugriffstoken
Da die fein abgestuften persönlichen Zugriffstoken nun sowohl die REST- als auch die GraphQL-API unterstützen, sollten Sie alle verbleibenden klassischen persönlichen Zugriffstoken löschen und durch ein fein abgestuftes Token ersetzen, das nur die vom Token benötigten Bereiche, Organisationen und Repositories enthält.
Beschränken Sie das Token auf Nur ausgewählte Repositories:

Wenn Sie alle Ihre Aktionen in einer Organisation und nicht in Ihrem persönlichen Konto durchführen und Single Sign-on aktiviert haben, dann benötigen Ihre Zugriffstoken eine zusätzliche SSO-Autorisierung. Dadurch wird eine weitere Sicherheitsebene hinzugefügt. Single Sign-on ist leider nur für GitHub Enterprise Cloud verfügbar, nicht für den Free und Teams Plan.
In Actions-Workflows verlassen sich auf GitHub Apps anstelle von persönlichen Zugangs-Tokens:
steps:
- id: create_token
uses: tibdex/github-app-token@0914d50df753bbc42180d982a6550f195390069f # v2
with:
app_id: ${{ secrets.APP_ID }}
private_key: ${{ secrets.PRIVATE_KEY }}
- run: "echo 'The created token is masked: ${{ steps.create_token.outputs.token }}'"
7. Bevorzugen Sie Forks für die Zusammenarbeit gegenüber dem Hinzufügen von Kollaborateuren zum Repo
Dieser letzte Punkt ist vielleicht etwas paranoid, aber GitHub schützt Ihr Repository besser, wenn andere Mitarbeiter ihre Änderungen von einem Fork statt von einem Branch im selben Repository einreichen.
Auf diese Weise können Mitarbeiter nicht:
- Tags erstellen
- Zweige erstellen
- Zugriff auf Repository-Geheimnisse
- Einen geänderten Workflow ohne Genehmigung ausführen (siehe Richtlinie oben)
8. Verwenden Sie sha über Tags in allen Arbeitsabläufen, die von Ihrer eigenen GitHub-Aktion verwendet werden.
Aktivieren Sie RenovateBot oder OSSF Scorecard oder Step Security, um die Versions-Tags in Ihren Workflows und zusammengesetzten Aktionen automatisch durch deren sha zu ersetzen.

Für RenovateBot fügen Sie das folgende Snippet zu Ihrem .github/renovate.json hinzu:
{
"extends": ["helpers:pinGitHubActionDigests"]
}
Und wenn diese Tools ein Upgrade auf eine neuere Version vorschlagen, stellen Sie sicher, dass Sie den Inhalt der neuen Version überprüfen.
Verfasst von
Jesse Houwing
Jesse is a passionate trainer and coach, helping teams improve their productivity and quality all while trying to keep work fun. He is a Professional Scrum Trainer (PST) through Scrum.org, Microsoft Certified Trainer and GitHub Accredited Trainer. Jesse regularly blogs and you'll find him on StackOverflow, he has received the Microsoft Community Contributor Award three years in a row and has been awarded the Microsoft Most Valuable Professional award since 2015. He loves espresso and dark chocolate, travels a lot and takes photos everywhere he goes.
Unsere Ideen
Weitere Blogs
Contact



