Vibe coding og sikkerhed: tjekliste og prompt til dit eget projekt

I artiklen 13 afsnit

1. Hvorfor virker det, men er alligevel ikke sikkert?
2. Hvad er det typiske, der går galt?
3. Hvad er vigtigt, når koden ligger på GitHub og Vercel?
4. Hvor ligger koden og dataene, og hvem har adgang?
5. Hvad hvis softwaren selv bruger AI?
6. Kan en hacker komme ind, selv med kodeord?
7. Hvad har jeg selv gjort med martinegesoe.dk og SPOR?
8. Tjekliste til dit eget vibe coding-projekt
9. Prompt til at teste sikkerheden i dit eget projekt
10. Hvad sker der, hvis I ikke tjekker?
11. Hvordan kan jeg hjælpe?
12. Hvad kan I gøre nu?
13. Ofte stillede spørgsmål

Hvorfor virker det, men er alligevel ikke sikkert?

AI-genereret kode er i dag næsten altid kode, der kører. Sikker kode er noget andet. Veracode testede over 100 sprogmodeller i 2026, og i gennemsnit klarede de sikkerhedstesten i 56 % af opgaverne. Omkring 44 % af opgaverne gav kode med en kendt sårbarhed, og tallet har knap flyttet sig på et år (Veracode, 2026 GenAI Code Security Report). Mod XSS, en angrebsmåde hvor en fremmed får din hjemmeside til at køre hans kode, svigtede AI i 85 % af tilfældene (SD Times om rapporten).

Tallene er ikke en sandsynlighed for, at lige dit projekt er usikkert. Veracode har testet isolerede kodeopgaver og ikke et helt system i drift. Men de viser det vigtige: At koden virker, fortæller ikke, om den er sikker. Det gør en test kun, hvis du selv beder om den.

Hvad er det typiske, der går galt?

Tre fejl går igen i projekter, der er bygget hurtigt med AI:

• Hemmelige nøgler ligger offentligt. En API-nøgle er en adgangskode, som programmer bruger til at tale sammen. Kommer den ind i koden på GitHub eller i den kode, som browseren henter, kan fremmede bruge den på din regning. Er en nøgle først lagt ud, skal den skiftes, også selv om du sletter den bagefter. GitHub har en funktion, der leder efter kendte nøgler i koden (GitHub, secret scanning), men den fanger ikke alt.
• Login er ikke det samme som adgangskontrol. Et login siger, hvem du er. Det siger ikke, hvad du må se. Hvis en bruger kan ændre et tal i adressen og se en andens data, er login ikke nok. OWASP, der samler de mest almindelige sikkerhedsfejl, har brudt adgangskontrol som nummer ét på sin liste fra 2025 (OWASP Top 10:2025).
• Indstillinger er sat til "det virker". Værktøjet vælger det, der får appen til at køre: åbne databaser, ingen grænse for forbrug, ingen logning. Det er også en kategori på OWASP's liste.

Næsten alle tjenester bruger en regel, som du skal kende: Variabler, der begynder med NEXT_PUBLIC_ i Next.js, bliver lagt ind i den kode, som browseren henter, og kan altså læses af alle (Next.js, dokumentation). Lægger du en hemmelig nøgle der, er den ikke hemmelig mere. Andre værktøjer har tilsvarende regler.

Er det regningen, der bekymrer dig mest, så læs AI-bygget app: fem ting at tjekke, før den går live. Her handler det om sikkerheden.

Hvad er vigtigt, når koden ligger på GitHub og Vercel?

GitHub og Vercel er to steder, hvor mange AI-byggede projekter ender. GitHub opbevarer koden, og Vercel kører den. Den, der kan ændre koden på GitHub, kan i praksis også ændre det, der kører. Tabellen viser, hvad du skal spørge om.

En nøgle skal ligge som en hemmelig indstilling hos hosting-tjenesten og aldrig i koden. Er du i tvivl om, hvilken indstilling der er hemmelig, så spørg AI-værktøjet direkte og bed det forklare, hvor hver nøgle bliver brugt.

Hvor ligger koden og dataene, og hvem har adgang?

Der er tre steder at kigge: koden, databasen og de tjenester, som koden sender data til. Spørg om hvert sted:

