Vibe-Coding AI Sikkerhedshul i Softwareudvikling: Sådan Beskytter Du Din Kode i 2026
Det er torsdag morgen, og jeg sidder med en kop kaffe og kigger på et pull request fra en udvikler i mit team. Der er 200 linjer ny kode, genereret på under fem minutter med GitHub Copilot. Koden ser pæn ud, den er veludformet, og den løser problemet perfekt — på papiret. Men da jeg åbner den, finder jeg tre sikkerhedshul, som kunne have kostet os dyrt. Det er et mønster, jeg ser igen og igen i 2026: vibe-coding AI sikkerhedshul i softwareudvikling er blevet en af de vigtigste sikkerhedsudfordringer, som danske virksomheder står over for.
Vibe-coding — det at skrive kode baseret på intuition og flow uden grundig sikkerhedsgennemgang — er ikke nyt. Men det er blevet eksponentielt værre siden AI-assistenter som GitHub Copilot, Claude og ChatGPT blev mainstream. Udvikler får en prompt, AI genererer kode, og koden lander direkte i produktionen uden ordentlig sikkerhedsrevision. Det sker hver dag i tusinder af virksomheder, og det er et problem, vi ikke kan ignorere.
I denne artikel dykker jeg ned i hvad vibe-coding er, hvordan det skaber sikkerhedshul, og vigtigst af alt: hvordan du kan beskytte din kode i 2026. Jeg deler praktiske strategier, konkrete værktøjer og steps, som danske virksomheder kan implementere med det samme.
Hvad Er Vibe-Coding og Hvorfor Er Det et Sikkerhedsproblem?
Vibe-coding handler om at skrive kode baseret på "vibes" — det vil sige, at man skriver uden at tænke dybt over sikkerhed, performance eller langtidsvedligeholdelse. Det er ikke inherent dårligt, og det er helt sikkert ikke nyt. Programmører har altid arbejdet i flow-tilstande, hvor de løser problemer hurtigt uden at analysere hver linje. Men da AI-assistenter kom ind i billedet, blev vibe-coding til en systemisk risiko.
GitHub Copilot, Claude og ChatGPT har demokratiseret kodegenerering. En udvikler kan nu skrive en prompt som "generer en login-funktion", og få 50 linjer arbejdende kode på sekunder. Det er fantastisk for produktiviteten. Men her ligger problemet: udvikler er nu under pres for at levere hurtigt, AI genererer kode uden sikkerhedskontekst, og koden bliver implementeret uden ordentlig review. Det er som at købe en brugt bil uden at få den inspiceret — det virker fint indtil det pludselig ikke gør.
Statistikkerne taler for sig selv. Undersøgelser fra 2025 og 2026 viser, at omkring 40% af kode genereret af AI-assistenter indeholder mindst ét sikkerhedshul, som ville være fanget af en erfaren sikkerhedsrevisor. Nogle kilder taler om, at op til 60% af AI-genereret kode i nogle domæner (som kryptering og autentificering) har kritiske problemer. Det er ikke fordi AI-modellerne er onde — det er fordi de er trænet på offentlige repositories, hvor meget af koden er suboptimal eller direkte usikker.
Risikoen forværres, når virksomheder ikke har klare policies for, hvordan AI-genereret kode skal behandles. Hvis du behandler det som færdig kode uden review, introducerer du systematisk sikkerhedshul i dine systemer. Hvis du derimod bruger AI som inspirationskilde og gennemgår alt grundigt, kan du få det bedste fra begge verdener: hastighed og sikkerhed.
Almindelige Sikkerhedshul i AI-Genereret Kode
Når jeg analyserer AI-genereret kode fra mine klienter, ser jeg de samme sikkerhedshul igen og igen. Og de er ikke særlige sofistikerede — de er klassiske vulnerabilities, som burde være døde for tyve år siden, men som AI-modeller reproducerer med deprimerende regelmæssighed.
SQL-Injection og Klassiske Input-Vulnerabilities
SQL-injection er kodegeneration-modelernes klassiske fejl. Jeg bad ChatGPT om at generere en funktion til at søge efter brugere i en database. Koden så ud til at være pæn, men den byggede SQL-strenge ved at konkatenere brugerinput direkte ind i queries. Hvis en bruger søgte efter "; DROP TABLE users; --, ville hele tabellen blive slettet. SQL-injection er ikke et nyt problem — det er fra 2000'erne — men AI-modeller lærer det fra Stack Overflow og gamle tutorials, hvor det var standard praksis.
Manglende input-validering er lige så almindeligt. En AI-assistent genererer en funktion, der accepterer en email-adresse, men uden at validere, at det faktisk er en valid email. Eller den accepterer en integer uden at tjekke for negative værdier eller overflow. Det er ikke fordi AI ikke kan forstå validering — det er fordi træningsdataene indeholder tusinder af eksempler på kode uden validering.
Hardcodede Credentials og API-Nøgler
Dette er måske det mest skræmmende sikkerhedshul. Jeg har set AI-assistenter generere kode med hardcodede AWS-nøgler, database-passwords og API-tokens direkte i kildekoden. Udvikler spørger "hvordan forbinder jeg til databasen?", og AI svarer med en forbindelsesstreng, der indeholder det rigtige password. Hvis denne kode endte op på GitHub (selv som privat repository), ville en angriber have adgang til hele databasen.
Problemet er, at AI-modellerne er trænet på repositories fra GitHub, hvor folk har gjort netop denne fejl tusinder af gange. Modellerne lærer mønstre fra data, ikke sikkerhedsprincipper. Så når du spørger om databaseforbindelse, reproducerer den mønstre fra træningsdataene, selv hvis de er usikre.
Svage Krypteringsimplementeringer
Kryptering er en af de områder, hvor AI er værst. Jeg testede en prompt som "generer en funktion til at kryptere data". Her er hvad jeg fik:
- Brug af ECB-mode i stedet for CBC eller GCM (ECB er usikkert fordi det ikke skjuler mønstre)
- Hardcodede encryption keys
- Brug af MD5 eller SHA1 til password-hashing (begge er brudt)
- Ingen random salt til password-hashing
- Brug af random.randint() i stedet for cryptographically secure randomness
Hver eneste af disse fejl ville blive fanget af en sikkerhedsrevisor. Men hvis koden aldrig bliver reviewet, ender den i produktion, og dine brugeres data er nu usikkert krypteret.
Dependency-Vulnerabilities og Outdated Libraries
AI-assistenter genererer ofte kode, der bruger biblioteker uden at tænke på, om bibliotekerne er opdaterede eller har kendte sikkerhedshul. En udvikler spørger "hvordan parser jeg JSON?", og AI svarer med at bruge en tre år gammel library-version, der har 15 CVE'er. Eller den bruger en dependency, der selv har usikre dependencies — hele supply chain bliver kompromitteret.
Hvordan AI-Modeller Lærer Usikker Kode
For at forstå problemet fuldt ud, må vi forstå, hvordan AI-modeller bliver trænet. Og her ligger roden til meget af problemet: AI-genereret kode er usikker, fordi modellerne lærer fra usikker kode.
GitHub Copilot, ChatGPT og Claude er alle trænet (helt eller delvist) på offentlige repositories fra GitHub, Stack Overflow og andre kilder. Disse kilder indeholder milliarder af linjer kode. Nogle af det er fantastisk, best-practice kode skrevet af erfarne sikkerhedsingeniører. Men meget af det er dårligt skrevet kode, hacky løsninger og direkte usikre implementeringer.
Når en AI-model lærer mønstre fra disse kilder, lærer den ikke sikkerhedsprincipper. Den lærer statistiske mønstre — "når nogen spørger om SQL, svarer vi sådan her, fordi sådan var der 10.000 eksempler i træningsdataene". Hvis de 10.000 eksempler indeholder SQL-injection, lærer modellen at generere SQL-injection.
Stack Overflow er et særligt problem. Stack Overflow er fantastisk for at finde svar hurtigt, men det indeholder også tusinder af upvotede svar, der er sikkerhedsmæssigt tvivlsomme. En udvikler stiller spørgsmål "hvordan laver jeg login?", og det mest upvotede svar bruger plaintext-passwords. AI-modeller lærer fra disse upvotede svar, fordi de er velsynlige i træningsdataene.
Derudover mangler AI-modeller kontekst omkring sikkerhedsbeslutninger. Når en erfaren udvikler skriver kode, tænker hun på threat models, compliance-krav, og hvem der skal bruge systemet. AI-modeller har ingen sådan kontekst. De genererer kode baseret på prompts, og hvis prompten ikke eksplicit nævner sikkerhed, prioriteres den ikke.
En anden faktor er, at AI-modeller er optimeret for at være brugbare og hurtige, ikke for at være sikre. Hvis en model skulle være 100% sikker, ville den blive så konservativ, at den ville være næsten ubrugelig. I stedet vælger udvikler af AI-modeller at prioritere brugbarhed, og overlader sikkerhed til brugeren.
Bedste Praksis: Sikker Brug af AI-Assistenter i Udvikling
Så hvordan bruger du AI-assistenter uden at introducere sikkerhedshul? Svaret er ikke at undgå AI — det ville være at ignorere et kraftigt værktøj. Svaret er at bruge det rigtigt. Her er de vigtigste bedste praksis, som jeg anbefaler til alle mine klienter.
Implementer Obligatorisk Code Review for AI-Genereret Kode
Dette er nummer ét på listen. Alt kode genereret af AI skal gennem en sikkerhedsrevision før det går i produktion. Ikke en hurtig glance, men en ordentlig review af en udvikler, der forstår sikkerhed. Jeg anbefaler, at reviews af AI-genereret kode bliver ekstra grundige — mindst dobbelt så grundige som reviews af manuelt skrevet kode.
Hvordan implementerer man dette praktisk? Opret en policy, der siger, at alle pull requests med AI-genereret kode skal mærkes med et tag (f.eks. "ai-generated"). Disse pull requests skal reviewes af mindst én sikkerhedsorienteret udvikler. Gør det til en del af jeres Definition of Done, så det ikke kan omgås.
Brug SAST-Værktøjer på Alle AI-Genererede Outputs
SAST (Static Application Security Testing) værktøjer som Snyk, SonarQube og Checkmarx kan automatisk scanne kode for kendte sikkerhedshul. Integrer disse værktøjer i jeres CI/CD-pipeline, så hver gang en udvikler pusher kode (især AI-genereret), bliver den automatisk skannet.
Disse værktøjer vil ikke fange alt — de er ikke perfekte — men de vil fange de mest åbenlyse problemer som hardcodede credentials, klassiske injection-vulnerabilities og dependency-problemer. Hvis SAST-værktøjerne ikke giver grønt lys, kan koden ikke merges. Det er en mekanisk sikkerhedscheck, som ikke afhænger af menneskelig opmærksomhed.
Træn Udviklere i Sikker Prompt-Engineering
Måden, du spørger AI'en, påvirker den kode, der genereres. Hvis du spørger "generer en login-funktion", får du generisk kode uden sikkerhedskontekst. Hvis du spørger "generer en sikker login-funktion med bcrypt password-hashing, input-validering og rate-limiting", får du betydeligt bedre kode.
Træn dine udviklere til at skrive sikkerhedsspecifikke prompts. Lad dem være eksplicitte om:
- Sikkerhedskrav (kryptering, hashing-algoritmer, osv.)
- Compliance-krav (GDPR, NIS2, osv.)
- Trussel-modeller (hvad er vi bange for?)
- Input-validering og output-encoding
- Dependency-versioner (brug stable, well-maintained libraries)
En velskrevet prompt kan halvere mængden af sikkerhedshul i AI-genereret kode.
Etabler Klare Policies for Hvad AI Må Generere
Ikke al kode er lige vigtig sikkerhedsmæssigt. Login-funktioner, payment-processing og datakryptering er kritiske. Utility-funktioner, formatting-kode og test-fixtures er mindre kritiske. Opret en policy, der siger:
- AI-assistenter må ikke bruges til sikkerhedskritisk kode uden ekstra review
- AI-assistenter må bruges til utility-kode med standard code review
- AI-assistenter må bruges til test-kode og dokumentation med minimal review
Dette betyder, at du får hastighed hvor det betyder noget (utility-kode), men bevarer kontrol hvor det betyder mest (sikkerhedskritisk kode).
Dokumenter og Spor AI-Genereret Kode
Når kode bliver genereret af AI, skal det være sporbart. Hvis der senere opdages et sikkerhedshul i AI-genereret kode, skal du kunne finde alle steder, hvor denne kode bruges. Jeg anbefaler at tilføje kommentarer til kode som:
// AI-generated by GitHub Copilot on 2026-04-11, reviewed by [reviewer], JIRA-ticket: SEC-1234
Dette gør det muligt at spore kode tilbage til review-processen og gør det klart for fremtidige maintainere, at dette er AI-genereret og skal behandles med ekstra forsigtighed.
Tools og Strategier til Sikring af AI-Genereret Kode
Teori er fint, men hvad skal du konkret implementere? Her er de værktøjer og strategier, som jeg bruger dagligt til at sikre AI-genereret kode i danske virksomheder.
SAST-Værktøjer: Dit Første Forsvar
Snyk er mit go-to værktøj til at scanne for vulnerabilities i dependencies og kode. Det integrerer direkte med GitHub, GitLab og andre platforme, og det giver real-time feedback. Når en udvikler pusher kode med en sårbar dependency, får hun besked øjeblikkeligt.
SonarQube er mere omfattende og fokuserer på code quality og sikkerhed. Det kan scanne for over 1.000 forskellige types problemer, inklusive sikkerhedshul, code smells og complexity-problemer. Det er ekstra værdifuldt for AI-genereret kode, fordi det kan fange mønstre, som menneskelige reviewere måske overser.
Checkmarx er et enterprise-niveau værktøj, som bruges af større virksomheder. Det er dyrere end Snyk og SonarQube, men det giver dybere analyse og færre false positives.
Dependency-Scanning og Vulnerability-Management
AI genererer ofte kode med outdated eller sårbare dependencies. Implementer automatiseret dependency-scanning som del af jeres CI/CD-pipeline. Tools som Dependabot (GitHub), Renovate eller Snyk kan automatisk opdatere dependencies og flagge vulnerabilities.
Opret en policy, der siger at kritiske vulnerabilities skal fixes inden 24 timer, høje vulnerabilities inden 7 dage. Hvis AI genererer kode med kritiske vulnerabilities, bliver det fanget og kan ikke merges.
Secure Coding Frameworks og Templates
I stedet for at stille AI'en helt åben, kan du give den rammer at arbejde inden for. Opret templates til almindelige patterns (login, API-endpoints, database-queries) som følger jeres sikkerhedsstandarder. Når en udvikler skal bruge AI til at generere kode, starter hun fra en sikker template i stedet for fra scratch.
For eksempel kan du have en template til login, der allerede indeholder:
- Bcrypt password-hashing
- Rate-limiting
- Input-validering
- Secure session-handling
- CSRF-protection
Udvikler kan så spørge AI'en "generer login-kode baseret på denne template", og AI vil generere kode, der følger jeres standarder.
Continuous Security Testing i CI/CD
Sikkerhed skal være integreret i jeres development process, ikke noget, der tjekkes til sidst. Opret en CI/CD-pipeline, der:
- Scanner kode med SAST-værktøjer (Snyk, SonarQube)
- Scanner dependencies for vulnerabilities
- Kører sikkerhedsorienterede unit tests
- Kører DAST (Dynamic Application Security Testing) tests på test-miljø
- Checker for secrets (hardcodede nøgler, tokens)
Alt dette skal ske automatisk, uden menneskelig intervention. Hvis noget fejler, blokeres koden fra at blive deployed.
CVE-Tracking og Open Source Security-Databaser
Hold dig opdateret med kendte vulnerabilities. Databaser som NVD (National Vulnerability Database), CVE.org og GitHub Advisory Database indeholder information om alle kendte sikkerhedshul. Integrer disse databaser med dine scannerings-værktøjer, så du bliver notificeret, når en sårbar version af en library bruges i din kode.
Implementering i Danske Virksomheder: Praktiske Steps
Du er nu overbeviste om problemet og ved hvilke værktøjer du skal bruge. Men hvordan implementerer du det i praksis i en dansk virksomhed? Her er konkrete steps, som jeg har hjulpet klienter med at gennemføre.
Trin 1: Audit Eksisterende AI-Genereret Kode
Før du kan bevæge dig fremad, skal du vide, hvor du står. Scan alt eksisterende kode i dine produktionsmiljøer med SAST-værktøjer for at finde sikkerhedshul introduceret gennem AI. Du kan også spørge dine udviklerteams: "Hvor meget af jeres kode er AI-genereret?" og "Blev den AI-genererede kode reviewet