Praktische Sicherheitsverbesserungen für GitHub Actions

Home » Python » Praktische Sicherheitsverbesserungen für GitHub Actions

GitHub Actions hat sich zum De-facto-CI/CD-System für auf GitHub gehostete Repositories entwickelt.Workflows treiben alles an, von Unit-Tests über Produktionsbereitstellungen bis hin zu Infrastrukturänderungen. Dieser Komfort hat jedoch einen schwerwiegenden Nachteil: Workflows laufen oft mit weitreichenden Berechtigungen, verarbeiten mächtige Token und Geheimnisse und können direkt auf Produktionssysteme zugreifen. Werden sie nicht gezielt abgesichert, öffnet man Fehlkonfigurationen, Abhängigkeitsfehlern und kompromittierten Konten quasi eine direkte Spur in den eigenen Pipelines und Cloud-Konten.

Dieser Leitfaden führt Sie durch eine umfassende, meinungsstarke Checkliste zur durchgängigen Absicherung von GitHub Actions.Wie man Geheimnisse korrekt handhabt, Script-Injection verhindert, Tokens und Trigger absichert, Aktionen von Drittanbietern bewertet, Runner verwaltet und integrierte Sicherheitsfunktionen wie Code-Scanning, OIDC, Dependabot und Audit-Logs nutzt. Ziel ist es, die verstreuten Best Practices, die aus jüngsten Vorfällen gewonnenen Erkenntnisse und die Sicherheitsrichtlinien von GitHub in einem praktischen Nachschlagewerk zusammenzuführen, das Sie in realen Projekten anwenden können.

Das tatsächliche Risikoprofil von GitHub Actions

Auf einer höheren Ebene ist ein GitHub Actions-Workflow lediglich eine YAML-Datei unter .github/workflows Ein Workflow definiert einen oder mehrere Jobs, die jeweils aus Schritten bestehen. Schritte können entweder Shell-Befehle ausführen oder wiederverwendbare Aktionen aufrufen, die von GitHub oder der Community veröffentlicht wurden. Workflows werden durch Ereignisse wie Push-Vorgänge, Pull-Anfragen, Aktivitäten in Issues, Zeitpläne oder manuelle Zuweisungen ausgelöst.

Aus Sicherheitssicht befinden sich diese Arbeitsabläufe direkt über Ihrer Software-Lieferkette.Sie erstellen und signieren Release-Artefakte, pushen Docker-Images, stellen in Cloud-Umgebungen bereit, provisionieren Infrastruktur, führen Migrationen durch und vieles mehr. Wenn ein Angreifer den Code, die Konfiguration oder die Umgebung kontrollieren kann, in der ein privilegierter Workflow ausgeführt wird, kann er oft:

• Hintertür-kompilierte Artefakte (Binärdateien, Container, Pakete), die Sie später an Kunden versenden.
• Wertvolle, langlebige Token und Geheimnisse exfiltrieren aus dem Speicher, Protokollen, Caches oder Artefakten.
• Missbrauch privilegierter Cloud-Rollen CI wurde die Erlaubnis erteilt, zusätzliche Dienste bereitzustellen, Netzwerkänderungen vorzunehmen oder auf Daten zuzugreifen.
• Gift flussabwärts Projekte durch Kompromittierung von Open-Source-Release-Pipelines und Verbreitung von mit Trojanern infizierten Releases.

Aktuelle Vorfälle in der Praxis haben verdeutlicht, wie attraktiv GitHub Actions als Angriffsfläche ist.Angreifer haben anfällige Arbeitsabläufe ausgenutzt, um Kryptominer in veröffentlichte Pakete einzuschleusen, und die beliebte tj-actions/changed-files Die Geschäftsprozesse wurden durch einen mehrstufigen Angriff auf Coinbase beeinträchtigt. Der Schadcode extrahierte geheime Informationen aus Arbeitsabläufen und schrieb sie in Build-Protokolle, wodurch potenziell eine Kettenreaktion weiterer Angriffe auf die Lieferkette ausgelöst werden konnte.

