Realitetsugen: AI-kodning støder på sikkerhedsmur

Sidste uge i april 2026 ramte virkeligheden AI-udviklerne hårdt. Vi har skabt stærke værktøjer til kodning, men sikkerheden halter efter. Fem store nyheder og undersøgelser viste et felt fanget mellem hastighed og risici.

De alarmsignalerende tal

Det værste tal rammer som et lyn: 20% af apps bygget med AI-kodningsværktøjer har alvorlige sikkerhedshuller. Det er ikke teori – det kører i produktion nu, ifølge Wiz Research fra Google Cloud Next.

Alvorlige betyder ting som åbne adgangsporte, lækkede data og udsatte adgangskoder i koden. Tusindvis af apps arver fejl fra deres AI-hjælpere.

Værre: 20% kan være for godt til at være sandt. Andre studier peger på endnu lavere niveauer.

Benchmark-sjokket: Kun 23,8%

SecureVibeBench testede 105 kodningsopgaver fra rigtige OSS-Fuzz-sårbarheder. AI'erne skulle løse problemer uden at gentage de gamle CVE-fejl.

Fem AI-agenter kæmpede: OpenHands, Claude Sonnet 4.5 og tre til. Bedste resultat: 23,8% korrekt og sikkert kode.

Det vil sige: 76,2% gav enten brugbar kode, gamle sårbarheder – eller begge dele.

Testene var ærlige med fuzzing og dynamisk analyse. De fandt overflows, bufferfejl og race conditions – ægte CVE-materiale.

Hvorfor det går galt

Ugens nyheder viser et mønster. Wiz integrerer scanning direkte i IDE'en. Red Gate analyserede fem fejltyper i AI-genereret databasekode, med Replit-deletionen som eksempel. Lovable indrømmer 10% fejl i egen kode.

De store spillere kender problemet og bygger løsninger. Men hvad med solo-gründere på Cursor? Eller ikke-tekniske chefer, der laver interne værktøjer?

(New Stack skrev om C-level-ledere med "kun-LLM-kodning". En CEO kørte et BBS på 23 MB RAM uden hændelser i et år. Fedt, men er det normen eller held?)

Tillidskrisen ifølge Forrester

Forrester kalder Vercel/Context.ai-bruddet for et tegn på kollaps i ansvarfordeling. Kritik: Valgfri mærkning af følsomme variabler skaber svage led.

SaaS-sikkerhed er en illusion, når platformen håndterer kodegenerering, hemmeligheder og logs. AI-kode mod disse systemer udvisker grænserne.

Hvad det betyder for din kodebase

Ugen kræver ændringer, hvis du bruger AI-kodning:

1. Forvent fejl i AI-kode. Test som ny junior: SAST, dynamisk analyse, fuzzing.

2. Kortlæg dine AI-værktøjer. Wiz' AI-BOM er smart. Spor modeller som Claude, Copilot, Cursor – de varierer i sikkerhed.

3. Kræv sikkerhed som standard. Opt-in for følsomme ting? Nej tak. Scanning skal være auto.

4. Planlæg for de 76%. 23,8% succes betyder: Brug review, analyse og hardening ved siden af AI.

5. Prioritér kritiske områder. Database, auth og API – her rammer fejl hårdest.

Den positive vinkel

Det er ikke anti-AI. CEO'er som Moshe Bar og OutSystems' leder viser: AI fremskynder uden at ødelægge – hvis du bygger rigtigt.

Nøglen: Design med sikkerhed indeni.

• Scanning i IDE før commit.
• Automatisk rettelse via extensions.
• Opdateret liste over AI-modeller.
• Test AI-kode som eksterne libs.
• Pres på platforme for obligatorisk sikkerhed.

Wiz' Red Agent, Red Gates analyser og SecureVibeBench er ikke dommedag. De er det, vi burde have haft. Nu bygger vi det – efter AI'en er udbredt.

Ugens mønster: Sen indsigt, hurtig handling. Spørgsmålet: Hvor mange apps bærer 20%-risikoen videre?

Oversigten

Wiz på Google Cloud Next: Red Agent til angrebstest, AI-BOM til sporning, inline-scanning for Lovable-kode. Remediation kører i Claude og Cursor. 20% af AI-apps har store huller.

SecureVibeBench: 105 C/C++-opgaver fra 41 OSS-Fuzz-projekter. Fungerende og sikker kode? Bedst: 23,8%. Resten fejler eller gentager fejl.

Red Gates databaseanalyse: Fem fejltyper i AI-databasekode. Henviser til Replit-hændelse og Lovables 10%-rate.

CEO-kodning: Codenotary-CEO byggede BBS med 500 brugere på 23 MB, nul hændelser. OutSystems-CEO testede egen platform mod Claude.

Forresters ramme: Vercel-bruddet afslører SaaS-problemer. Blandede roller for kode, secrets og logs knækker modellen.

Ugen beviste: AI-kodning er her, den booster produktivitet – og vi lærer at sikre den, nogle gange den hårde vej.