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

Kort samengevat: Een gelekte API-sleutel die is gecommit naar een repo blijft nog lang in de geschiedenis staan nadat het bestand is verwijderd. Detectie, rotatie en het herschrijven van de geschiedenis zijn allemaal nodig — verwijdering alleen geeft een vals gevoel van veiligheid.

De verwijder-en-commit-valkuil

Wanneer een ontwikkelaar een gecommitte credential opmerkt, is het instinct om de regel te verwijderen en een fix te pushen. Maar het geheim staat nog steeds in de git-geschiedenis, op te halen door iedereen met clone-toegang. Als de repo ooit publiek is geweest of gespiegeld is, ga er dan van uit dat het geheim gecompromitteerd is vanaf het moment dat het werd gepusht.

De enige veilige aanname is dat een gelekt geheim een actief geheim is totdat het wordt geroteerd.

De echte volgorde van herstel

• Roteer de credential onmiddellijk — behandel het als een inbreuk, niet slechts als blootstelling.
• Trek in en controleer op elk gebruik van de gelekte sleutel tijdens het blootstellingsvenster.
• Herschrijf de geschiedenis om het geheim uit alle bereikbare commits te wissen en forceer een refresh van mirrors.
• Voeg pre-commit- en CI-scans op geheimen toe zodat het volgende geheim wordt opgevangen voordat het landt.

Detectie moet continu zijn

Gelekte geheimen zijn geen eenmalige opschoning; het is een doorlopend detectieprobleem. Alleen scannen op commit-moment mist geheimen die via andere paden worden gepusht, en alleen historisch scannen mist de fout van morgen. Beide zijn belangrijk.

De scans van KENSAI brengen blootgestelde credentials aan het licht met de context die nodig is om rotatie te prioriteren — welke sleutel, waar deze bereikbaar is en hoe urgent de blootstelling is.

Hoe goede hygiëne er in de praktijk uitziet

Behandel elk geheim dat ooit een repository heeft aangeraakt als reeds blootgesteld, en ontwerp zo dat blootstelling te overleven is. Kortlevende, automatisch geroteerde credentials maken van een gelekte sleutel een probleem dat vanzelf verloopt in plaats van een open deur die maandenlang openblijft.

Verplaats detectie naar links met pre-commit- en pre-receive-hooks die een geheim blokkeren voordat het ooit wordt vastgelegd, en combineer dat met server-side scanning die opvangt wat er doorheen glipt. Het doel is geen eenmalige opschoning maar een blijvende controle die nieuwe lekken zeldzaam, luid en snel intrekbaar maakt.

Conclusie

Het verwijderen van een gelekt geheim is de minst belangrijke stap. Roteer eerst, wis daarna de geschiedenis, en zet continue detectie op zodat blootstellingsvensters krimpen in plaats van zich te herhalen.