Der wichtigste Aspekt, den man sich merken sollte, ist, dass es bei den meisten GitHub Actions-Angriffen um „Wahrscheinlichkeit × Auswirkung“ geht.Sie möchten die Wahrscheinlichkeit verringern, dass Sie schädliche oder fehlerhafte Komponenten (Drittanbieteraktionen, unsichere Runner, riskante Trigger) einsetzen, und gleichzeitig den Wirkungsradius drastisch begrenzen, falls eine einzelne Komponente kompromittiert wird.

Geheimnisse in GitHub Actions absichern

Geheimnisse sind in jedem CI/CD-System in der Regel das attraktivste Ziel.In GitHub Actions werden sie als Repository-, Organisations- oder Umgebungsgeheimnisse angezeigt, und zwar als Ad-hoc-Werte, die Sie versehentlich in Konfigurationen, Protokolle, Caches oder Artefakte einfügen könnten.

Als Erstes muss man sich das Zugriffsmodell verinnerlichen: Jeder, der Schreibzugriff auf ein Repository hat, kann effektiv alle Geheimnisse auf Repository-Ebene lesen.Sie können einfach einen bestehenden Workflow auf einem ungeschützten Branch modifizieren, Logging- oder Exfiltrationscode einfügen und diesen Workflow ausführen, um Geheimnisse auszugeben oder zu leaken. Die Maskierung von GitHub-Logs ist ein bestmöglicher Schutz, keine absolute Garantie.

Um Geheimnisse unter diesem Modell überlebbar zu machen, befolgen Sie diese Grundregeln.:

• Wenden Sie das Prinzip der geringsten Rechte anJegliche Anmeldeinformationen, die in einem Workflow verwendet werden, dürfen nur über die unbedingt erforderlichen Mindestberechtigungen verfügen. Vermeiden Sie die Weitergabe allgemeiner Administrator-Token als Workflow-Geheimnisse.
• Für sensible Werte sollten Umgebungsgeheimnisse gegenüber Repository- oder Organisationsgeheimnissen bevorzugt werden.Umgebungsgeheimnisse sind nur für Jobs verfügbar, die diese Umgebung deklarieren, und Sie können sie mit zusätzlichen Schutzmechanismen wie erforderlichen Prüfern und Zweigbeschränkungen versehen.
• Speichern Sie Geheimnisse niemals im Klartext in Workflow-YAML-Dateien. oder im in das Repository eingecheckten Code. Alle sensiblen Daten sollten über den GitHub-Secrets-Mechanismus oder einen externen Geheimnismanager verwaltet werden.
• Vermeiden Sie die Verwendung strukturierter Datenblöcke (JSON, YAML, XML) als einzelnen geheimen Wert.Die Maskierung basiert größtenteils auf exaktem Zeichenkettenvergleich; Datenblöcke mit mehreren Feldern lassen sich deutlich schwieriger zuverlässig schwärzen. Stattdessen sollten sensible Daten in mehrere separate, geheime Einträge aufgeteilt werden.
• Registrieren Sie alle abgeleiteten Geheimnisse explizitWenn Sie ein Geheimnis transformieren (Base64, URL-Codierung, JWT-Signierung usw.) und das Ergebnis möglicherweise jemals in Protokollen auftauchen könnte, registrieren Sie den transformierten Wert als eigenes Geheimnis, damit GitHub versuchen kann, ihn zu maskieren.

Rotation und Hygiene sind genauso wichtig wie die anfängliche Konfiguration.Überprüfen Sie regelmäßig, welche Geheimnisse vorhanden sind, wer oder was diese noch benötigt, und entfernen oder rotieren Sie veraltete Geheimnisse. Nach jedem Verdacht auf Offenlegung (z. B. wenn ein Geheimnis ungeschwärzt in Protokollen gespeichert oder bei einer kompromittierten Aktion verwendet wurde) löschen Sie umgehend die betroffenen Protokolle, widerrufen Sie die Zugangsdaten und erstellen Sie neue.

Vermeidung von Skript-Injection und unsicherer Interpolation

Eine der häufigsten, aber dennoch subtilsten Arten von GitHub Actions-Fehlern ist die Skripteinschleusung über Ausdrücke.GitHub bietet umfangreiche „Kontexte“ wie zum Beispiel github, env, secrets und Ereignisnutzlasten, auf die Sie in Workflows mithilfe der ${{ ... }} Syntax. Diese Ausdrücke werden von GitHub ausgewertet. bevor Ihr Shell-Schritt wird ausgeführt.

