Vibe coding och säkerhet: När AI skriver koden ingen granskar

I cybersäkerhetsforum världen över syns samma mönster: inlägg efter inlägg med rubriken "I built a security tool" — följt av en demo av en applikation som uppenbart genererats av AI på en eftermiddag. Communityt har fått nog. Frustrationen har blivit så utbredd att moderatorer ombeds skapa en "Built with AI"-flair, så att erfarna säkerhetsingenjörer kan filtrera bort floden av halvfärdiga verktyg.

Det låter kanske som intern dramaturgi i ett Redditforum. Men frustrationen pekar på något allvarligare: en generation applikationer som byggs utan att någon förstår koden de innehåller — och som i allt högre grad hanterar känslig data, autentisering och säkerhetskritiska funktioner.

Vad är vibe coding?

Termen myntades i början av 2025 och beskriver en utvecklingsmetod där du skriver en prompt — inte kod. Du ber en AI-modell som Claude, GPT eller Copilot att bygga det du vill ha, accepterar resultatet, och itererar genom att beskriva vad som behöver ändras. Du behöver aldrig läsa koden. Du behöver inte förstå den.

Det demokratiserar mjukvaruutveckling på ett sätt som var otänkbart för fem år sedan. Men det skapar samtidigt ett nytt problem: kod som ingen har granskat, i applikationer som ingen fullt ut förstår, deployed till produktionsmiljöer som hanterar riktiga användare.

Siffrorna som borde oroa alla

Cloud Security Alliance publicerade i mars 2026 en forskningsrapport som spårar sårbarheter direkt till AI-genererad kod. Trenden är tydlig:

■74 bekräftade CVE:er har spårats till AI-kodverktyg under Q1 2026 — 6 i januari, 15 i februari, 35 i mars
■45% av AI-genererad kod introducerar OWASP Top 10-sårbarheter vid testning
■Java presterar sämst med 72% felfrekvens, medan XSS-sårbarheter dök upp i 86% av testade kodexempel
■10x fler säkerhetsfynd — AI-assisterade utvecklare levererar 3-4 gånger snabbare men introducerar säkerhetsproblem tio gånger oftare

Georgia Tech-forskare uppskattar att det verkliga antalet AI-introducerade sårbarheter är 5 till 10 gånger högre än vad som detekteras — mellan 400 och 700 fall bara i det öppna ekosystemet.

Moltbook: Tre dagar från lansering till katastrof

Det mest talande exemplet hittills är Moltbook. Plattformen lanserades den 28 januari 2026 som ett AI-drivet socialt nätverk. Grundaren gick ut offentligt och sa att han "inte skrev en enda rad kod" — allt var AI-genererat.

Inom tre dagar hade säkerhetsforskare hittat att hela produktionsdatabasen var exponerad, inklusive 1,5 miljoner API-autentiseringsnycklar. Ingen hade granskat koden. Ingen hade testat autentiseringslogiken. Ingen hade ens tittat.

Det är inte ett isolerat fall. Escape.tech skannade 1 400 vibe-kodade applikationer och hittade 2 038 kritiska sårbarheter, 400+ läckta hemligheter och 175 fall av exponerad persondata.

Slopsquatting — en ny attackvektor

Här blir det riktigt oroande. Cirka 20% av AI-genererade kodexempel refererar till paket som inte existerar — så kallade hallucinerade beroenden. Det är inte bara en bugg. Det är en attackyta.

Angripare har börjat registrera de paketnamn som AI-modeller hallucinerar, och fylla dem med skadlig kod. Tekniken kallas slopsquatting och fungerar eftersom 43% av hallucinerade paketnamn upprepas konsekvent — samma modell föreslår samma falska paket om och om igen. En utvecklare som litar på AI:ns förslag installerar ett paket som ser legitimt ut men i själva verket exfiltrerar data eller öppnar en bakdörr.

Det är supply chain-attacker automatiserade av ofrivilliga AI-assistenter.

Varför communityt reagerar

Tillbaka i cybersäkerhetsforum handlar frustrationen om mer än bara dålig kod. Det handlar om att AI sänker tröskeln för att bygga säkerhetsverktyg till en punkt där verktygen själva blir en risk.

