Säkerhetsgranskning av AI-applikationer: OWASP LLM Top 10

När ett bolag bygger en AI-funktion på en språkmodell uppstår en attackyta som klassiska säkerhetsgranskningar inte fångar. En vanlig kodgranskning letar efter SQL-injektion och trasig autentisering; den letar inte efter att en användare kan manipulera modellens instruktioner via en till synes oskyldig prompt. OWASP LLM Top 10 är den lista som satte ord på de här riskerna, och den har snabbt blivit referensramverket för att granska AI-applikationer.

Den här genomgången går igenom de viktigaste kategorierna och vad de betyder i praktiken. Jag granskar AI-applikationer mot det här ramverket inom cybersäkerhet, och poängen är alltid densamma: AI-säkerhet är ett tillägg till, inte en ersättning för, vanlig applikationssäkerhet. Det som gör AI-applikationer kluriga är att gränsen mellan kod och data suddas ut. I ett traditionellt system är instruktioner (kod) och indata (data) tydligt åtskilda. I en språkmodell är instruktionen text, och indatan är text, och modellen behandlar i grunden allt som samma ström av ord. Det är ur den sammanblandningen de flesta nya riskerna uppstår.

Varför OWASP LLM Top 10 behövdes

OWASP har länge gett ut sin klassiska Top 10 för webbapplikationer, och den har format hur en hel bransch tänker kring säkerhet. När generativ AI exploderade saknades motsvarande gemensamma språk för de nya riskerna, och resultatet blev att varje team uppfann sina egna farhågor. OWASP LLM Top 10 fyller det tomrummet: den ger team, granskare och beställare ett gemensamt vokabulär för att prata om vad som faktiskt kan gå fel i en LLM-applikation. Det praktiska värdet är inte att listan är fullständig, den utvecklas, utan att den ger en strukturerad utgångspunkt så att granskningen blir systematisk istället för en samling lösa magkänslor.

Prompt injection, den nya injektionsattacken

Prompt injection är listans mest omtalade risk och den svåraste att helt eliminera. Angriparen smyger in instruktioner som modellen tolkar som legitima, antingen direkt i sin egen input eller indirekt via innehåll modellen läser, som ett dokument eller en webbsida i ett RAG-flöde. Resultatet kan bli att modellen kringgår sina skyddsinstruktioner eller läcker information. Försvaret är lager på lager: tydlig separation mellan systeminstruktioner och användardata, validering av output, och minsta möjliga behörighet för det modellen får göra.

Känsligt informationsläckage

Modeller kan oavsiktligt återge känslig information, antingen från sin träningsdata eller från kontext de matats med. I RAG-system är den vanligaste varianten att modellen får tillgång till dokument användaren egentligen inte har behörighet till. Försvaret är att åtkomstkontroll sker innan retrieval, inte att man förlitar sig på att modellen själv ska hålla tyst.

Supply chain och osäkra plugins

AI-applikationer hänger ihop med modeller, bibliotek, vektordatabaser och ofta verktyg eller plugins som modellen får anropa. Varje sådan komponent är en potentiell svaghet. Ger ni modellen tillgång till verktyg som kan utföra åtgärder, måste varje verktyg behandlas som en privilegierad operation med egen behörighetskontroll. Här går AI-säkerhet ihop med klassisk sårbarhetshantering, som jag beskriver i SBOM med Syft och Grype.

Överdrivet handlingsutrymme och osäker output

Två återkommande misstag hänger ihop. Det första är att ge modellen för mycket handlingsutrymme, låta den utföra åtgärder med vidare behörighet än uppgiften kräver. Det andra är att lita på modellens output utan validering, exempelvis köra genererad kod eller mata genererad text rakt in i ett annat system. Behandla alltid modellens svar som otillförlitlig input som ska valideras innan den används.

Här gör jag mid-vägs alltid samma övning: kartlägger vad modellen faktiskt kan röra vid, vilka behörigheter den har och var dess output hamnar. Den kartan avslöjar nästan alltid mer handlingsutrymme än någon avsett. Vill ni ha den gjord ingår det i cybersäkerhetsuppdraget.

Så granskar jag en AI-applikation

• Kartlägg dataflödet, vad matas in, vad modellen läser, vart svaret går.
• Testa prompt injection både direkt och indirekt via dokument i RAG-kedjan.
• Verifiera åtkomstkontroll i retrieval-steget, inte bara i applikationen runt omkring.
• Granska verktyg och plugins som modellen får anropa, var och en som en privilegierad operation.
• Validera output-hantering, körs eller vidarebefordras något ovaliderat?

Att bygga in säkerhet från start istället för att granska efteråt

En granskning är värdefull, men den bästa investeringen är att bygga rätt från början. Konkret betyder det några vanor som kostar lite men sparar mycket: separera systeminstruktioner från användarinnehåll så tydligt arkitekturen tillåter, ge modellen minsta möjliga behörighet och tillgång, validera allt som kommer ut innan det används, och logga modellens in- och utdata så att ni kan utreda i efterhand. Team som har de vanorna på plats klarar en granskning betydligt bättre, helt enkelt för att de redan tänkt igenom var det kan brista. AI-säkerhet är till sin natur ett rörligt mål, eftersom både modeller och angreppstekniker utvecklas snabbt, och då är inbyggda principer mer hållbara än punktinsatser.

Var jag brukar börja

Börja med dataflödeskartan och behörigheterna. De flesta allvarliga AI-säkerhetsbrister jag hittar handlar inte om exotiska modellattacker, utan om att modellen getts för stort handlingsutrymme eller åtkomst till data den inte borde se. Det är vanlig god säkerhetshygien, applicerad på ett nytt slags system. När kartan finns blir det dessutom lätt att se vilka av OWASP-kategorierna som faktiskt är relevanta för just er applikation, alla tio är sällan lika viktiga, och en bra granskning prioriterar efter er verkliga arkitektur. Se hur jag lägger upp granskningar i kundcase.

Relaterat

• DORA för fintech: Operativ resiliens, ICT-risk och tredjepartshantering
• Zero Trust-arkitektur för SMB: Praktisk implementation på 30 dagar
• Cloudflare Zero Trust för SMB: Ersätt VPN på en eftermiddag

Vill du ta det vidare?

Jag granskar AI-applikationer mot OWASP LLM Top 10 och hjälper team att bygga säkrare från start. Boka ett samtal så går vi igenom er applikation.