• Hvilket land eller hvilken region ligger det i? Mange tjenester kan vælges med en EU-region. Det skal du vælge aktivt, for standarden er ikke altid EU.
• Hvem ejer kontoen? Det skal være jer og ikke en tidligere udvikler eller et AI-værktøjs egen konto.
• Er der en databehandleraftale, hvis tjenesten behandler persondata for jer? Se ChatGPT og GDPR og seks ting, før AI bygger noget.

Mange tjenester er amerikanske selskaber, selv om data ligger i EU. Det betyder ikke automatisk, at noget er forkert, men du skal vide det og kunne forklare det. Jeg er ikke jurist, og en EU-region er ikke i sig selv det samme som at overholde GDPR.

Hvad hvis softwaren selv bruger AI?

Hvis dit værktøj analyserer data, laver billeder eller genererer rapporter ved hjælp af en AI-model, sendes dine data til modellen. Så skal du kunne svare på tre ting:

1. Hvad bliver sendt? Kun det nødvendige, og ikke for eksempel CPR-numre eller sundhedsoplysninger.
2. Hvor og hos hvem bliver det behandlet? Hvilken udbyder, hvilken region, og bruger udbyderen jeres data til at træne modeller?
3. Hvem kan se resultatet? Både dem, der må, og dem, der ikke må.

AI-forordningen stiller krav, men de afhænger af, hvad softwaren bruges til, og hvilken rolle I har. De fleste små interne værktøjer er ikke højrisiko, men der kan gælde krav om at oplyse, at brugeren taler med AI, og om at medarbejdere har tilstrækkelig AI-forståelse (artikel 4). Se tidslinjen for AI-forordningen, artikel 4 og hvornår kunden skal have besked. Den officielle tekst står på artificialintelligenceact.eu, og Digitaliseringsstyrelsen samler vejledning på digst.dk. Spørg en jurist, hvis du er i tvivl om, hvad der gælder for netop jeres værktøj.

Kan en hacker komme ind, selv med kodeord?

Ja. Et kodeord alene beskytter ikke, fordi det kan stjæles, gættes, genbruges fra en anden tjeneste eller snydes ud af en medarbejder med en falsk mail. Og login hjælper ikke, hvis en fejl i koden lader en bruger se andres data, eller hvis en nøgle ligger åbent.

To-faktor-godkendelse betyder, at du skal bevise, hvem du er på to måder, fx med kodeord og en kode fra en app på telefonen. Så er et stjålet kodeord ikke nok. OWASP anbefaler flerfaktorgodkendelse og peger på, at nogle metoder er stærkere end andre. En sms-kode er bedre end ingenting, men en app eller en nøgle (passkey) er stærkere (OWASP, Multifactor Authentication Cheat Sheet). Slå det til på de konti, der betyder mest: GitHub, hosting, database, mail og domæne. Der beskytter det både koden og de nøgler, som alt andet hænger på. Har din egen software et login, så kræv det til brugerne også, hvis den indeholder noget, der ikke må komme ud.

Hvad har jeg selv gjort med martinegesoe.dk og SPOR?

Jeg bygger selv med AI, så jeg har brugt tjeklisten på mine egne systemer. Det er ikke en garanti, men en beskrivelse af, hvad jeg har gjort.

• Hjemmesiden martinegesoe.dk er en statisk hjemmeside uden database og uden login. Der er ikke noget at bryde ind i, og målingen starter først, når du har sagt ja til den.
• SPOR er mit system til at holde styr på virksomhedens AI. Der er to-faktor for alle, data ligger i EU (Frankfurt), og kunders data er adskilt fra hinandens i databasen, ikke kun i skærmbilledet. De hemmelige nøgler ligger som hemmelige indstillinger og ikke i koden.
• Jeg lod en AI-gennemgang kontrollere koden efter OWASP's standard, den samme, som artiklen henviser til. Det er ikke en uafhængig test. Gennemgangen fandt blandt andet en fejl i, hvordan ny kode sendes i produktion, og en fejl i, hvordan AI-forbrug blev kontrolleret. Jeg har rettet dem i koden og skrevet tests, der fejler, hvis fejlen kommer tilbage.

