Sicherheitscheckliste: So schützen Unternehmen GitHub vor Angriffen

GitHub hat sich längst von einer einfachen Code-Plattform zu einem zentralen Steuerungssystem für Unternehmen entwickelt. Für viele Organisationen fungiert GitHub gleichzeitig als Identitätsmanager, Software-Lieferkette, CI/CD-Plattform, Geheimnistresor, Bereitstellungs-Orchestrator und System für Produktionsänderungen. Diese Vielseitigkeit macht die Plattform zu einem kritischen Kontrollpunkt – vergleichbar mit einer Steuerungsebene in der Produktion.

Doch viele Unternehmen behandeln GitHub noch immer wie ein reines Entwicklungstool, das allein der Engineering-Abteilung gehört. Diese Sichtweise ist gefährlich: Ein unsachgemäß gesicherter GitHub-Zugriff kann nicht nur Code, sondern ganze Arbeitsabläufe, Build-Systeme und Produktionsumgebungen kompromittieren. Ein aktueller Leitfaden der DEV Community zeigt nun, wie Unternehmen GitHub systematisch absichern können – nicht als theoretische Best Practices, sondern als umsetzbare Sicherheitsstandards.

Eine dreistufige Strategie für die GitHub-Sicherheit

Der Leitfaden unterteilt die Absicherung in drei Ebenen, die aufeinander aufbauen:

• Strategische Ebene: Definiert, warum GitHub als kritische Kontrollebene („Tier-0“) behandelt werden muss. Verantwortlich sind CISOs, Engineering-Leiter und Plattformverantwortliche.
• Sicherheitsstandards: Legt verbindliche Kontrollen, Ausnahmen und Verantwortlichkeiten fest. Hier arbeiten Security-, Plattform- und DevSecOps-Teams zusammen.
• Betriebliche Umsetzung: Unterstützt Onboarding, Überwachung, Incident-Response und regelmäßige Prüfungen. Zuständig sind SOC-Teams, Repository-Besitzer und Release-Ingenieure.

Jede Kontrollmaßnahme folgt dabei einer klaren Sprache:

• Must/Required: Unverzichtbare Basiskontrolle, sofern keine dokumentierte Ausnahme vorliegt.
• Should/Recommended: Sehr empfohlene Maßnahme; Abweichungen erfordern eine Begründung.
• May/Optional: Abhängig vom Risikoprofil des jeweiligen Repositories.

Jede verbindliche Kontrolle sollte schließlich mit einer eindeutigen ID, Anforderung, Verantwortlichkeit, Durchsetzung, Nachweispflicht und Überwachung verknüpft sein. Abschnitt 29 des Leitfadens enthält eine detaillierte Zuordnung, die Administratoren zeigt, wo sie GitHub-Einstellungen finden, wie sie diese konfigurieren und welche Nachweise sie führen müssen.

Voraussetzungen für die Umsetzung

Bevor Unternehmen die Empfehlungen umsetzen, sollten sie prüfen, ob ihre GitHub-Umgebung die technischen Grundlagen erfüllt:

• Nutzung von GitHub Organization oder GitHub Enterprise Cloud.
• Repositories enthalten Produktionscode, Infrastruktur-as-Code (IaC), Automatisierung, CI/CD-Workflows und interne Tools.
• GitHub Actions ist aktiviert oder geplant.
• Entwickler arbeiten mit Pull Requests für Änderungen.
• Einige Repositories sind mit AWS, Azure, GCP, Kubernetes, Paketregistern oder Bereitstellungstools verknüpft.

Wo spezifische Funktionen wie GitHub Advanced Security, GitHub Secret Protection oder GitHub Code Security erforderlich sind, muss zunächst geprüft werden, ob die aktuelle GitHub-Edition diese unterstützt. Der Leitfaden enthält eine Matrix, die zeigt, welche Kontrollen in welcher GitHub-Version verfügbar sind und welche Alternativen es bei fehlenden Funktionen gibt.

GitHub-Funktionen und Lizenzvalidierung im Überblick

