Sichern Ihrer Git-Repositories: Best Practices und nicht vertrauenswürdige Quellen

Die Sicherung Ihrer Git-Repositories bedeutet mehr, als nur Code privat zu halten. Ein Repository kann Geheimnisse, ausführbare Hooks, Lieferkettenrisiken, sensible Verlaufsdaten und Konfigurationen enthalten, die jeden Entwickler betreffen, der es klont.

Gute Git-Sicherheitspraktiken helfen Ihnen, durchgesickerte Anmeldedaten, unsichere Automatisierung und versehentliches Vertrauen in Code aus unbekannten Quellen zu vermeiden. Die Grundlagen sind einfach, müssen aber konsequent angewendet werden.

Schützen Sie Geheimnisse, bevor sie in Git gelangen

Das sicherste Geheimnis ist das, das niemals in das Repository gelangt. API-Schlüssel, private SSH-Schlüssel, Cloud-Anmeldedaten, Datenbankpasswörter, Tokens und .env-Dateien sollten vollständig aus Git herausgehalten werden.

Fügen Sie lokale Geheimnisdateien zur .gitignore hinzu:

.env
.env.*
*.pem
id_rsa
id_ed25519

Seien Sie vorsichtig mit .env.example. Diese Datei ist oft nützlich, sollte aber gefälschte Platzhalterwerte enthalten:

DATABASE_URL=postgres://user:password@localhost:5432/app
API_TOKEN=replace-me

Fügen Sie keine echten Werte „nur zum Testen“ ein. Der Git-Verlauf merkt sich alte Versionen, selbst wenn Sie eine Zeile in einem späteren Commit löschen.

Wenn Sie versehentlich ein Geheimnis committen, behandeln Sie es als offengelegt. Entfernen Sie es aus dem aktuellen Baum, rotieren Sie die Anmeldedaten in dem Dienst, der sie ausgestellt hat, und entscheiden Sie dann, ob eine Bereinigung des Verlaufs erforderlich ist. Das Umschreiben des Verlaufs kann helfen, die zukünftige Offenlegung zu reduzieren, garantiert aber nicht, dass das Geheimnis nie kopiert wurde.

Teams sollten auch Geheimnisscans verwenden. Viele gehostete Git-Plattformen bieten Scans für gängige Token-Muster. Lokale Pre-Commit-Tools können Fehler früher erkennen, bevor ein Push den Server erreicht.

Verwandte Betriebsmuster finden Sie unter Mastering Environment Variables for Configuration and Secrets.

Beschränken Sie Zugriff und Branch-Änderungen

Die Repository-Sicherheit beginnt mit der Zugriffskontrolle. Geben Sie Personen den geringstmöglichen Zugriff, den sie benötigen. Jemand, der nur Code überprüft, braucht wahrscheinlich keine Admin-Rechte. Ein CI-Dienstkonto benötigt wahrscheinlich keine Berechtigung, Branches umzuschreiben.

Überprüfen Sie diese Einstellungen regelmäßig:

• Repository-Administratoren und -Eigentümer.
• Mitarbeiter mit Schreibzugriff.
• Bereitstellungsschlüssel und Maschinenbenutzer.
• Persönliche Zugriffstoken, die von der Automatisierung verwendet werden.
• Webhooks, die Repository-Ereignisse empfangen.
• Branch-Schutzregeln.

Geschützte Branches sind eine der nützlichsten Kontrollen. Für wichtige Branches wie main sollten Pull-Requests, Statusprüfungen und Überprüfungen vor dem Zusammenführen erforderlich sein. Deaktivieren Sie Force-Pushes, es sei denn, Ihr Team hat einen sehr spezifischen Grund, sie zuzulassen.

Signierte Commits oder signierte Tags können auch in Umgebungen mit höherem Vertrauen hilfreich sein. Sie machen Code nicht von sich aus sicher, können aber beweisen, dass ein Commit oder Release-Tag von einem Schlüssel erstellt wurde, den Ihr Team erkennt.

Verwenden Sie Tags sorgfältig für Releases. Wenn ein Bereitstellungsprozess Tags vertraut, schränken Sie ein, wer sie erstellen oder verschieben kann. Ein verschobener Release-Tag kann Audits und Bereitstellungen verwirren.

Seien Sie vorsichtig mit nicht vertrauenswürdigen Repositories

Das Klonen von Code aus einer nicht vertrauenswürdigen Quelle ist üblich. Das sofortige Ausführen ist der riskante Teil. Ein Git-Repository kann Build-Skripte, Paket-Lebenszyklus-Skripte, Makefiles, Container, CI-Konfiguration und Anweisungen enthalten, die Code auf Ihrem Rechner ausführen.

