GitHub als kritische Enterprise-Plattform

In vielen modernen Unternehmen ist GitHub längst viel mehr als eine Plattform zur Verwaltung von Quellcode. Gerade im Zusammenspiel mit DevOps und GitOps ist GitHub inzwischen häufig ein zentraler Bestandteil von Softwareentwicklung, Infrastruktur-Management und Automatisierung.

Neben Anwendungscode liegen dort häufig auch IaC-(Infrastructure-as-Code-)Definitionen, Kubernetes-Konfigurationen, Architekturentscheidungen und weitere Bestandteile der technischen Plattform. Änderungen an Repositories können dadurch direkte Auswirkungen auf Software-Development-Prozesse und Cloud-Umgebungen haben.

Während Cloud-Landing-Zones, Netzwerke und Produktionsumgebungen meist nach klaren Sicherheitsstandards geschützt werden, wird bei der GitHub-Organisation selbst auch mal ein Auge zugedrückt ;)

So können aus Berechtigungen, manuellen Konfigurationen und fehlenden Governance-Prozessen Risiken entstehen, die durchaus vermeidbar gewesen wären.

Enterprise GitHub unter Beschuss

Dabei steht GitHub selbst nicht selten im Fokus von Angreifern. Ein direkter Angriff auf komplexe Infrastruktur-Komponenten wäre nicht der einfachste Weg in die Enterprise-Umgebung. Ein kompromittierter Benutzer-Account, lose Berechtigungen oder ein versehentlich veröffentlichtes Repository bieten da schon einen deutlich einfacheren Einstieg.

Die Absicherung von GitHub Enterprise ist deshalb keine reine Aufgabe des Developer-Teams, sondern ist ein zentraler Bestandteil moderner Cloud- und Identity-Security.

💡HINWEIS:

CI/CD-Pipelines und insbesondere GitHub-Actions betrachten wir hier bewusst nicht. Diese Themen bringen eigene Sicherheitsanforderungen mit sich, z.B bezogen auf Runner-Sicherheit, Workload Identity oder Pipeline-Hardening. Der Fokus dieses Artikels liegt auf der GitHub-Organisation selbst, Identity Management und Repository Governance.

Reality Check: Enterprise Governance & Strukturen

Bei der Analyse von GitHub-Organisationen zeigen sich häufig ähnliche Muster. Die größten Sicherheitsrisiken entstehen hier selten durch komplexe technische Schwachstellen, sondern durch fehlende Standards und Strukturen, die längst überholt sind.

Gewachsene Berechtigungen & vergessene Ausnahmen

Berechtigungen sind ein klassisches Beispiel. In vielen Organisationen erhalten Benutzer über die Zeit Zugriff auf zahlreiche Repositories, Teams oder Admin-Funktionen. Was ursprünglich als vorübergehende Ausnahme gedacht war, ‘rutscht hinter die Couch’ und bleibt unbemerkt weiter bestehen.

Temporär hat in Berechtigungsmodellen eine erstaunlich lange Halbwertszeit, in der Mitarbeitende oder Externe Zugriff auf deutlich mehr Informationen haben, als für ihre eigentliche Tätigkeit notwendig wäre.

Fehlende Identity-Integration

Ein weiteres Problem, dass wir bei shiftavenue regelmäßig antreffen, ist die fehlende Integration in zentrale Identity-Prozesse. Werden persönliche GitHub-Accounts ohne konsequente Kopplung an den unternehmensinternen Identity-Provider genutzt, entstehen Risiken beim Offboarding.

🚨 Ein deaktiviertes Unternehmenskonto bedeutet dann nicht automatisch, dass alle GitHub-Zugriffe ebenfalls entfernt wurden.

Gerade in großen Organisationen mit vielen Teams und Repositories führt die fehlende Standardisierung dieser Abläufe schnell zu einer überwucherten Berechtigungslandschaft.

Secret Leakage & ungeschützte Zugangsdaten