Wenn Sie einen nicht vertrauenswürdigen Kontext direkt in einen Shell-Befehl einbetten, laden Sie zu Befehlsinjektion ein.Wenn Sie beispielsweise Folgendes tun:

run: echo "new issue ${{ github.event.issue.title }} created"

und ein Angreifer kann den Titel des Problems kontrollierenSie können einen Titel einreichen wie zum Beispiel $(id)Nach der Auswertung des Ausdrucks ergibt sich folgender Schritt:

echo "new issue $(id) created"

was ausführt id auf dem LäuferAuch das Anpassen von Anführungszeichen oder das Hinzufügen einfacher Validierungen in der Shell wird Sie nicht zuverlässig vor diesem Muster bewahren.

GitHub empfiehlt als sicheres Vorgehen die Verwendung einer temporären Umgebungsvariablen.:

env:
TITLE: ${{ github.event.issue.title }}
run: |
echo "new issue \"$TITLE\" created"

Hier bleibt der potenziell schädliche Wert als Umgebungsvariable im Speicher erhalten.und die Hülle sieht nur $TITLEEs handelt sich also nicht um eine dynamisch erstellte Befehlszeile. Die üblichen Shell-Regeln (Variablen in Anführungszeichen setzen, unnötige `eval`-Befehle vermeiden usw.) sind weiterhin erforderlich, aber der gefährliche Interpolationsschritt entfällt.

Wenn Sie in Versuchung geraten, einzubetten ${{ github.* }} oder andere vom Benutzer kontrollierte Daten direkt in run: Blockaden, anhalten und durchschieben env: beantragen müssenDiese eine Gewohnheit beseitigt eine ganze Klasse von Script-Injection-Problemen in Ihren Arbeitsabläufen.

Berechtigungen und Token sicher konfigurieren

Das GITHUB_TOKEN Die von GitHub in jeden Workflow-Lauf eingebundenen Einstellungen sind unglaublich leistungsstark, wenn sie auf den Standardeinstellungen belassen werden.Es kann Inhalte lesen und schreiben, Pull Requests öffnen und aktualisieren sowie auf vielfältige Weise mit dem Repository interagieren. In der Vergangenheit war es in vielen Organisationen standardmäßig auf Lese- und Schreibzugriff eingestellt, ohne dass dies bewusst war.

Der erste Härtungsschritt sollte darin bestehen, die Standardberechtigungen für Workflow-Token auf „Nur lesen“ zu setzen. auf Organisations- und/oder Repository-Ebene. Hierfür gibt es eine spezielle Einstellung in der Aktionskonfiguration. Dort können Sie zusätzliche Berechtigungen selektiv pro Workflow oder pro Job erteilen, zum Beispiel:

permissions:
contents: read
pull-requests: write

Dieses Modell, bei dem standardmäßig verweigert und nur bei Bedarf zugelassen wird, reduziert die Möglichkeiten eines Angreifers, einen kompromittierten Workflow auszunutzen, erheblich.Es zwingt Autoren außerdem dazu, darüber nachzudenken, welche Fähigkeiten ihre Arbeit tatsächlich erfordert, anstatt einen Allzweckbegriff zu übernehmen.

Wenn Ihre Organisation vor Anfang 2023 gegründet wurde, sollten Sie diese Standardeinstellungen explizit überprüfen.Viele ältere Organisationen verfügen immer noch über Workflow-Token mit Schreibberechtigung, da sie vor der Einführung der sichereren Standardeinstellung entstanden sind und sich nie für die Umstellung entschieden haben.

Neben Token-Bereichen ist besondere Vorsicht bei Einstellungen geboten, die es GitHub Actions ermöglichen, Pull-Anfragen zu genehmigen oder zu erstellen.Wenn Workflows Pull Requests automatisch freigeben, besteht die Gefahr des Missbrauchs, bei dem kompromittierte Prozesse bösartigen Code ohne menschliche Prüfung zusammenführen. Sofern Sie keinen zwingenden Anwendungsfall und strenge Sicherheitsvorkehrungen haben, sollten Sie diese Funktion deaktiviert lassen.

