Ist GitHub sicher für private Informationen?

GitHub ist technisch gut abgesichert – die meisten Datenlecks entstehen trotzdem dort. Nicht, weil die Plattform unsicher wäre, sondern weil Passwörter, API-Schlüssel und .env-Dateien versehentlich in ein Repository geraten und dort dauerhaft in der Git-Historie liegen bleiben. Entscheidend ist die Grenze zwischen dem, was GitHub für Sie erledigt, und dem, was Ihre Verantwortung bleibt – plus die konkreten Schritte, falls doch einmal ein Schlüssel im Repo landet.

Was „sicher“ bei GitHub konkret bedeutet

GitHub (seit 2018 Teil von Microsoft) verschlüsselt Repository-Daten bei der Übertragung per TLS und im Ruhezustand auf den Servern. Ein privates Repository ist nur für Sie und die Personen sichtbar, die Sie ausdrücklich als Collaborator oder über ein Team hinzufügen. Suchmaschinen indexieren es nicht, anonyme Besucher sehen es nicht.

Das deckt den offensichtlichen Fall ab: Ihr Code liegt nicht offen im Netz. Es bedeutet aber ausdrücklich nicht, dass ein privates Repo ein sicherer Tresor für Geheimnisse ist. Zwei Dinge bleiben Ihre Verantwortung:

• Wer Zugriff hat. Jeder Collaborator, jedes Mitglied eines berechtigten Teams und jeder Personal Access Token mit Repo-Rechten kann den kompletten Inhalt inklusive Historie lesen.
• Was Sie hineinschreiben. GitHub prüft nicht, ob Ihr Code produktive Datenbank-Passwörter oder Kundendaten enthält. Das tut es nur, wenn Sie die entsprechenden Schutzfunktionen aktivieren (siehe unten).

Das eigentliche Risiko: versehentlich committete Geheimnisse

Der mit Abstand häufigste Sicherheitsvorfall ist kein Angriff auf GitHub, sondern ein Commit, der etwas enthält, das dort nicht hingehört: ein API-Schlüssel im Quellcode, eine config.php mit Datenbank-Zugangsdaten, eine .env-Datei, ein privater SSH-Key.

Bei öffentlichen Repositories ist das besonders brisant: Bots durchsuchen neue Commits auf GitHub innerhalb von Sekunden nach gültigen Schlüsseln. Ein aus Versehen gepushter AWS- oder Stripe-Key kann binnen Minuten missbraucht werden.

Warum Löschen nicht reicht

Der klassische Fehler: Man bemerkt den Schlüssel, löscht ihn im nächsten Commit und hält das Problem für erledigt. Ist es nicht. Git speichert jede Version. Der alte Stand mit dem Geheimnis liegt weiter in der Historie und lässt sich mit einem Blick auf den früheren Commit lesen.

Das bloße Entfernen aus dem aktuellen Stand:

git rm --cached .env
echo ".env" >> .gitignore
git commit -m "Entferne .env aus dem Tracking"

löscht die Datei nur aus künftigen Commits – nicht aus der Vergangenheit. Um sie wirklich aus der gesamten Historie zu tilgen, brauchen Sie ein History-Rewrite-Werkzeug wie git-filter-repo (empfohlen; git filter-branch gilt als veraltet) oder den BFG Repo-Cleaner:

# mit git-filter-repo
git filter-repo --path .env --invert-paths

Anschließend müssen Sie den umgeschriebenen Verlauf force-pushen. Wie das sauber funktioniert und welche Fallstricke es dabei gibt, lesen Sie unter Was ein Git Force Push macht.

Der wichtigste Schritt: das Geheimnis sofort ungültig machen

Merken Sie sich diese Regel: Ein Schlüssel, der einmal in einem Repository war, gilt als kompromittiert. History-Rewriting entfernt ihn aus Ihrer Kopie, aber Sie wissen nie, wer den Commit vorher schon geklont, geforkt oder in einem Cache gespeichert hat. Rotieren Sie daher jeden offengelegten Zugang, statt sich nur auf das Löschen zu verlassen:

1. Den betroffenen Schlüssel beim Anbieter (AWS, Stripe, Datenbank etc.) widerrufen und neu erzeugen.
2. Die neuen Zugangsdaten überall eintragen, wo sie gebraucht werden.
3. Danach die Historie bereinigen – in dieser Reihenfolge, nicht umgekehrt.

Geheimnisse gar nicht erst committen

Am günstigsten ist der Vorfall, der nie passiert. Drei Maßnahmen verhindern die meisten Fälle:

1. .gitignore konsequent pflegen. Alles, was Zugangsdaten oder Umgebungsspezifisches enthält, gehört ausgeschlossen:

.env
.env.*
config.local.php
*.pem
*.key
/secrets/

