1000 tals Vibe coding appar läcker företagshemligheter

Tänk dig att din kollega Kalle bestämde sig för att bygga en intern app med hjälp av AI. Inga konstigheter, tyckte han. Han beskrev vad han ville ha i ett textfält, AI:n fixade resten, och Kalle klickade på publicera med ett nöjt leende. Det Kalle inte visste var att han precis lade ut företagets kundlistor, finansiella dokument och strategiplaner som en digital självservice-buffé för hela internet. Välkommen till vibe codingens guldålder och dess mardrömslika baksida.

Snabbfakta

🤖 Vad är vibe coding? Att bygga appar med AI och enkla textkommandon utan att skriva kod själv
🔓 Hur många appar? Över 5 000 appar utan grundläggande säkerhetsskydd hittades
📊 Känslig data? Cirka 40 procent av apparna innehöll känslig information
🏢 Vilka plattformar? Lovable, Replit, Base44 och Netlify granskades
🔍 Vem hittade det? Säkerhetsforskaren Dor Zvi och cybersäkerhetsföretaget Redaccess
⚠️ Plattformarnas svar? Ansvaret ligger hos användarna

Så hittade forskarna 5 000 appar med öppen dörr

Säkerhetsforskaren Dor Zvi och cybersäkerhetsföretaget Redaccess granskade appar skapade med AI-verktyg som Lovable, Replit, Base44 och Netlify. Resultatet var nedslående: totalt hittades 380 000 publikt tillgängliga resurser byggda med dessa verktyg, varav drygt 5 000 saknade grundläggande säkerhetsskydd eller autentisering och innehöll känslig företagsdata.

Det är ungefär som att låsa upp 5 000 arkivrum och sätta upp en skylt med texten “välkommen in, ta vad du vill.”

Bland de exponerade apparna hittades ett system för ett shippingbolag som visade vilka fartyg som förväntades anlöpa vilka hamnar, samt en intern applikation för ett brittiskt hälsoföretag med detaljer om pågående kliniska prövningar. Inte precis information man vill ha indexerad av sökmotorer.

Hur kan det här problemet uppstå?

Problemet är delvis inbyggt i verktygens design. Integritetsinställningarna på flera vibe-kodningsverktyg är som standard inställda på publikt läge, och ändras bara om användaren aktivt väljer att göra appen privat. Många av apparna är dessutom indexerade av sökmotorer, vilket gör det möjligt för i princip vem som helst att snubbla in på dem utan att ens leta aktivt.

En känd teknisk risk är att AI placerar känslig logik i fel del av koden. Autentisering, API-nycklar och beräkningar som egentligen ska ligga i backend hamnar i frontend, vilket öppnar dörren för säkerhetsluckor som är svåra att upptäcka för den som inte har teknisk bakgrund.

Vibe coding har väckt oro kring förståelse och ansvarsskyldighet. Användare kan använda AI-genererad kod utan att förstå hur den fungerar, vilket leder till oupptäckta buggar, fel eller säkerhetsbrister som sedan lever vidare i tyst harmoni med resten av verksamheten.

Plattformarna skyller på användarna

Det uppenbara följdfrågan är förstås vad verktygen själva säger om detta. Svaret är ungefär vad man kan förvänta sig av ett teknikbolag som hellre talar om empowerment än om ansvar.

Lovables talesperson meddelade att plattformen ger utvecklare verktygen för att bygga säkert, men att hur en app konfigureras i slutändan är skaparnas eget ansvar. Replit-chefen å sin sida påpekade att publika appar som är tillgängliga på internet är förväntat beteende, och att integritetsinställningarna kan ändras med ett klick.

Det är en klassisk ansvarsförskjutning som branschen är mästare på. Verktyget ger kraften, du har ansvaret. Tyvärr fungerar den logiken ungefär lika bra som att sälja laddade vapen och sedan hänvisa till bruksanvisningen.

Det är ett styrelse/ledningsgruppsproblem, inte ett renodlat IT-problem

Här är den obehagliga sanningen som många organisationer helst inte vill höra: det här är inte ett problem som IT-avdelningen kan lösa på egen hand. Det är ett ledningsproblem, och i förlängningen ett styrelseproblem.