Auswahl und Fixierung von Aktionen Dritter

Jede externe Aktion, die Sie ausführen, ist ein Stück Remote-Code, der mit denselben Berechtigungen wie der Rest Ihres Jobs ausgeführt wird.Wenn diese Aktion bösartig wird, kompromittiert wird oder mit anfälligen Abhängigkeiten abgebrochen wird, wird sie zu einem vorgeschobenen Einfallstor in Ihre Pipeline.

Beim Konsum von Drittanbieteraktionen können Sie mehrere Schutzebenen anwenden.:

• Beginnen Sie mit einer kleinen, vertrauenswürdigen Zulassungsliste.. Von GitHub verwaltete Aktionen (wie actions/checkout, actions/setup-nodeAktionen von verifizierten Erstellern auf dem Marktplatz stellen in der Regel eine sicherere Grundlage dar als zufällige Repositories. Viele Organisationen setzen dies auf Organisationsebene durch, indem sie „Bestimmte Aktionen und wiederverwendbare Workflows zulassen“ aktivieren.
• Bevorzugen Sie populäre, aktiv aufrechterhaltene Maßnahmen.Untersuchungen zeigen, dass viele Marketplace-Aktionen niedrige OpenSSF-Scorecard-Werte, nur einen Betreuer und kurzlebige oder sehr junge Inhaberkonten aufweisen. Weit verbreitete Aktionen werden tendenziell genauer geprüft und schneller behoben.
• Achten Sie auf eine große Anzahl offener Dependabot-Pull-Requests im Repository der Aktion.Das ist oft ein Zeichen dafür, dass der Systembetreuer keine Sicherheitsupdates einspielt und somit transitive Schwachstellen ungepatcht bleiben.
• Bevorzugt werden Aktionen mit mehr als einem Maintainer und einer nicht archivierten, aktiven Codebasis.Hunderte von Aktionen im Marktplatz werden archiviert, was bedeutet, dass keine neuen Fehlerbehebungen oder Kompatibilitätsaktualisierungen mehr erfolgen und das Risiko mit der Zeit zunimmt.

Versionsfixierung ist ein weiteres wichtiges Thema.Wenn Sie eine Aktion nur anhand eines Tags angeben, wie zum Beispiel some-org/some-action@v2Sie vertrauen darauf, dass dieses Tag niemals zu Schadcode missbraucht wird. Tags können jedoch umgeleitet werden, wenn das Konto des Verantwortlichen oder das Repository kompromittiert wird.

Der defensivste Ansatz besteht heutzutage darin, einen vollständigen Commit-SHA festzulegen.:

uses: some-org/some-action@247835779184621ab13782ac328988703583285a

Durch das Festlegen eines SHA-Werts wird der Code aus Ihrer Sicht praktisch unveränderlich. (Ausgenommen ist ein SHA-1-Kollisionsangriff auf Git-Objekte). Der Nachteil liegt im Betrieb: Sie müssen die SHA aktualisieren, wenn Sie neue Funktionen oder Fehlerbehebungen nutzen möchten, und unterschiedliche Arbeitsabläufe können zu unterschiedlichen SHAs führen, wenn Sie nicht vorsichtig sind.

Um diesen Aufwand zu reduzieren, zentralisieren einige Teams die Nutzung von Drittanbieteraktionen in gemeinsamen oder zusammengesetzten Workflows.Einzelne Repositories verweisen über Tags auf diese gemeinsamen Workflows, während die gemeinsamen Workflows die zugrunde liegenden Aktionen an geprüfte SHAs binden und in einem kontrollierten Rhythmus aktualisiert werden, manchmal mit Tools, die Pull Requests für neue SHAs öffnen.

Egal für welche Strategie Sie sich entscheiden, denken Sie daran, dass das Anheften von Elementen kein Allheilmittel ist.Eine Aktion kann weiterhin dynamisch Code zur Laufzeit abrufen (zum Beispiel über curl | bash Muster) und Ihre PIN umgehen. Sie müssen den Quellcode weiterhin auf offensichtlich unsichere Muster überprüfen, bevor Sie einer Aktion Geheimnisse oder beschreibbare Token anvertrauen.

Gestaltung sichererer Arbeitsabläufe und Arbeitsplätze

Die Art und Weise, wie Sie Arbeitsabläufe und Aufgaben strukturieren, beeinflusst maßgeblich das Ausmaß eines möglichen Kompromisses.Ein häufiges Anti-Pattern ist ein einzelner riesiger Job, der Code auscheckt, kompiliert, testet, verpackt und bereitstellt, und der gleichzeitig über weitreichende Berechtigungen und Zugriff auf Produktionsgeheimnisse verfügt.

Die Aufteilung von Arbeit in separate Aufgaben und sogar separate Arbeitsabläufe sorgt sowohl für Trennung als auch für Klarheit.Zum Beispiel könnte Folgendes gelten:

• A Build- und Testjob Das System läuft mit minimalen Berechtigungen und ohne Bereitstellungsgeheimnisse.
• A Paketjob Das erzeugt signierte Artefakte, kommuniziert aber immer noch nicht mit der Produktion.
• A Job bereitstellen die von den anderen abhängig ist und als einzige berechtigt ist, auf Umgebungsgeheimnisse zuzugreifen und Cloud-Rollen zu übernehmen.

Auf den von GitHub gehosteten Runnern wird jeder Job in einem Workflow in einer neuen virtuellen Maschine ausgeführt.Dadurch wird eine gewisse Isolation zwischen den einzelnen Prozessen erreicht. Dies ist zwar nicht mit einer vollständig abgesicherten Sandbox vergleichbar, und es sind bekannte Angriffsvektoren zwischen den Prozessen bekannt (wie z. B. gemeinsam genutzte Branch-Caches), aber die Aufteilung der Prozesse zwingt Angreifer dennoch zu mehr Aufwand und reduziert das versehentliche Durchsickern von Geheimnissen in nicht zusammenhängende Schritte.

Nutzen Sie Umgebungen, um sensible Schritte mit Schutzmaßnahmen zu verknüpfen.Ein Bereitstellungsauftrag könnte Folgendes deklarieren:

environment: production

und der production Die Umgebung kann dann so konfiguriert werden, dass sie nur Deployments von einem geschützten Branch akzeptiert.Möglicherweise mit obligatorischen manuellen Genehmigungen. In Kombination mit strengen Schutzregeln für Geschäftsbereiche (erforderliche Prüfungen, keine beschleunigten Implementierungen, Ablehnung veralteter Genehmigungen) kommt man dem Vier-Augen-Prinzip für Produktionsänderungen sehr nahe.

Abschließend sei darauf hingewiesen, dass man mit Artefakten, Caches und Protokollen vorsichtig umgehen sollte.Sie bieten zwar eine bequeme Möglichkeit, Daten zwischen Jobs und Workflows auszutauschen, aber:

• Geheimnisse sollten nicht in Caches gebündelt werden.insbesondere nicht so bekannte Orte wie ~/.docker/config.json die möglicherweise einfache Docker-Anmeldeinformationen enthalten.
• Vermeiden Sie es, Geheimnisse zu protokollieren oder ganze Kontexte in Protokolle auszugeben.Da dies die Maskierung untergraben oder abgeleitete Werte offenbaren könnte, die GitHub nicht zu schwärzen weiß.
• Denken Sie daran, dass jeder mit Lesezugriff auf das Repository in der Regel Artefakte herunterladen und Protokolle durchsuchen kann.einschließlich externer Mitarbeiter, sofern Sie ihnen Zugriff gewähren.

OIDC und kurzlebige Cloud-Zugangsdaten

Eine der wirkungsvollsten Änderungen, die Sie vornehmen können, ist, die Speicherung von Anmeldeinformationen für langlebige Cloud-Anbieter als GitHub-Geheimnisse vollständig einzustellen.Verwenden Sie stattdessen OpenID Connect (OIDC), um kurzlebige, klar definierte Token zu erhalten, die an eine bestimmte Workflow-Identität gebunden sind.

Der Durchfluss auf hohem Niveau ist einfach:

• Ihr Cloud-Anbieter (AWS, Azure, GCP usw.) ist so konfiguriert, dass er dem OIDC-Anbieter von GitHub vertraut.
• Sie definieren eine Identitätsrichtlinie, die besagt: „Nur Tokens aus dieser Organisation/diesem Repository/diesem Branch oder dieser Umgebung werden akzeptiert.“
• Während eines Jobs kann GitHub ein OIDC-Token anfordern, und Ihr Workflow verwendet eine Cloud-spezifische Aktion (zum Beispiel). aws-actions/configure-aws-credentials) um dies gegen ein kurzlebiges Rollen- oder Servicekonto-Token einzutauschen.