2. Geheimnisse über Umgebungsvariablen laden, nicht als Konstante im Code. Eine .env.example mit leeren Platzhaltern gehört ins Repo, die echte .env niemals.

3. Secret Scanning und Push Protection aktivieren. GitHub kann Commits automatisch auf bekannte Schlüsselmuster prüfen. Push Protection blockiert einen Push sogar, bevor das Geheimnis überhaupt auf dem Server landet. Für öffentliche Repositories sind beide Funktionen kostenlos und standardmäßig verfügbar. Für private Repositories sind sie Teil des kostenpflichtigen Sicherheitspakets (früher GitHub Advanced Security).

Ergänzend lohnt sich ein lokaler Pre-Commit-Hook (z. B. mit gitleaks oder pre-commit), der schon auf dem Rechner Alarm schlägt, bevor etwas überhaupt in einen Commit gelangt.

Das Konto absichern

Selbst ein sauberes Repository nützt wenig, wenn der Zugang schwach ist.

• Zwei-Faktor-Authentifizierung (2FA): Für alle Nutzer, die Code auf GitHub.com beitragen, ist 2FA inzwischen Pflicht. Nutzen Sie bevorzugt eine Authenticator-App oder einen Hardware-Key statt SMS.
• Keine Passwörter für Git über HTTPS: GitHub akzeptiert seit August 2021 keine Kontopasswörter mehr für Git-Operationen. Verwenden Sie einen Personal Access Token – am besten fein granuliert und mit Ablaufdatum – oder einen SSH-Schlüssel.
• Least Privilege: Geben Sie Collaboratoren nur die Rechte, die sie brauchen. Prüfen Sie regelmäßig, wer Zugriff hat, und entfernen Sie ausgeschiedene Mitarbeiter oder alte Tokens sofort.
• Dependabot: Lassen Sie sich vor verwundbaren Abhängigkeiten warnen – ein Sicherheitsleck steckt oft nicht in Ihrem Code, sondern in einer eingebundenen Bibliothek.

DSGVO und personenbezogene Daten

Für den deutschen und europäischen Kontext kommt eine zweite Ebene hinzu. GitHub speichert die Daten von GitHub.com überwiegend in den USA. Wer dort personenbezogene Daten Dritter verarbeitet, benötigt eine passende Rechtsgrundlage und in der Regel einen Auftragsverarbeitungsvertrag mit Microsoft/GitHub. Zertifizierungen wie ISO 27001 und SOC 2 sind vorhanden, ersetzen aber nicht Ihre eigene Prüfung.

Die praktische Konsequenz: Reale Kundendaten, Ausweiskopien, produktive Zugangsdaten oder Gesundheitsdaten gehören nicht in ein Repository – auch nicht in ein privates. Für Geheimnisse ist ein dedizierter Secrets-Manager (etwa HashiCorp Vault, ein Cloud-KMS oder GitHub Actions Secrets für CI/CD) der richtige Ort. Welche Werkzeuge sich hier grundsätzlich datenschutzkonform betreiben lassen, ordnet der Beitrag Welche Apps sind DSGVO-konform? ein.

Häufige Fragen

Kann GitHub selbst meine privaten Repositories einsehen? Technisch haben Betreiber-Systeme Zugriff auf die gespeicherten Daten, und in eng begrenzten Fällen (etwa Support auf Ihre Anfrage oder erzwungene rechtliche Vorgänge) kann autorisiertes Personal zugreifen. Für den Normalbetrieb sind private Repos gegenüber anderen Nutzern abgeschottet. Wer das ausschließen will, verschlüsselt sensible Inhalte zusätzlich clientseitig oder nutzt eine selbst gehostete Lösung.

Ist ein privates Repository sicher genug für Passwörter, wenn nur ich Zugriff habe? Nein. Passwörter und Schlüssel gehören auch dann nicht in Versionskontrolle, wenn Sie allein am Projekt arbeiten. Ein späterer Collaborator, ein kompromittiertes Token oder ein aus Versehen öffentlich gestelltes Repo legt die gesamte Historie offen. Nutzen Sie einen Passwort- oder Secrets-Manager.

Ist GitHub sicherer als GitLab oder eine selbst gehostete Lösung? Die großen Plattformen bieten ein vergleichbares Sicherheitsniveau; der Unterschied liegt in Ihrer Konfiguration und Ihrem Umgang mit Geheimnissen. Wer volle Kontrolle über den Speicherort braucht (etwa aus DSGVO-Gründen), kann Git selbst hosten – handelt sich damit aber die komplette Verantwortung für Updates, Backups und Absicherung ein. GitHub und die zugrunde liegende Git-Technik sind übrigens nicht dasselbe; den Unterschied erklärt Ist Git SCM dasselbe wie GitHub?.