Redaccess hittade apparna när de undersökte så kallad shadow AI, det vill säga anställdas obehöriga användning av AI-verktyg. Anställda testar verktyg på egen hand, skapar appar med känslig data, och ingen i ledningen vet om det. Ingen har frågat. Ingen har skapat en policy. Ingen har ens definierat vad som räknas som känslig information i det här sammanhanget.

Viktiga frågor som organisationer måste hantera är bland annat vad som delas med AI-verktygen, hur data lagras, vem som ansvarar, hur man bedömer kvaliteten och säkerheten i AI-genererad kod och vem som äger koden när appen väl är byggd.

Styrelsen måste börja ställa dessa frågor. Inte en gång per år i en riskrapport, utan löpande, som en naturlig del av hur verksamheten styrs. Annars är det Kalle som bestämmer, och Kalle tycker att allt verkar gå bra.

Vad som krävs av ledningar nu

Det räcker inte med att förlita sig på att anställda läser en manual om integritetsinställningar. Organisationer behöver en tydlig AI-policy som faktiskt tillämpas, inte bara existerar i ett dokument som ingen hittar.

För att bygga något som ska hålla över tid krävs att koden exporteras till Git, att känslig logik ligger på en server man kontrollerar och att det finns rutiner för säkerhet, backup och drift. Det låter tråkigt. Det är också precis det som skiljer ett ansvarsfullt företag från ett som läser om sig själv i tidningen.

Konkret innebär det att styrelser och ledningsgrupper behöver definiera vilka typer av data som aldrig får hanteras i externa AI-verktyg utan godkännande, kräva att alla AI-byggda applikationer granskas av någon med teknisk kompetens innan publicering, skapa tydliga rapporteringsvägar för shadow AI så att anställda vet var gränsen går, följa upp efterlevnad som en del av ordinarie internkontroll och säkerställa att NIS 2 och GDPR-perspektiv är en del av varje AI-relaterat beslut.

“Lovable ger utvecklare verktygen för att bygga säkert, men hur en app konfigureras är i slutändan skaparnas ansvar.” — Talesperson för Lovable

Vad ledningen behöver hantera omgående:

• Kartlägg vilka AI-verktyg som faktiskt används i organisationen inklusive de ingen frågat om
• Inför godkännandeprocess för externa AI-verktyg som hanterar intern data
• Utbilda chefer och mellanchefer om riskerna med okontrollerad AI-användning
• Ställ krav på leverantörer att EU-anpassad lagring och tydliga databehandlingsavtal finns på plats
• Behandla vibe-kodade appar som alla andra affärssystem med krav på dokumentation och säkerhetsgranskning

Fördelar med vibe coding Snabb prototyping utan kodkunskaper Låg tröskel för innovation i organisationen Kostnadseffektivt för enklare interna verktyg Demokratiserar apputveckling

Nackdelar med vibe coding Säkerhetsinställningar är publika som standard Känslig logik hamnar ofta fel i koden Ingen garanti för GDPR eller NIS 2-efterlevnad Ansvaret läggs på användaren av plattformen

FAQ

Vad är vibe coding? Vibe coding innebär att man bygger appar genom att beskriva vad man vill ha i ett textfält, varefter AI genererar koden automatiskt. Verktyg som Lovable, Replit och Base44 är exempel på sådana plattformar.

Hur kan företagsdata hamna publikt? Många vibe-kodningsverktyg har publikt läge som standardinställning. Om användaren inte aktivt ändrar till privat läge är appen tillgänglig för alla med länken och ofta även indexerad av sökmotorer.

Vems ansvar är det? Juridiskt och regulatoriskt sett är det alltid den organisation som behandlar data som bär ansvaret, oavsett vilket verktyg som använts. Plattformarnas argument om att ansvaret ligger hos användaren fritar inte företaget från GDPR-ansvar.

Vad bör styrelsen göra? Styrelsen bör kräva en inventering av vilka AI-verktyg som används, etablera en tydlig policy och behandla shadow AI som en del av den ordinarie riskhanteringen, inte som ett IT-tekniskt sidoproblem.

Påverkar detta svenska företag? Ja. Lovable är ett svenskt bolag och svenska företag använder dessa verktyg flitigt. GDPR ställer hårda krav på hur personuppgifter hanteras och exponerade appar är sannolikt en direkt regelöverträdelse.

Källor

https://computersweden.se/article/4168886/tusentals-vibe-kodade-appar-exponerar-kansliga-foretagsdata.html