Die Vertrauensbedingung ermöglicht sehr detaillierte Analysen.Eine typische Richtlinie für AWS könnte Folgendes beinhalten:

"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:Org/Repo:ref:refs/heads/main"
}

Dadurch wird sichergestellt, dass nur Workflows aus einem bestimmten Repository und Branch die Rolle übernehmen können.Für eine noch präzisere Abgrenzung können Sie die Rolle an eine bestimmte Umgebung anstatt an einen Branch binden und diese Umgebung dann ausschließlich für den Deployment-Job vorschreiben. Bei einer kompromittierten Drittanbieteraktion in einem Nicht-Deployment-Job schlagen OIDC-Aufrufe fehl.

Die Verwendung von OIDC beseitigt nicht die Notwendigkeit von Rollenrichtlinien mit minimalen Berechtigungen in der Cloud.Dadurch werden statische Zugriffsschlüssel in GitHub Secrets eliminiert, wo sie von außerhalb von GitHub gestohlen und unbegrenzt wiederverwendet werden könnten.

Zweigschutz, Regelsätze und Umgebungen arbeiten zusammen

Viele der gefährlichen Angriffsmethoden in GitHub Actions lassen sich auf Folgendes reduzieren: „Angreifer schleust bösartige Änderungen in einen geschützten Branch ein.“Zweigschutz und Regelsätze sind dort Ihre wichtigste Verteidigungslinie.