| Kontrollbereich | Empfohlene GitHub-Funktion | Verfügbarkeitsprüfung | Kompensierende Maßnahme bei Nichtverfügbarkeit | |----------------|----------------------------|-----------------------|-----------------------------------------------| | Unternehmensidentität | SAML SSO, SCIM, Enterprise Managed Users | Enterprise-/Organisationseinstellungen | IdP-gesteuerte Zugriffsprüfungen und manuelle Deprovisionierung | | Repository-Governance | Organisations- oder Enterprise-Regelsätze | Verfügbarkeit für private Repositories prüfen | API- oder IaC-gesteuerte Branch-Schutzregeln | | Geheimnisschutz | Secret Scanning, Push Protection | Secret Protection / GHAS | Pre-Commit-Scans, CI-basierte Geheimnisprüfung | | Code-Sicherheit | CodeQL, Code Scanning, Security Overview | Code Security / GHAS | Integration von Drittanbieter-SAST-Tools | | Abhängigkeitssicherheit | Dependabot, Dependency Review, Security Updates | Repository-Einstellungen | Drittanbieter-SCA mit PR-Blockierung und SBOM-Prüfung | | Audit-Überwachung | Audit-Log-Export/API/Streaming | Enterprise-/Organisationseinstellungen | Geplante Exporte mit SIEM-Integration | | CI/CD-Identitätsföderation | GitHub Actions OIDC | Verfügbarkeit für Cloud-Anbieter prüfen | Kurzlebige Anmeldeinformationen über einen Broker; statische Geheimnisse nur in Ausnahmefällen | | Artefakt-Provenienz | GitHub Artifact Attestations | Actions- und Release-Workflow-Unterstützung | Externe Signatur-Tools wie Sigstore/cosign | | Runner-Isolation | Runner-Gruppen, Ephemere Runner, Hosted Runner Controls | Enterprise-Actions-Runner-Einstellungen | Dedizierte Cloud-Konten/Projekte und kurzlebige Runner-Instanzen |

Wichtig: Das Ziel der Sicherheit darf nicht durch fehlende native Funktionen gefährdet werden. Entweder wird die erforderliche GitHub-Funktion aktiviert, ein zugelassenes Drittanbieter-Tool eingesetzt oder eine zeitlich begrenzte Ausnahme mit kompensierenden Kontrollen dokumentiert.

GitHub als kritische Kontrollebene etablieren

Der häufigste Fehler bei der GitHub-Sicherheit ist die Annahme, die Plattform gehöre allein der Engineering-Abteilung. Doch GitHub steuert heute nicht nur Code, sondern auch Identitäten, Bereitstellungen und sensible Daten. Ein solcher Missstand schafft Angriffsflächen, die über reine Code-Kompromittierung hinausgehen.

Unternehmen sollten daher ein formales Ownership-Modell für GitHub einführen, das Verantwortlichkeiten klar zuweist:

• Unternehmens- und Organisations-Einstellungen: Verantwortlich ist der CISO oder Head of Engineering. Ziel ist die zentrale Steuerung von Richtlinien, Zugriffskontrollen und Auditierbarkeit.
• Repository-Besitz: Engineering-Leitung und Repository-Maintainer sind für sichere Änderungssteuerung und Code-Ownership zuständig.
• GitHub Actions: Platform Engineering, DevOps und DevSecOps-Teams kontrollieren die CI/CD-Ausführung.
• Geheimnisse und Token: Security-Teams und App-Teams sorgen dafür, dass keine langlebigen Anmeldeinformationen unkontrolliert genutzt werden.
• OAuth / GitHub Apps: Security-Teams genehmigen nur vertrauenswürdige Integrationen.
• Self-Hosted Runner: Platform Engineering und Infrastruktur-Teams stellen isolierte, überwachte und kurzlebige Runner-Instanzen sicher.
• Sicherheitswarnungen: AppSec-Teams analysieren und beheben Warnmeldungen.

Diese klare Aufteilung stellt sicher, dass GitHub nicht nur als Entwicklungstool, sondern als kritische Steuerungsebene behandelt wird – mit definierten Verantwortlichkeiten, Überwachungsmechanismen und kontinuierlicher Verbesserung.