Bevor Sie etwas ausführen, überprüfen Sie das Repository:

git clone --no-checkout https://example.com/project.git
cd project
git log --oneline -5
git status

Überprüfen Sie dann risikoreiche Dateien:

• Shell-Skripte wie install.sh oder bootstrap.sh.
• Paketskripte in package.json.
• CI-Dateien unter .github/workflows/, .gitlab-ci.yml oder ähnlichen Pfaden.
• Dockerfiles und Compose-Dateien.
• Makefiles.
• Sprachspezifische Abhängigkeitsmanifeste.

Führen Sie keine curl | bash-Setup-Befehle aus einer zufälligen README aus. Wenn ein Projekt einen Installer erfordert, laden Sie ihn herunter, lesen Sie ihn und führen Sie ihn wenn möglich in einer Wegwerf-Umgebung aus.

Git-Hooks verdienen besondere Erwähnung. Hooks in .git/hooks/ werden normalerweise nicht als aktive Hooks übertragen, wenn Sie ein Repository klonen. Das ist gut. Aber ein Repository kann Skripte enthalten, die Hooks für Sie installieren. Lesen Sie diese Skripte, bevor Sie sie ausführen, da Hooks während Commits, Merges, Rebases und Pushes ausgeführt werden können.

Verwenden Sie für unbekannten Code Isolation. Eine temporäre virtuelle Maschine, ein Container oder eine abgesicherte Entwicklungsumgebung reduziert die Schadenswirkung, wenn ein Skript sich schlecht verhält. Montieren Sie Ihre SSH-Schlüssel, Cloud-Anmeldedaten oder Ihr Produktions-Kubeconfig nicht in einer Umgebung, die für nicht vertrauenswürdigen Code verwendet wird.

Halten Sie Repository-Verlauf und Dateien sauber

Sicherheit ist einfacher, wenn das Repository ordentlich ist. Große Binärdateien, generierte Archive, eingelagerte Geheimnisse und alte Konfigurationsdumps erschweren die Überprüfung und erhöhen das Risiko.

Verwenden Sie .gitignore für lokale Dateien und .gitattributes für Dateibehandlungsregeln. Zum Beispiel:

*.sh text eol=lf
*.png binary
*.jpg binary

Wenn Ihr Projekt große Dateien benötigt, überlegen Sie, ob Git Large File Storage geeignet ist. Standard-Git ist nicht ideal für große Build-Artefakte oder Mediendateien. Das direkte Speichern kann Klone verlangsamen und die Bereinigung sensibler Dateien erschweren.

Überprüfen Sie Pull-Requests auf sicherheitsrelevante Änderungen, nicht nur auf Anwendungslogik. Achten Sie auf:

• Neue Anmeldedaten oder Tokens.
• Neue Netzwerkaufrufe in Skripten.
• Änderungen an Abhängigkeitsquellen.
• Neue CI-Berechtigungen.
• Änderungen an Bereitstellungsskripten.
• Breite .gitignore-Änderungen, die wichtige Dateien verbergen.

Achten Sie auch auf Submodule. Sie verweisen auf externe Repositories und bestimmte Commits. Wenn Ihr Projekt sie verwendet, überprüfen Sie Submodule-URLs und Updates sorgfältig.

Wann Sie einen Fachmann hinzuziehen sollten

Ziehen Sie einen Sicherheitsingenieur, DevOps-Leiter oder Incident-Response-Verantwortlichen hinzu, wenn ein Geheimnis in ein öffentliches Repository gepusht wurde, ein geschützter Branch unerwartet force-gepusht wurde oder ein unbekannter Mitwirkender CI- oder Bereitstellungsautomatisierung geändert hat.

Sie sollten auch Hilfe holen, wenn Sie vermuten, dass der Repository-Verlauf manipuliert wurde. Die Sicherung von Beweisen kann wichtiger sein als eine schnelle Bereinigung, insbesondere in einer Unternehmensumgebung.

Die Sicherung von Git-Repositories läuft auf diszipliniertes Vertrauen hinaus. Halten Sie Geheimnisse fern, beschränken Sie den Zugriff, schützen Sie wichtige Branches und überprüfen Sie nicht vertrauenswürdigen Code, bevor Sie ihn ausführen. Diese Gewohnheiten verhindern die meisten Repository-Sicherheitsprobleme, bevor sie zu Vorfällen werden.