Auf Ästen wie main or productionMan möchte normalerweise mindestens:

• Vor dem Zusammenführen ist ein Pull Request erforderlich. – Direkte Schubsbewegungen sind nicht zulässig.
• Mindestens eine (oftmals mehrere) positive Bewertung ist erforderlich. von jemand anderem als dem letzten Schieber.
• Veraltete Genehmigungen werden beim Hinzufügen neuer Commits verworfen. – damit Angreifer nach der Überprüfung keinen Code einschleusen können.
• Genehmigung des letzten überprüfbaren Push erforderlich – verhindert, dass ein Angreifer die PR einer anderen Person kapert, schlechten Code einspielt und sich selbst genehmigt.

Anschließend können Sie diese Schutzmechanismen mit Umgebungen verbinden.. Zum Beispiel a production Die Umgebung akzeptiert möglicherweise nur Bereitstellungen von der main Um die Änderungen zu verzweigen, sollte möglicherweise auch eine manuelle Genehmigung durch eine kleine Gruppe von Prüfern erforderlich sein (mit aktivierter Option „Selbstprüfung verhindern“). Auf diese Weise kann ein einzelnes kompromittiertes Mitarbeiterkonto nicht ohne ausdrückliche Beteiligung einer anderen Person beliebigen Code in die Produktionsumgebung einschleusen.

Seien Sie vorsichtig mit Umgebungsregeln, die von Bereitstellungen selbst abhängen. (Zum Beispiel: „Erfordern, dass Deployments erfolgreich abgeschlossen werden, bevor Tag-Aktualisierungen zugelassen werden“). Bei schlechter Strukturierung können zirkuläre Abhängigkeiten oder Pseudo-Kontrollen entstehen, die ein Mitarbeiter durch Bearbeiten der Workflows umgehen kann. Das sicherste Vorgehen ist nach wie vor: starker Branch-Schutz → eng abgegrenzte Umgebungen → explizite Verwendung dieser Umgebungen nur in den wenigen Jobs, die sie tatsächlich benötigen.

Runner verwalten: GitHub-gehostet vs. selbstgehostet