Du kan læse mere om, hvor data ligger, og hvad SPOR ikke indeholder, på Din tryghed. SPOR lover ikke compliance, og jeg er hverken jurist eller revisor.

Tjekliste til dit eget vibe coding-projekt

Gå listen igennem, før et projekt får rigtige data eller rigtige brugere. Hvert punkt kan tjekkes på få minutter.

Prompt til at teste sikkerheden i dit eget projekt

Her er et udkast til en prompt, du kan give til et AI-kodeværktøj som Claude, ChatGPT eller Cursor. Den beder værktøjet om at gennemgå dit projekt og rapportere. Den må ikke bruges 1 til 1: Ret de tekster, der står i kantede parenteser, så de passer til dit projekt, og slet de punkter, der ikke gælder. Jeg bruger selv en meget længere udgave til SPOR, og den kan ikke bruges på andre systemer.

Kør prompten igen, når du har rettet. Og husk, at en gennemgang fra AI-værktøjet ikke er det samme som en uafhængig sikkerhedstest. Den finder meget, men ikke alt. Har projektet rigtige kunder eller følsomme data, så få en fagperson til at se på det. Vil du læse standarden bag: OWASP ASVS 5.0.

Hvad sker der, hvis I ikke tjekker?

Fejlene bliver dyre, når de først er opdaget af andre. En lækket nøgle giver misbrug og en regning. Kommer persondata ud, skal en virksomhed som udgangspunkt anmelde bruddet til Datatilsynet uden unødig forsinkelse og om muligt inden 72 timer (GDPR artikel 33). Det koster tid, tillid og ofte kunder. Se også hvad der skal leve videre efter go-live.

Hvordan kan jeg hjælpe?

Jeg gennemgår AI-byggede projekter mod tjeklisten og siger, hvad der skal rettes først. Jeg arbejder i denne rækkefølge: forstå processen → udvikle løsningen → integrere den → hjælpe med drift og videreudvikling. Se mine systemer og løsninger. Jeg giver ikke juridisk rådgivning, jeg er ikke revisor, og jeg garanterer ikke, at noget er sikkert eller overholder reglerne.

Hvad kan I gøre nu?

Gør dette i dag:

1. Slå to-faktor til på GitHub, hosting, database, mail og domæne.
2. Søg efter nøgler i koden og i historikken. Skift dem, der har ligget åbent.
3. Test, om en bruger kan se en andens data.
4. Sæt et forbrugsloft og en alarm.
5. Kør prompten ovenfor på en kopi af projektet, og ret det vigtigste først.

Kort sagt: Det tager en eftermiddag at tjekke det grundlæggende, og meget længere at rydde op efter et brud.

Ofte stillede spørgsmål

Er AI-genereret kode sikker?

Ikke automatisk. Veracodes test af over 100 sprogmodeller i 2026 viste, at kode fra AI klarede sikkerhedstesten i 56 % af opgaverne, og at resultatet næsten ikke var blevet bedre på et år. Det er en test af isolerede opgaver og ikke en dom over et bestemt projekt, men det er en god grund til selv at tjekke.

Hvad gør jeg, hvis jeg har lagt en API-nøgle på GitHub?

Skift nøglen hos udbyderen med det samme, og slet den gamle. Det er ikke nok at fjerne den fra koden, fordi den stadig ligger i historikken. Tjek derefter udbyderens forbrug for aktivitet, du ikke kender.

Er to-faktor nok til at beskytte min software?

Nej, men det er et af de vigtigste lag. To-faktor beskytter mod et stjålet kodeord. Det beskytter ikke mod en fejl i koden, der lader en bruger se andres data, og heller ikke mod en nøgle, der ligger åbent. Derfor skal alle lagene være på plads.

Skal min software leve op til AI-forordningen?

Det afhænger af, hvad den bruges til, og af jeres rolle. Mange små interne værktøjer er ikke højrisiko, men der kan gælde krav om information til brugeren og om AI-forståelse hos medarbejderne. Læs oversigten i artiklerne om AI-forordningen, og spørg en jurist, hvis I er i tvivl.

Artiklen er generel vejledning og ikke juridisk rådgivning eller en sikkerhedsgaranti. Udgivet 5. oktober 2026.