En erfaren säkerhetsingenjör beskrev det så här: "Problemet är inte att folk bygger verktyg. Problemet är att de bygger säkerhetsverktyg som de inte förstår, som hanterar autentisering de inte kan förklara, med beroenden de aldrig verifierat — och sedan marknadsför dem som om de löste ett verkligt problem."

Säkerhetsverktyg kräver en grundläggande förståelse för hotmodeller, autentiseringsflöden och kryptografi. En sårbarhetsskanner som flaggar allt är värdelös i skala — den dränker granskare i brus, vilket är precis det som sänkte curls bug bounty-program när AI-genererade rapporter översvämade kön.

Den svenska dimensionen

Sverige har en snabbt växande startup-kultur och en tradition av att tidigt anamma ny teknik. Det gör oss särskilt exponerade för vibe coding-risker.

NIS2-direktivet, som trädde i kraft 15 januari 2026, ställer explicita krav på supply chain-säkerhet för organisationer i 18 sektorer. Vibe-kodade komponenter som hamnar i produktionsmiljöer utan granskning riskerar att direkt bryta mot dessa krav — med sanktioner upp till 2% av global omsättning.

IMY har redan flaggat att AI-genererade system som hanterar personuppgifter kräver samma GDPR-efterlevnad som manuellt utvecklade system. Det innebär konsekvensbedömningar, dokumentation av dataflöden och bevisad säkerhet — inte "AI byggde det och det verkar fungera".

AI-verktygens egen säkerhet

Det finns ytterligare en dimension som ofta förbises: AI-kodverktygen själva har blivit attackytor.

■Amazon Q (CVE-2025-8217): Prompt injection via komprometterade GitHub-repositorier kunde styra AI:ns kodgenerering
■Cursor (CVE-2025-54135): Remote code execution via Slack MCP-server — angripare kunde exekvera godtycklig kod genom att manipulera AI-verktygets integrationer
■Rules File Backdoor: Dolda Unicode-tecken i konfigurationsfiler som styr AI att infoga skadlig kod — osynligt för utvecklaren

Det innebär att även utvecklare som granskar AI-genererad kod kan bli komprometterade av verktyget de använder för att generera den.

Vad som faktiskt fungerar

Lösningen är inte att sluta använda AI för kodning. Det tåget har gått — 77% av organisationer använder redan generativ AI i sin teknikstack. Men det krävs rutiner som matchar tempot.

■Behandla AI-kod som opålitlig input. Varje AI-genererad ändring bör valideras innan den mergas — precis som extern kod från en okänd bidragsgivare
■Begränsa AI på kritiska områden. Autentisering, auktorisering och kryptografi bör ha explicita restriktioner mot oövervakad AI-assistans
■Verifiera beroenden. Kör SBOM-analys (Software Bill of Materials) för att fånga hallucinerade paket innan de installeras
■Skifta säkerhetstestning åt vänster. Integrera SAST och DAST direkt i AI-assisterade arbetsflöden — inte som en eftertanke i CI/CD-pipelinen
■Granska AI-verktygen själva. Vilka integrationer har de? Vilken data exponeras? Har konfigurationsfilerna validerats mot manipulation?

Den verkliga risken

Den verkliga risken med vibe coding är inte att AI skriver osäker kod — det gör mänskliga utvecklare också. Risken är att människor skeppar kod de aldrig hade en chans att säkra. Automationsbekvämlighet sätter in: efter att AI har haft rätt tillräckligt många gånger slutar människor att kontrollera.

I en värld där säkerhetsteam redan är överbelastade, och där angripare skalar snabbare med hjälp av samma teknik, har vi inte råd med den typen av tillit.

Cybersäkerhetscommunityt har rätt i sin frustration. En "Built with AI"-flair är inte en lösning — men det är en signal. Det säger: vi behöver veta hur den här koden skapades, för det påverkar hur mycket vi kan lita på den.

Artikeln bygger på data från Cloud Security Alliance Vibe Security Radar (mars 2026), Veracode AI Code Security Report, Georgia Tech-forskning om AI-genererade sårbarheter, Escape.tech:s scanning av vibe-kodade applikationer samt diskussioner i cybersäkerhetspraktikerforum.

Läs mer om hur AI påverkar säkerhetsteamens arbete, vår guide till incidenthantering vid cyberattack och hur du bygger en säkerhetskultur som fångar risker tidigt.