Runner sind die Maschinen, die Ihre Arbeitsabläufe tatsächlich ausführen.Bei den von GitHub gehosteten Runnern handelt es sich um kurzlebige VMs, die von GitHub verwaltet werden; bei den selbst gehosteten Runnern handelt es sich um Maschinen oder Container, die Sie bereitstellen und kontrollieren.

Auf GitHub gehostete Runner sind standardmäßig im Allgemeinen viel sicherer.:

• Sie sind vergänglich und werden für jeden Auftrag zurückgesetzt.Es gibt also keinen dauerhaften Kompromiss über mehrere Durchläufe hinweg.
• GitHub veröffentlicht SBOMs für Standard-Images (Ubuntu, Windows, macOS)., wodurch Sie vorinstallierte Software auf Sicherheitslücken analysieren können.
• Bestimmte schädliche Hosts werden standardmäßig blockiert. (zum Beispiel bekannte Kryptomining-Pools) über die /etc/hosts Konfiguration.

Selbstverwaltete Runner sind leistungsstark, aber gefährlich. wenn Sie sie nicht wie Produktionsserver behandeln:

• Sie sind normalerweise nicht vergänglich, es sei denn, man gestaltet sie selbst.So kann jeder bösartige Workflow versuchen, sich dauerhaft einzunisten, sich seitlich auszubreiten oder Daten zu stehlen.
• Sie verfügen oft über einen umfassenderen Netzwerkzugang und lokale Geschäftsgeheimnisse. (SSH-Schlüssel, Cloud-CLIs, Metadatendienste), wodurch das Risiko einer Kompromittierung steigt.
• Öffentliche Repositorien sollten fast nie selbstgehostete Runner verwenden.Denn jeder kann einen Pull Request öffnen, der letztendlich Code auf Ihrer Infrastruktur ausführt.

Falls Sie selbstgehostete Runner verwenden müssen, unterteilen Sie diese anhand von Vertrauensgrenzen.Verwenden Sie Läufergruppen und Einschränkungen, damit:

• Öffentliche und private Projekte teilen sich nie denselben Pool an Projektleitern.
• Hochsensible Repositories (z. B. Produktionsinfrastrukturen) verfügen über eigene, streng kontrollierte Runner.
• Nur bestimmte Repositories oder Organisationen können Jobs an eine bestimmte Gruppe senden.

Das Risiko lässt sich weiter reduzieren, indem Just-in-Time (JIT)-Runner über die REST-API bereitgestellt werden.Diese Runner registrieren sich dynamisch, führen maximal einen Job aus und werden anschließend automatisch entfernt. Sie müssen weiterhin sicherstellen, dass der zugrunde liegende Host bereinigt oder gelöscht wird, aber dadurch wird das Zeitfenster, in dem ein kompromittierter Job nachfolgende Jobs beeinträchtigen kann, verkleinert.

Behandeln Sie selbstgehostete Runner wie jedes andere Produktionssystem.: Überwachung der Prozessaktivität, Sperrung ausgehender Netzwerkpfade, Aktualisierung von Betriebssystem und Tools sowie die Annahme, dass jeder Benutzer, der die Berechtigung zum Auslösen von Workflows besitzt, effektiv auch die Codeausführung auf dieser Maschine ermöglicht.

Integrierte Sicherheitsfunktionen: Code-Scanning, Scorecards und Dependabot

GitHub bietet eine Reihe erstklassiger Funktionen, die speziell darauf abzielen, Workflow- und Abhängigkeitsrisiken aufzudecken.Und sie sind die geringen Einrichtungskosten wert.

Code-Scanning (zum Beispiel mit CodeQL) kann nun auch GitHub Actions-Workflows selbst analysieren.Nicht nur der Quellcode Ihrer Anwendung. Regeln wie „Übermäßige Offenlegung von Geheimnissen“ können Muster erkennen, bei denen GitHub nicht feststellen kann, welche Geheimnisse erforderlich sind (z. B. dynamische Geheimnisse). secrets[myKey] Verwendung in Matrix-Builds), was dazu führt, dass mehr Geheimnisse als nötig in den Jobspeicher geladen werden.

OpenSSF Scorecards und die Scorecards-Aktion fügen eine weitere Ebene hinzu, indem sie den Sicherheitsstatus Ihrer Abhängigkeiten bewerten.Für Aktionen auf dem Markt können Scorecards unsichere Lieferkettenpraktiken kennzeichnen, wie zum Beispiel:

