Behandla en ärvd, AI-byggd kodbas som läckt tills du har kontrollerat motsatsen. Sök systematiskt på fyra ställen — källkod, commithistorik, byggd frontend och loggar — inte bara i de filer som ligger där idag. Avgör för varje fynd om det måste roteras hos leverantören, inte bara tas bort ur koden. Sätt sedan upp en enkel spärr så att nästa läcka stoppas innan den committas, inte upptäcks av nästa person som tar över.
Varför AI-byggd kod läcker oftare än handskriven
Det är inte att modellen är slarvig med säkerhet i något generellt avseende. Det är att den snabbaste vägen till "det fungerar" ofta går genom att skriva in ett värde direkt i stället för att koppla upp en konfiguration som inte finns än. Frågar du en assistent att "koppla in Stripe" mitt i ett vibecodingflöde, är hårdkodning av testnyckeln en fullt rimlig genväg för att komma vidare — särskilt om ingen bett om något annat.
Lägg till att ett nytt projekt sällan har en .gitignore på plats innan den första commiten. En .env-fil med riktiga nycklar hinner ofta committas innan någon tänker på att den inte ska vara med. Filen tas bort i nästa commit — men historiken minns.
"Jag tog bort filen, så den är borta." Git tar inte bort något som redan committats — det lägger till en ny commit som råkar sakna filen. Varje tidigare version, inklusive den med nyckeln i klartext, finns kvar i historiken och är lika lätt att hämta ut som den senaste.
De fyra vanligaste läckageplatserna
.env.gitignore fanns. Även om den senare togs bort finns den kvar i historiken.Sök i den ordningen, inte bara en gång
En sökning i dagens filer räcker inte. Gå igenom platserna i tur och ordning, eftersom var och en hittar sådant de andra missar.
key, secret, token och password nära en tilldelning. Öppna varje träff och avgör om det är ett riktigt värde eller en platshållare.Sök brett, verifiera smalt
- Sök efter mönster, inte bara efter kända varumärkesnamn — en nyckel avslöjar sig sällan genom att stava ut vilken tjänst den hör till.
- Ett verktyg med filåtkomst och historiksökning hittar mer än en genomläsning för hand, men du behöver fortfarande öppna varje träff själv.
- Skilj tydligt på testnycklar och produktionsnycklar i resultatet — de kräver olika brådska, inte samma reaktion.
Ett fynd är inte klart förrän det är roterat
Att ta bort en hårdkodad nyckel ur koden stoppar nästa läsare, inte den som redan sett den. Om kodbasen någonsin delats, legat i ett verktyg med extern lagring, eller bara existerat länge nog för att du inte kan garantera vem som haft åtkomst, är den enda säkra åtgärden att byta ut nyckeln hos leverantören.
Att skriva om commithistoriken för att ta bort en läckt hemlighet är möjligt men stör alla andra som arbetar mot samma repo och kräver att alla synkar om från grunden. Rotera nyckeln först — det gör historiken ofarlig även om den innehåller den gamla strängen. Skriv bara om historiken om repot ska bli offentligt eller om policyn kräver det.
Prompten som ber om en genomsökning
Be om en lista att kontrollera, inte om en försäkran om att allt är rent. En modell som får en vag fråga om säkerhet svarar gärna med en lugnande sammanfattning; en modell som får en konkret sökuppgift levererar träffar du själv kan verifiera.
Sök igenom hela repot, inklusive commithistoriken, efter möjliga hemligheter: API-nycklar, lösenord, tokens och anslutningssträngar med inloggningsuppgifter.
Leta efter långa slumpmässiga strängar nära ord som key, secret, token, password eller connectionstring, och efter kända prefixmönster från vanliga tjänster.
Lista varje träff med fil, radnummer (eller commit-hash om det bara finns i historiken) och det omgivande sammanhanget. Gissa inte om något är en platshållare — visa raden och låt mig avgöra.
Kontrollera separat om projektet bygger en frontend: sök i den byggda utdatan för tecken på att en server-nyckel följer med till klienten.
Sätt upp spärren innan du glömmer
Den här genomgången är en engångsstädning om inget hindrar nästa hemlighet från att committas. Lägg in en kontroll som körs automatiskt före varje commit eller i CI, som stoppar en push innan en nyckel når historiken över huvud taget. Det behöver inte vara sofistikerat — ett mönstermatchande skript som kör i samma steg som dina andra kontroller före merge räcker långt. CI-artikeln går igenom hur du binder in stoppregler av det här slaget.
Om ett värde skulle vara pinsamt eller farligt om det låg i en offentlig sökmotor imorgon, hör det inte hemma i källkoden — varken hårdkodat, i en committad .env, eller i en byggd frontend. Miljövariabler lästa vid körning, aldrig skrivna till disk i repot, är standardvägen.