Er AI-genereret kode sikker nok til produktion?

Er AI-genereret kode sikker nok til produktion? Kun, hvis den behandles med samme krav og kontroller som al anden kode. Spørgsmålet om, er AI-genereret kode sikker, har derfor ikke et ja/nej-svar, der gælder generelt. Værktøjer som GitHub Copilot og ChatGPT leverer ofte kode, der virker og ser ryddelig ud, men de garanterer ikke, at den er sikker, opdateret eller tilpasset jeres arkitektur. Sikkerheden afgøres af den proces, koden passerer igennem, før den når produktion, og af om nogen har påtaget sig ansvaret for resultatet.

Er AI-genereret kode sikker, når den ser korrekt ud?

Den største fare er ikke, at AI-kode er åbenlyst dårlig. Den er, at den ser overbevisende ud. En sprogmodel producerer det statistisk mest sandsynlige svar på en prompt, ikke det, der er sikkert i jeres konkrete miljø. Koden kompilerer, testene består, og funktionen leverer det, udvikleren bad om. Sikkerhedsfejl opdages først senere, hvis nogen overhovedet leder efter dem.

Derfor er svaret på spørgsmålet i praksis betinget af tre forhold:

Hvad koden bruges til: Et internt hjælpescript til datakonvertering har en anden risikoprofil end login, betalingsflow eller API’er, der håndterer persondata.
Hvem der reviewer den: Kode, som en erfaren udvikler gennemgår kritisk, er noget andet end kode, der copy-pastes direkte fra en chat.
Hvilke automatiske kontroller der findes: Uden scanning i pipelinen afhænger sikkerheden af held og individuel disciplin.

For IT-ledere er pointen, at AI ikke ændrer kravene til produktionskode. Den ændrer mængden af kode, der skal kontrolleres, og hastigheden, den ankommer i.

Hvilke skjulte risici introducerer AI-genereret kode?

AI-værktøjer fejler på måder, der adskiller sig fra almindelige menneskelige fejl. Tre mønstre går igen.

Forældede afhængigheder og hallucinerede pakker

Modeller er trænet på kode fra et bestemt tidspunkt. De foreslår derfor gerne biblioteksversioner, der siden er fundet sårbare, eller API-kald, der er udfaset. Modeller kan også opfinde pakkenavne, der ikke findes. Det er et reelt angrebsspor: En angriber kan registrere et navn, som modeller ofte foreslår, og fylde det med skadelig kode. En udvikler, der blindt kører installationskommandoen, har dermed hentet malware ind i sit projekt.

Usikre kodemønstre

Modeller har lært af enorme mængder offentlig kode, herunder kode med dårlige vaner. Typiske eksempler er:

SQL-forespørgsler bygget ved strengsammensætning frem for parametriserede kald
manglende eller for svag inputvalidering
svag eller forkert brug af kryptografi, fx forældede hashfunktioner til adgangskoder
hardcodede nøgler, tokens og adgangskoder i eksempelkode, som udvikleren overtager uden at udskifte
fejlhåndtering, der lækker interne oplysninger i fejlbeskeder
for brede CORS-indstillinger eller tilladelser, der “bare får det til at virke”

Disse fejl falder ind under kategorier, som OWASP har beskrevet i årevis i bl.a. OWASP Top 10. Nyt er ikke fejlene, men at de nu kan produceres hurtigt og i stor skala.

Manglende kontekstforståelse

En model kender ikke jeres trusselsmodel, jeres dataklassifikation eller jeres adgangsmodel. Den ved ikke, at et bestemt felt indeholder personoplysninger, eller at kunder skal være strengt adskilt i et multitenant-system. Den foreslåede kode kan være teknisk fornuftig i isolation, men forkert i jeres sammenhæng, fx en endpoint uden kontrol af, om brugeren må tilgå netop den ressource. Den slags logiske fejl fanger automatiske værktøjer sjældent alene.

Dertil kommer et organisatorisk problem: Udviklere kan indsætte fortrolig kode eller data i eksterne AI-tjenester. Det er et spørgsmål om datalækage og om, hvad leverandøren må bruge input til, og det bør afklares i aftale- og politikregi, før værktøjet tages i brug.

Hvordan fanger en Secure SDLC-proces fejlene, uanset hvem der har skrevet koden?

Heldigvis behøver man ikke en særlig proces til AI-kode. En struktureret Secure SDLC behandler al kode som ukendt, indtil den er kontrolleret, og er derfor et naturligt svar på AI-udfordringen. Den bygger sikkerhed ind fra planlægning til drift i stedet for at tilføje en kontrol til sidst. Vil du dykke ned i, hvordan håndtering af sårbarheder i kode kan struktureres i hele livscyklussen, er faserne et godt udgangspunkt.

De faser, der betyder mest, når AI er med i værkstedet:

Planlægning og sikkerhedskrav: Informationsklassifikation og kritikalitet afgør, hvor AI-assistance overhovedet er acceptabel, og hvor kravene til review skærpes.
Risiko- og trusselsmodellering: Her sættes konteksten, som modellen mangler. Hvis teamet har identificeret misbrug af rettigheder eller manglende adskillelse mellem kunder som trusler, kan reviewere målrettet kontrollere netop de punkter i den genererede kode.
Sikker udvikling: Retningslinjer for sikker kodning, peer review og code review, SAST, scanning efter eksponerede secrets og kontrol med open source-komponenter. Her hører også klare krav til brug af AI-assisterede udviklingsværktøjer hjemme.
Test og sikkerhedskontrol: SAST, DAST og Software Composition Analysis, test af adgangsstyring, API-sikkerhedstest og penetrationstest efter risiko.
Release og deployment: Klare kriterier for, hvilke fund der skal være lukket, hvem der kan godkende, og hvordan undtagelser risikovurderes og dokumenteres.
Drift og sårbarhedshåndtering: Løbende overvågning og håndtering af nye sårbarheder i egen kode og i tredjepartskomponenter.

