Hvorfor avslører git log hemmeligheter selv etter at de er «slettet»
Slette en linje fra en fil og commitÅ gjøre endringen fjerner ikke de sensitive dataene fra depotet ditt. Hvis den hemmeligheten, en API-nøkkel, legitimasjon eller token, noen gang ble committed, den ligger i Git-historikken din. Alle som kjører git logg -p, git -show, eller inspisere differanser fra tidligere commits kan fortsatt hente den.
Selv om du overskriver en fil eller erstatter verdien, git logg bevarer hele arvlinjen til hver endring. Dette er utformet. Hele Gits modell er basert på uforanderlige commit historie og distribuerte kopier. Så med mindre du eksplisitt omskriver historien, er hemmelighetene dine fortsatt der. Her er et praktisk tilfelle:
git commit -m "Added config with AWS_SECRET_KEY"
# Realize mistake
git rm config.json
git commit -m "Removed secret file"
⚠️ Pedagogisk eksempel, ikke kjør i produksjon
For sent. Det git logg viser fortsatt den tasten i den første commit.
Misoppfatninger rundt git stash og git rebase
Mange utviklere antar git stash hjelper med å skjule eller oppklare hemmeligheter. Ikke sant. git stash bare hyller arbeidskatalog endres midlertidig; den berører aldri commit historie. Hvis en hemmelighet noen gang var committed, å lagre endringer etterpå gjør ingenting for å rense det.
Hva med git rebaseSelv om det kan omskrive historien, må det gjøres førcisely. Bare løper git rebase -i og ombestilling eller squashing commits fjerner ikke hemmeligheter med mindre du eksplisitt redigerer eller sletter dem. Og hvis bare én klon eller fork finnes med originalen commits, hemmeligheten din lever videre.
Enda verre er det at rebasing uten riktig tvangspressing eller på nytt koordinering med samarbeidspartnere kan introdusere de eksponerte legitimasjonene på nytt via sammenslåinger.
git commit -m "Added config with AWS_SECRET_KEY"
⚠️ Pedagogisk eksempel, ikke bruk i virkelige miljøer
git rebase -i HEAD~3
⚠️ Pedagogisk eksempel, ikke kjør på produksjonsrepoer
Redigere commit inneholder hemmeligheten, men glemmer å fjerne den. Din git logg kunne se renere, men det sensitive innholdet kan fortsatt gjenopprettes.
Risikoer i den virkelige verden fra glemte legitimasjonsdetaljer i Git-historikken
Dette er ikke teoretisk. Angripere skanner aktivt offentlige og private lagre for hemmeligheter som skjuler seg i dem. commit historikk. GitHub-forker, speilepoeng og mellomlagrede CI/CD pipelines kan alle huse de glemte tokensene.
- En lekket API-nøkkel fra en gammel git logg førte til tusenvis i skyfakturering for én oppstartsbedrift.
- OAuth-tokener committed, deretter «slettet», ble brukt til å kapre brukerkontoer.
- Hemmeligheter begravd dypt i gafler av åpen kildekode-prosjekter utløste store sikkerhetshendelser.
Disse problemene skaleres inn i CI/CDHver jobb som kloner et repo kjører git logg under panseret, og alle byggeartefakter kan potensielt inneholde spor av avslørte hemmeligheter.
Rydde opp i sensitive data med git filter-repo
Hvis skaden er skjedd, er det mest pålitelige verktøyet for å rengjøre den git filter-repo. I motsetning til git rebase, som omskriver individuelt commits, git filter-repo kan skrive om hele commit historikk basert på filstier, mønstre eller innhold.
Eksempel: å skrubbe alle forekomster av config.json som kan inneholde hemmeligheter:
pip install git-filter-repo
# Backup your repo first
cp -r my-repo my-repo-backup
cd my-repo
git filter-repo --path config.json --invert-paths
⚠️ Pedagogisk eksempel, verifiser i et testlager før bruk i produksjon
Eller å fjerne alle commitsom inkluderer en spesifikk streng (f.eks. AWS_SECRET_ACCESS_KEY):
git filter-repo --replace-text <(echo 'AWS_SECRET_ACCESS_KEY==REDACTED')
⚠️ Pedagogisk eksempel, verifiser i et testlager før bruk i produksjon
Vær forsiktig: Dette vil skrives om commit hasher. Du må tvinge frem sendingen og informere alle samarbeidspartnere. Eventuelle automatiserings- eller distribusjonsnøkler knyttet til commit hasher vil bryte sammen.
Også verktøy som BFG Repo-Cleaner tilbyr lignende funksjoner, men er mindre fleksible og anses nå som utdaterte for komplekse saker.
Forebygging av hemmelige lekkasjer før de når Git
Forebygging er bedre enn opprydding. Slik hindrer du hemmeligheter i å dukke opp git logg:
1. Pre-commit Hooks
Bruk verktøy som pre-commit, gitleakseller talisman å skanne etter hemmeligheter før commits:
# .pre-commit-config.yaml
- repo: https://github.com/zricethezav/gitleaks
rev: v8.15.0
hooks:
- id: gitleaks
2. CI/CD Pipeline Enforcement
Integrere hemmelig deteksjon inn i CI-jobbene dine. Mislykkede bygg når hemmeligheter blir funnet. Gjør dette til en policy.
3. Hemmelighetshåndtering
Aldri hardkode legitimasjon. Bruk miljøvariabler, hvelv eller hemmelige administratorer fra dag én.
4. Revisjonsavhengigheter
Ikke stol blindt på tredjepartspakker. Hemmeligheter kan lekke gjennom npm-, PyPI- eller Docker-lag.
Endelig løsning: Skrubbehemmeligheter med git filter-repo
Det er ikke nok å slette hemmeligheter fra kode. git logg holder en fullstendig oversikt med mindre du bevisst tar grep for å omskrive historien. Ikke stol på git stash eller halvferdig git rebase forsøk. Bruk git filter-repo når du trenger en grundig opprydding, og håndhever retningslinjer og skanning før hemmeligheter når depotet ditt i utgangspunktet.
For proaktiv hemmelighetsdeteksjon, vurder å bruke verktøy som Xygeni for å sikre deg pipelines, håndheve commit hygiene og forhindre kostbare lekkasjer før de kommer til overflaten. Git glemmer aldri, men du kan sørge for at den aldri husker hemmelighetene dine i utgangspunktet.