• Abhängigkeiten werden nicht fixiert.
• Fehlende Zweigschutzmechanismen oder Anforderungen an die Codeüberprüfung.
• Fehlende Sicherheitsrichtlinien oder unzureichende Prozesse zur Reaktion auf Sicherheitslücken.

Dependabot spielt hier zwei Rollen.:

• Dependabot-Warnungen Sie werden gewarnt, wenn eine Abhängigkeit Ihrer Aktionen oder Arbeitsabläufe eine bekannte Sicherheitslücke aufweist, basierend auf der GitHub Advisory Database.
• Dependabot-Versions- und Sicherheitsupdates kann automatisch Pull Requests öffnen, um Aktionsversionen zu erhöhen und anfällige Releases zu patchen.

Der Abhängigkeitsgraph für Workflows ist ein weiteres unterschätztes Feature.GitHub behandelt Ihre Workflow-Dateien als Manifeste und kann Ihnen Folgendes anzeigen:

• Auf welche Aktionen und wiederverwendbaren Workflows Sie angewiesen sind.
• Welchen Konten oder Organisationen gehören sie?
• Welche Versionen oder SHAs haben Sie festgelegt?

Dadurch wird es einfacher, Fragen wie „Wo setzen wir diese kompromittierte Aktion ein?“ zu beantworten. wenn neue Warnmeldungen veröffentlicht werden, und um umfassende Sanierungsmaßnahmen zu planen.

Überwachung, Prüfung und Governance

Sicherheit endet nicht mit der Konfiguration; Sie benötigen auch Einblick in die Vorgänge im Laufe der Zeit.GitHub stellt Audit-Logs und Sicherheitsprotokolle sowohl auf Benutzer- als auch auf Organisationsebene bereit.

Aus Sicht der Aktionen gibt es mehrere Dinge, die es wert sind, verfolgt zu werden.:

• Ereignisse im Zusammenhang mit Geheimnissen, sowie org.update_actions_secret oder Änderungen am Repository-Geheimnis. Diese deuten auf die Erstellung, Aktualisierung oder Löschung sensibler Zugangsdaten hin.
• Workflow- und Regelsatzänderungen: Wer hat die Schutzregeln geändert, wer hat die Bereitstellungsabläufe bearbeitet, wer hat die Umgebungsschutzmaßnahmen geändert?
• Neue oder geänderte Marketplace-Aktionen und GitHub-Apps in der Organisation installierte Systeme, insbesondere solche, denen ein breiter Repository- oder Organisationsbereich gewährt wurde.

Sie können die eigenen Kontrollmechanismen von GitHub durch Richtliniendurchsetzungsanwendungen wie Allstar von OpenSSF ergänzen., das kontinuierlich überprüft, ob die Repositories den Sicherheitsrichtlinien Ihrer Organisation entsprechen (Branch-Schutz, aktivierte Code-Überprüfung, erforderliche Reviews usw.).

Im Bereich der „laufenden Arbeitsabläufe“ sollte man auf Muster achten, die auf Missbrauch hindeuten könnten.Ungewöhnliche Spitzenwerte bei der Laufzeit von Jobs, unerwarteter ausgehender Datenverkehr von den Runnern oder häufige Jobfehler bei Schritten, die Geheimnisse oder OIDC-Tokens verarbeiten, sind Anzeichen für böswillige Absichten, aber gute Ausgangspunkte für Untersuchungen.

Zusammengefasst bedeutet dies, GitHub Actions als Teil Ihrer zentralen Produktionsumgebung zu betrachten.Nicht nur „Glue-Skripte“. Mit sorgfältig definierten Geheimnissen und Tokens, striktem Schutz von Branches und Umgebungen, zurückhaltendem Einsatz von Drittanbieteraktionen, gehärteten Runnern und kontinuierlicher Überwachung mit Tools wie CodeQL, Scorecards und Dependabot geben Sie Ihrem Unternehmen eine echte Chance gegen die wachsende Zahl von CI/CD- und Lieferkettenangriffen, die gezielt GitHub-Workflows angreifen.