Hver kontrol dækker en specifik AI-risiko. Software Composition Analysis finder de forældede eller sårbare biblioteker, modellen foreslog. Secret-scanning fanger de nøgler, der blev hængende fra eksempelkode. SAST peger på klassiske usikre mønstre. Code review og trusselsmodellering dækker den kontekst, værktøjerne ikke kan se.

Hvem har ansvaret, når AI-genereret kode indeholder en sårbarhed?

Kort sagt: virksomheden, der sender koden i produktion. AI-værktøjet er ikke en ansvarlig part, og leverandørens vilkår fraskriver typisk ansvar for outputtet. Det er værd at læse jeres konkrete aftale, men man bør ikke gå ud fra, at leverandøren dækker et tab.

Internt er ansvaret ofte uklart. Udvikleren, der accepterede forslaget, reviewer, der godkendte pull requesten, og lederen, der indførte værktøjet uden retningslinjer, kan alle pege på hinanden. Det er en ledelsesopgave at gøre ansvaret eksplicit:

Udvikleren, der committer koden, ejer den, som om han selv havde skrevet hver linje.
Reviewere godkender ud fra samme kriterier for AI- og menneskekode.
Produktejeren ejer risikoaccepten, når en undtagelse gives.
Ledelsen ejer rammerne: politik, værktøjsvalg og ressourcer til kontrol.

Har virksomheden regulatoriske krav, fx under GDPR, NIS2 eller kontraktlige sikkerhedskrav fra kunder, ændrer AI ikke på dem. Lovgivningen stiller generelt krav om passende tekniske og organisatoriske foranstaltninger, uanset hvordan koden er blevet til. Er I i tvivl om, hvordan kravene rammer netop jer, bør I søge juridisk og teknisk rådgivning.

Hvordan sikrer man kvaliteten uden at bremse udviklingstempoet?

AI bruges, fordi den øger tempoet. Hvis sikkerhedskontrol bliver en manuel flaskehals, finder udviklerne omveje, fx private konti hos AI-tjenester, der ikke er godkendt. Løsningen er at automatisere det, der kan automatiseres, og bruge menneskelig tid, hvor den gør forskel.

Flyt kontrollerne ind i pipelinen: SAST, secret-scanning og afhængighedskontrol kører automatisk ved hver pull request og blokerer ved kritiske fund.
Risikobaseret review: Dybt review af autentifikation, adgangsstyring, kryptering og dataadgang. Let review af lavrisiko-kode.
Små ændringer: Store AI-genererede pull requests er svære at reviewe grundigt. Kræv mindre, afgrænsede ændringer.
Godkendt værktøjsliste: Giv teamet et sikkert, tilladt alternativ, så skygge-AI undgås.

Mere om, hvilke krav ledelsen generelt bør stille, kan du læse i Sikker softwareudvikling: Krav ledelsen skal stille til udviklere og leverandører.

Hvilke krav bør ledere stille til teams, der bruger AI-værktøjer?

Konkrete krav, der kan efterprøves, virker bedre end generelle forbud eller ukritisk accept. Et praktisk udgangspunkt:

En skriftlig AI-politik for udvikling: Hvilke værktøjer er godkendt, hvilke data og hvilken kode må ikke sendes ud, og hvilke systemer er undtaget.
Leverandørvurdering: Afklar databehandling, opbevaring af prompts, brug til modeltræning og databehandleraftaler, før værktøjet udrulles.
Ens review-krav: AI-genereret kode må ikke have lavere review-standard. Overvej at kræve, at pull requests angiver, om AI er brugt væsentligt.
Obligatoriske automatiske kontroller: SAST, SCA og secret-scanning som betingelse for merge.
Kontrol af nye afhængigheder: Nye pakker skal verificeres, før de tilføjes, for at imødegå hallucinerede og ondsindede pakker.
Kompetenceløft: Udviklere skal kunne genkende usikre mønstre. Træning i sikker kodning er vigtigere, når en maskine skriver meget af koden.
Dokumenterede undtagelser: Hvis en release går i luften med kendte fund, skal risikoen vurderes, godkendes af en navngiven ansvarlig og dokumenteres.
Løbende opfølgning: Mål fx hvor mange fund der opstår, og hvor hurtigt de lukkes, og justér politikken, når værktøjerne udvikler sig.

Tænker I videre over, hvor langt AI i det hele taget skal have lov at gå i jeres systemer, kan Er det sikkert at lade AI styre virksomhedens systemer? give et supplerende perspektiv.

Konklusion: sikkert nok, hvis processen er det

AI-genereret kode er ikke i sig selv usikker, men den er heller ikke sikker pr. automatik. Den kan være brugbar i produktion, når den passerer de samme krav, kontroller og ansvarsfordelinger som al anden kode. De organisationer, der får mest ud af AI, er dem, der har en moden Secure SDLC, som gør hurtig udvikling og høj sikkerhed forenelige. Start med at gøre ansvaret klart, automatisér de basale kontroller, og stil krav til brugen af værktøjerne, før de bliver en uformel del af hverdagen.