Auch im Umgang mit sensiblen Informationen verstecken sich zahlreiche Risiken.
Unabsichtlich (und häufig unbemerkt) gelangen immer wieder:

• API-Schlüssel,
• Cloud-Zugangsdaten,
• Service-Principal-Informationen,
• Datenbank-Credentials

in Repositories. Das große Problem dabei: Ein einmal veröffentlichtes Secret verschwindet nicht automatisch, nur weil es später aus dem aktuellen Code entfernt wird. Informationen können weiterhin Bestandteil der Git-Historie sein und müssen entsprechend behandelt werden.

Mit Secret Scanning und Push Protection bietet GitHub zwei wichtige Schutzmechanismen.

💡 Secret Scanning erkennt exponierte Credentials auch in der Git-Historie; Push Protection kann erkannte Secrets blockieren, bevor sie das Repository erreichen.

Diese technischen Schutzmaßnahmen ersetzen aber noch längst keine Sicherheitsstrategie. Secrets sollten grundsätzlich über geeignete Secret-Management-Lösungen verwaltet und regelmäßig überprüft werden.

Vernachlässigte Repository Governance

In vielen Unternehmen unterscheiden sich Repositories stark voneinander. Während einzelne Teams sehr hohe Sicherheitsstandards etablieren, fehlen in anderen Bereichen wichtige Schutzmaßnahmen komplett. Besonders kritisch wird es bei Repositories, die Infrastruktur oder produktionsnahe Komponenten enthalten.

Ohne verbindliche Governance können beispielsweise:

• Änderungen ohne ausreichende Reviews durchgeführt werden,
• Rulesets beziehungsweise Schutzmechanismen für wichtige Branches fehlen,
• kritische Änderungen ohne Vier-Augen-Prinzip erfolgen.

Gerade in GitOps-orientierten Umgebungen ist dies relevant, da Änderungen am Repository direkten Einfluss auf technische Systeme haben können.

🚨 Eine GitHub-Enterprise-Strategie benötigt deshalb klare Standards für Repository-Strukturen, Berechtigungen und Freigabeprozesse.

Fehlende Nachvollziehbarkeit & Konfigurationsdrift

Ein häufig unterschätztes Risiko ist die manuelle Verwaltung von GitHub über die Weboberfläche.

Ein Administrator passt „nur kurz“ eine Berechtigung an, ein Team erstellt ein Repository mit abweichenden Einstellungen oder verändert eine Sicherheitsregel „temporär“. Ohne geeignete Governance weiß niemand, ob diese Änderungen bewusst erfolgt sind oder ein Risiko.

Mit wachsender Organisation entsteht dadurch Konfigurationsdrift:
Der tatsächliche Zustand der Plattform unterscheidet sich also zunehmend von den gewünschten Sicherheitsstandards.

Für Enterprise-Umgebungen ist deshalb eine nachvollziehbare und standardisierte Verwaltung entscheidend.

Was eine sichere GitHub Enterprise Governance ausmacht

Eine robuste GitHub-Organisation basiert auf mehreren zentralen Prinzipien:

• zentrale Identitätssteuerung
• Least Privilege & klare Berechtigungsmodelle
• Standardisierte Sicherheitsrichtlinien
• Transparente Dokumentation & Auditierbarkeit

Schauen wir uns diese genauer an.

Zentrale Identitätssteuerung

Die Integration mit einem zentralen Identity Provider wie Microsoft Entra ID oder Okta bildet die Grundlage für kontrollierte Zugriffe.

Dadurch können Unternehmensrichtlinien für Authentifizierung, Zugriffsschutz und Benutzerlebenszyklen auch auf GitHub angewendet werden.

Least Privilege & klare Berechtigungsmodelle

Alle Benutzer sollten ausschließlich Zugriff auf die Ressourcen erhalten, die sie auch tatsächlich benötigen.

