GitHub-Organisation: So sichern Sie Repositories und CI/CD richtig ab

GitHub ist mehr als nur ein Code-Hosting-Dienst: Es steuert Entwicklungsprozesse, CI/CD-Pipelines, Geheimnisse, Paketfreigaben und sogar Produktionsbereitstellungen. Eine unsichere Organisation in GitHub kann daher schwerwiegende Folgen haben – von Datenlecks bis hin zu kompromittierten Bereitstellungen. Doch wie lassen sich organisationale Zugriffe, Repository-Einstellungen und Workflows systematisch absichern? Und welche konkreten Einstellungen in GitHub sind dafür entscheidend?

Ein strukturierter Ansatz beginnt mit der Planung der Sicherheitsmaßnahmen. Dabei sollten Sie nicht isoliert einzelne Funktionen konfigurieren, sondern eine hierarchische Rollout-Strategie verfolgen. Diese vier Phasen helfen, Sicherheitslücken zu vermeiden und gleichzeitig die Produktivität nicht unnötig einzuschränken:

Phase 1: Identität und Organisationsverwaltung – Der Grundstein der Sicherheit

Die Grundlage jeder Sicherheitsstrategie in GitHub ist die Kontrolle über Identitäten und Zugriffsrechte. Ohne eine klare Definition, wer auf welche Ressourcen zugreifen darf, sind selbst die besten technischen Maßnahmen wirkungslos. Der erste Schritt besteht darin, die Anzahl der Organisationseigentümer zu reduzieren und Single Sign-On (SSO) als Standard durchzusetzen. Gleichzeitig sollte Multi-Faktor-Authentifizierung (MFA) für alle Benutzer obligatorisch sein – sowohl für direkte GitHub-Zugriffe als auch für externe Mitarbeiter oder Dienstkonten.

Ein zentraler Aspekt ist die Verwaltung von SSH-Schlüsseln für privilegierte Zugriffe. Hier empfiehlt es sich, hardwaregestützte Schlüssel zu bevorzugen, da diese gegen Diebstahl und Manipulation besser geschützt sind. Zudem sollten Sie die Berechtigungen für externe Mitarbeiter stark einschränken und die Erstellung neuer Repositories sowie Änderungen an Sichtbarkeit oder Forks kontrollieren.

• SSO für alle Organisationseigentümer und Administratoren aktivieren
• Phishing-resistente MFA/Passkeys über den Identity Provider (IdP) erzwingen
• Lokale MFA/Passkeys für Break-Glass-Konten und Dienstkonten beibehalten
• Anzahl der Organisationseigentümer auf ein Minimum reduzieren
• Organisationsebene auf „Keine Berechtigung“ als Standard setzen
• Externe Mitarbeiter und Repository-Erstellungsrechte einschränken

Phase 2: Repository-Kontrollen – Klare Regeln für Code und Prozesse

Nach der Absicherung der Identitäten folgt die Kontrolle über die Repositories selbst. Hier geht es darum, Standards für Branches, Code-Owner und Zugriffspfade zu definieren. Ein zentraler Baustein ist die Klassifizierung von Repositories nach ihrem Kritikalitätsgrad – etwa nach Datenempfindlichkeit oder geschäftlicher Relevanz. Diese Klassifizierung hilft, gezielt Schutzmaßnahmen wie spezielle Regeln für Produktionsbranches oder Hotfix-Pfade zuzuweisen.

Ein weiteres wichtiges Element sind Rulesets, die standardisierte Branches wie main oder develop schützen. Diese Regeln können erzwingen, dass Pull Requests bestimmte Kriterien erfüllen – etwa die Anwesenheit eines Code-Owners oder das Bestehen von Sicherheitsprüfungen. Zudem sollten Sie Push-Regeln für risikoreiche Dateipfade wie .env-Dateien oder Zertifikate definieren, um unbeabsichtigte Commits zu verhindern.

