Artikel Granskning

Säkerhetsgranska en AI-kodbas

Att ärva kod som är skriven av AI kräver ett annat fokus än vid vanlig kodgranskning. Modellen introducerar inte avsiktliga bakdörrar, men den väljer ofta minsta motståndets lag — vilket leder till autentiseringar som accepterar allt, hallucinerade beroenden och loggar som läcker personuppgifter.

Senast granskad: 7 aug 2026

En abstrakt apliknande profil byggd av lysande nätverksnoder svävar intill en mörk metallpanel med en glasskiva, där grönt ljus lyser fram i springan. En tunn ljustråd går från profilen till panelens kant.
Säkerhetsgranskning av en ärvd kodbas handlar om att hitta de tysta missarna innan koden når produktion.

Kort sagt

AI-genererad kod lider ofta av tre specifika typer av tysta säkerhetsmissar. Autentisering och auktorisering hanteras med "happy path"-logik som saknar validering av utgångna tokens eller behörighetsnivåer. Tredjepartsberoenden kan vara utdaterade eller i värsta fall helt hallucinerade (vilket öppnar för supply chain-attacker). Och loggningen innehåller ofta hela request-objektet, vilket spiller lösenord och API-nycklar rakt ner i dina felloggar.

Minsta motståndets säkerhet

När en AI bygger en funktion från grunden optimerar den för att få koden att fungera och passera eventuella enhetstester. Den optimerar inte för att hantera illvilliga indata om du inte uttryckligen ber den bygga defensivt. Det betyder att säkerhetsmekanismerna ofta reduceras till papperskonstruktioner: en JWT-validering kontrollerar formatet men inte signaturen; ett filuppladdningsskript kollar filändelsen men inte filens faktiska innehåll.

Det här är inte "buggar" i klassisk mening, eftersom koden gör precis det den ombeds göra för en vanlig, välmenande användare. Men i produktion räcker inte "happy path".


De tre vanligaste sårbarheterna

Naiv autentisering
JWT-tokens vars utgångsdatum ignoreras, felaktig hantering av refresh-tokens, eller middleware som returnerar oavsett roll. Koden kollar "Är användaren inloggad?" men inte "Får användaren se just den här resursen?"
Skumma beroenden
Ofta föreslår AI utdaterade bibliotek (som var standard vid dess tränings-cutoff) eller rent hallucinerade paketnamn. En angripare kan registrera ett hallucinerat paketnamn på NPM och köra skadlig kod på din server.
Överdriven loggning
"console.log(request.body)" är AI:ns favoritmetod för felsökning. I produktion innebär det att användares lösenord, PII och till och med autentiseringstokens hamnar i klartext i Splunk eller Datadog.

Checklistan för granskning

Innan du driftsätter en AI-genererad kodbas som någon annan startat, måste du göra ett aktivt övertagande. Här är vad du bör systematiskt kontrollera:

1
Granska auktoriseringen. Sök på filnivå efter verify, auth och route-handlers. Saknas rollvalidering? Valideras signaturen på tokens, eller dekodas de bara? Om en klient ändrar sitt ID i requesten, tillåter databasfrågan det utan att korskolla mot inloggad session?
2
Rensa och lås beroenden. Öppna package.json, requirements.txt eller pom.xml. Kör ett verktyg som npm audit eller motsvarande. Slå upp varje okänt paket manuellt för att se att det faktiskt existerar och underhålls.
3
Röj bland loggarna. Sök globalt i projektet efter utskrifter av okontrollerade objekt (som error eller req.body). Byt ut dem mot strukturerad loggning där endast säkra, explicita fält plockas ut och sparas.

Prompten för att assistera granskningen

Du kan använda en AI för att hjälpa dig identifiera var AI:n har tagit genvägar, men du kan inte lita på att en enda, generell "finns det säkerhetsproblem i koden?" kommer att hitta dem. Du måste styra sökningen:

Säkerhetsgranskningsprompt Kodövertagande

Agera som senior säkerhetsexpert. Jag har en kodbas som är AI-genererad och jag behöver identifiera tre specifika risker före produktion.

1. Autentisering och Auktorisering: Hitta all kod som validerar JWT:er eller hanterar inloggning. Finns det platser där vi saknar kontroll av utgångsdatum, där signaturen inte verifieras, eller där vi lider av IDOR (Insecure Direct Object Reference)?

2. Beroenden: Granska min beroendefil. Är några paket kända för att vara föråldrade eller osäkra? Lista dem som verkar otypiska eller potentiellt hallucinerade.

3. Loggläckage: Hitta varje plats där objekt som request, response, error eller user loggas direkt utan filtrering (t.ex. console.log(user)).

Svara med exakt fil och radnummer för varje träff. Ge konkreta förslag på hur vi rättar till dem.


Ingen kod i produktion utan ägare

Att ärva kod som ett LLM spottat ur sig åt någon icke-utvecklare är i slutändan samma process som att ärva kod från ett konsultbolag som lämnat över projektet. Skulden är teknisk, och den är din den sekund den rullar in i drift. Innan du godkänner överlämningen, låt koden passera din egen grind.

Relaterad läsning
Hemligheter i en AI-byggd kodbas: hitta och rotera det som läckt innan du tar över