Statt großzügig Standardberechtigungen auszuteilen, müssen Zugriffe über fest definierte Teams und Rollen gesteuert werden. Das verkleinert nicht nur die Angriffsfläche, sondern begrenzt auch die potenzielle Reichweite kompromittierter Accounts.

Standardisierte Sicherheitsrichtlinien

Eine sichere Plattform läuft nicht ohne verbindliche technische Standards.
Dazu gehören beispielsweise:

• geschützte produktive Branches,
• verpflichtende Reviews,
• fixe, dokumentierte Repository-Regeln oder Rulesets,
• Secret-Schutzmaßnahmen,
• maximale Kontrolle über die Repository-Sichtbarkeit.

Der entscheidende Punkt ist dabei nicht nur die einmalige Aktivierung dieser Funktionen, sondern ihre konsequente Durchsetzung – und zwar flächendeckend in der gesamten Organisation.

Transparenz & Auditierbarkeit

In Enterprise-Umgebungen muss jederzeit nachvollziehbar sein, wer welche Änderungen durchgeführt hat.

💡 Das GitHub Audit Log liefert dafür Informationen dazu, wer eine Aktion durchgeführt hat, was geändert wurde und wann die Aktion stattgefunden hat.

Administrative Tätigkeiten sollten deshalb überwacht und in zentrale Sicherheitsprozesse integriert werden. Nur wenn Änderungen transparent sind, können Risiken erkannt und Sicherheitsanforderungen dauerhaft eingehalten werden.

IaC als strategischer Ansatz

Mit steigender Größe einer GitHub-Organisation reicht klassische Administration allein häufig nicht mehr aus. Die logische Konsequenz: GitHub selbst sollte nach denselben Prinzipien wie andere Infrastruktur-Komponenten verwaltet werden.

💡 Infrastructure as Code (IaC) ermöglicht es, Plattformkonfigurationen, Teams, Berechtigungen und Sicherheitsrichtlinien versioniert und nachvollziehbar zu managen.

Ein vergleichbarer Ansatz wird zum Beispiel beim Microsoft Entra ID Hardening verfolgt. Dort können privilegierte Rollen, Berechtigungen und Security-Policies mithilfe von IaC standardisiert, nachvollziehbar und kontrolliert verwaltet werden.

Wie sich Privileged Identity Management (PIM) in Entra ID mit Terraform und GitOps-Ansätzen automatisieren lässt, habe ich in meinem letzten Artikel im #shiftavenueBlog erklärt 👉„Entra ID Hardening: Privileged Identity Management (PIM) mit Terraform“.

Moderne Enterprise Security braucht GitHub Governance

GitHub Enterprise Hardening ist keine einzelne technische Maßnahme, sondern ein kontinuierlicher Governance-Prozess.

Eine sichere Developer Platform entsteht durch ein fortlaufendes Zusammenspiel aus:

• zentralem Identity Management,
• restriktiven Berechtigungsmodellen,
• standardisierten Repository-Regeln,
• Schutz vor Secret Leakage,
• transparenter Überwachung,
• automatisierter Verwaltung.

In DevOps- und GitOps-Umgebungen ist GitHub fester Teil der Unternehmensinfrastruktur. Die Plattform, auf der Anwendungen und Infrastruktur entstehen, braucht dieselben Sicherheitsanforderungen wie jedes andere kritische System.

Infrastructure as Code (IaC) und klare Governance-Ansätze sind dabei die Basis jeder Plattform, die sicher, skalierbar und effizient betrieben werden kann. Einzelne Sicherheitsfunktionen zu aktivieren ist der einfache Teil.

Die eigentliche Herausforderung ist eine Betriebsweise, die diese Sicherheitsstandards dauerhaft durchsetzt, ohne zu bremsen.

💡HINWEIS:

In unserem Enterprise GitHub & Governance Workshop analysieren wir die bestehende GitHub-Organisation gemeinsam mit internen Teams und erarbeiten konkrete Maßnahmen für Berechtigungsmodelle, Sicherheitsstandards und automatisierte Governance.