• Repositories nach Kritikalität klassifizieren (Critical/High/Medium/Low)
• Organisationsebene Rulesets für Standardbranches erstellen
• Repository-spezifische Rulesets für develop, release/* und hotfix/* definieren
• CODEOWNERS für Workflows, Infrastruktur-as-Code und Deployment-Pfade festlegen
• Push-Regeln für sensible Dateipfade und -typen implementieren

Phase 3: CI/CD und Supply-Chain-Sicherheit – Automatisierte Kontrollen in Pipelines

CI/CD-Pipelines sind ein häufiges Einfallstor für Angriffe, da sie oft Zugriff auf sensible Umgebungen und Geheimnisse haben. Eine der wichtigsten Maßnahmen ist die Einschränkung von GitHub Actions auf genehmigte Aktionen. Dies verhindert, dass bösartige oder unsichere Workflows in Ihrer Organisation ausgeführt werden. Gleichzeitig sollten Sie die Standardberechtigungen des GITHUB_TOKEN auf „Nur-Lesen“ setzen und explizite Berechtigungen für Workflows verlangen.

Ein weiterer kritischer Punkt ist der Umgang mit Geheimnissen. Langfristige Cloud-Geheimnisse sollten durch kurzlebige Tokens ersetzt werden, die über OpenID Connect (OIDC) generiert werden. Dies reduziert das Risiko von Geheimnislecks erheblich. Zudem empfiehlt es sich, GitHub Environments für Produktionsbereitstellungen zu nutzen, um Zugriffe und Berechtigungen granular zu steuern.

• GitHub Actions auf vertrauenswürdige Aktionen beschränken
• Standardberechtigungen des GITHUB_TOKEN auf „read-only“ setzen
• Explizite Workflow-Berechtigungen erzwingen
• Langfristige Geheimnisse durch OIDC-basierte Tokens ersetzen
• GitHub Environments für Produktionsbereitstellungen verwenden

Phase 4: Überwachung, Incident Response und laufende Validierung

Sicherheit ist kein einmaliger Prozess, sondern erfordert kontinuierliche Überwachung und Anpassung. GitHub bietet mehrere Funktionen, die dabei helfen: Secret Scanning und Push Protection warnen vor unbeabsichtigten Geheimnis-Commits, während CodeQL und Dependabot Sicherheitslücken in Code und Abhängigkeiten erkennen. Für selbstgehostete Runner sollten Sie zudem die Zugriffsrechte einschränken und regelmäßig überprüfen, ob alle Komponenten auf dem neuesten Stand sind.

Ein weiterer wichtiger Aspekt ist die Protokollierung und Incident Response. Regelmäßige Prüfungen der Audit-Logs helfen, verdächtige Aktivitäten frühzeitig zu erkennen. Gleichzeitig sollte ein Incident-Response-Playbook erstellt werden, das im Falle eines Sicherheitsvorfalls klare Schritte vorgibt – von der Isolierung betroffener Repositories bis hin zur Kommunikation mit den betroffenen Teams.

• Secret Scanning und Push Protection aktivieren
• CodeQL- oder Code-Scanning-Analysen einrichten
• Dependabot und Dependency Review für Abhängigkeitsmanagement nutzen
• Selbstgehostete Runner absichern und überwachen
• Regelmäßige Prüfung der Audit-Logs und Incident-Response-Planung

Die Implementierung dieser Maßnahmen erfordert zwar zunächst einen erhöhten Aufwand, zahlt sich jedoch langfristig aus. Eine gut abgesicherte GitHub-Organisation reduziert nicht nur das Risiko von Sicherheitsvorfällen, sondern schafft auch Vertrauen bei Kunden und Partnern. Zudem ermöglicht sie es Entwicklerteams, sich auf ihre Kernaufgaben zu konzentrieren – ohne ständig Sicherheitswarnungen oder Vorfälle managen zu müssen. Der Schlüssel zum Erfolg liegt dabei in der Kombination aus technischen Kontrollen, klaren Verantwortlichkeiten und einer Kultur der kontinuierlichen Verbesserung.