Secrets verlopen niet wanneer u ze verwijdert: Git-geschiedenis opschonen

Kort samengevat: Een gelekte API-sleutel die in een repository is vastgelegd, blijft lang na het verwijderen van het bestand in de geschiedenis staan. Detectie, rotatie en het herschrijven van de geschiedenis zijn allemaal noodzakelijk; alleen verwijderen geeft schijnveiligheid.

De valkuil van de verwijdercommit

Wanneer een ontwikkelaar een vastgelegde credential ontdekt, is de eerste impuls vaak om de regel te verwijderen en een fix te pushen. Het secret staat echter nog steeds in de Git-geschiedenis en kan door iedereen met clonetoegang worden teruggehaald. Is de repository ooit openbaar geweest of gespiegeld, ga er dan van uit dat het secret gecompromitteerd is vanaf het moment dat het werd gepusht.

De enige veilige aanname is dat een gelekt secret actief blijft totdat het is geroteerd.

De juiste herstelvolgorde

1. Roteer de credential onmiddellijk en behandel deze als geschonden, niet alleen als blootgesteld.
2. Trek de sleutel in en controleer ieder gebruik tijdens het blootstellingsvenster.
3. Herschrijf de geschiedenis om het secret uit alle bereikbare commits te verwijderen en ververs alle mirrors geforceerd.
4. Voeg secret scanning toe aan pre-commit en CI, zodat een volgend lek wordt gestopt voordat het landt.

Detectie moet continu zijn

Secretlekken zijn geen eenmalige opruimactie maar een permanent detectieprobleem. Alleen tijdens commits scannen mist secrets die via andere routes binnenkomen; alleen historische scans missen de fout van morgen. Beide controles zijn nodig.

KENSAI toont blootgestelde credentials met de context die nodig is om rotatie te prioriteren: welke sleutel, waar deze bereikbaar is en hoe urgent de blootstelling is.

Goede hygiëne in de praktijk

Behandel ieder secret dat ooit een repository heeft geraakt als reeds blootgesteld en ontwerp het systeem zo dat die blootstelling overleefbaar is. Kortlevende, automatisch geroteerde credentials veranderen een gelekte sleutel in een probleem dat vanzelf afloopt, in plaats van een deur die maanden open blijft.

Schuif detectie naar voren met pre-commit- en pre-receive-hooks die een secret blokkeren voordat het wordt vastgelegd. Combineer dit met serverscans voor alles wat toch ontsnapt. Het doel is geen eenmalige schoonmaak, maar een vaste controle die nieuwe lekken zeldzaam, luid en snel intrekbaar maakt.

Conclusie

Een gelekt secret verwijderen is de minst belangrijke stap. Roteer eerst, verwijder het daarna uit de geschiedenis en voer continue detectie in om blootstellingsvensters steeds kleiner te maken.