Hvorfor AI-genereret kode ødelægger din sårbarhedsstyringsmodel

AI-kodegenerering har gjort noget, som år med DevOps-værktøjer aldrig helt har formået: de har gjort det muligt at udgive funktioner på få dage, hvor det tidligere tog uger. Problemet er, at hastigheden også gælder for sårbarhederne.

Gennem mine år i cybersikkerhed har jeg set organisationer cykle gennem den samme reaktive mønster: opdage en sårbarhed, kæmpe for at forstå dens omfang, diskutere, hvem der ejer løsningen, og afhjælpe den uger eller måneder senere. AI har ikke ændret dette mønster. Det har accelereret det til en hastighed, hvor den gamle model ikke længere kan følge med. Branchegennemsnittet for MTTR for kritiske CVE’er er over 60 dage. AI-assisteret udvikling giver dig ikke 60 dage. Det giver dig en ny kodebase hver sprint.

Det afhængighedsproblem er nu et AI-problem

96 procent af virksomhedsapplikationer inkluderer åbne kildekomponenter. De fleste blev aldrig grundigt gennemgået, men blot hentet fra offentlige registre, fordi de fungerede, og nogen havde brug for dem samme eftermiddag. Sikkerhedsteams har tabt terræn på dette område i år, og AI-kodestøtte har forvandlet en langsom blødning til noget meget sværere at kontrollere.

Når en udvikler skriver kode manuelt, træffer de bevidste valg om afhængigheder. Når en AI-model genererer kode, henter den fra det, den er trænet på. Det betyder ofte hallucinerede pakker, forældede versioner eller komponenter med kendte CVE’er, som modellen ikke havde nogen grund til at undgå. Koden ser ren ud. Risikoen er indlejret i afhængighedstræet, flere lag nede, usynlig for alle, der ikke specifikt søger efter det.

Jeg har siddet i sikkerhedsanmeldelser, hvor hold var chokerede over at finde en kritisk CVE i en transitiv afhængighed af en pakke, de havde godkendt måneder tidligere. Pakken var i orden. Det, den trak med sig, var det ikke. Denne dynamik sker nu på maskineskala, på tværs af hundredvis af udviklere, der bruger AI-værktøjer, som ikke har nogen forestilling om virksomhedens sikkerhedsstilling.

Scanning efter faktum er ikke en strategi

Den herskende model for åben kilde software-sikkerhed er scan-og-patch: køre en scanner, triage fund, tildel billetter og vent. Denne model har altid været reaktiv, og i en AI-accelereret udviklingsmiljø er den helt forsinket.

Scannere finder problemer efter, at de allerede er i din kode. Vinduet mellem introduktion og opdagelse er, hvor din eksponering lever. Når AI genererer kode i stor skala, bliver vinduet bredere, og volumen af fund vokser hurtigere, end nogen team kan manuelt afhjælpe. Resultatet er en CVE-rug, der udvides uendeligt, prioritering, der bliver til gætteri, og udviklere, der bruger 4 til 8 timer pr. sårbarhed på arbejde, der producerer zero forretningsværdi.

Tilføj governance-brud, der følger, og billedet bliver værre. Ejerskab af afhjælp er ofte uklart. Sikkerhed markerer en CVE, ingeniører kalder det en konfigurationsproblem, og operationer kalder det et kodeproblem. Jeg så dette mønster for 20 år siden, og det er ikke gået væk. AI gør konsekvenserne af denne tvetydighed væsentligt sværere at absorbere.

Skiftet, der virkelig fungerer: Kontroller, hvad der kommer ind

Organisationerne, der kommer foran dette, har stoppet med at forsøge at scannen sig til sikkerhed og er begyndt at kontrollere, hvad deres udviklere og AI-værktøjer kan forbruge fra starten. Mekanismen er en kurateret, politik-styret katalog over åbne kildekomponenter, bygget fra kilde, kontinuerligt overvåget og serveret som en privat intern registry, der erstatter direkte hentninger fra offentlige økosystemer som PyPI, npm eller Maven.

Denne tilgang flytter sikkerheden til venstre i den mest litterale forstand. Sårbarheder blokeres på forbrugspunktet, før de nogensinde kommer ind i byggepipeline. Udviklere bruger de samme værktøjer, de altid har brugt. AI-kodestøtte løser afhængigheder fra den samme styrede kilde. Sikkerhedsteamet fastsætter politik én gang, og den politik gælder overalt, herunder for kode, en model genererer klokken 2 om natten uden, at nogen menneske har gennemgået det.

Hvad dette ser ud i praksis

For sikkerhedsledere, der arbejder igennem dette, er der nogle ting, der betyder mere end noget andet:

1. Definer din godkendte komponentsamling, før du skalerer AI-adopteringsprocessen. Hvis dine AI-kodestøtteværktøjer løser afhængigheder fra offentlige registre, eksisterer din godkendelsesproces kun på papir. Etabler en styret intern registry, rout alt gennem den og kræv, at komponenter bygges fra kilde med verificerbar proveniens.
2. Behandle afhjælp som en styret proces, ikke en billetkø. Organisationerne, der holder sig foran CVE-gæld, er ikke dem, der flytter hurtigere på manuel afhjælp. De har fjernet manuel afhjælp fra ligningen. Når en community-godkendt patch er tilgængelig, bliver den genopbygget i kataloget automatisk. Udviklere får opdateringen næste gang, de henter. Ingen tildeler en billet. Ingen venter 60 dage.
3. Kortlæg din AI-værktøjskæde til dine compliance-forpligtelser, før du er tvunget til det. Jeg har set hold bygge på AI-værktøjer i måneder, kun for at ramme en væg, når en kunde krævede FedRAMP-alignment eller SOC 2-bevis. Din kuraterede katalog er også din compliance-revisionsstykke. SBOM’er og proveniensoptegnelser skal følge med hver komponent, ikke samles retroaktivt under deadline-presset.
4. Tildel klart ejerskab på styre-niveau, ikke på billet-niveau. Holdene, der flytter hurtigst på afhjælp, er ikke dem med flest udviklere. De er dem, hvor sikkerhedsteamet ejer politik, platformteamet ejer levering og ingen af dem venter på den anden for at handle.

Sikkerhed, der aktiverer i stedet for blokerer

Der er en vedvarende tro på, at sikkerhed og udviklingshastighed er i fundamental konflikt. Jeg har aldrig fundet det til at være sandt, når sikkerhed er designet ind i processen i stedet for boltet på. Udviklere, der arbejder fra en kurateret komponentsamling, flytter faktisk hurtigere, fordi de ikke tvivler på godkendelser, venter på sikkerhedsanmeldelser eller rydder op i sårbarheder, der kunne være blokeret opstrøms.

Organisationerne, der vil navigere AI-dreven udvikling uden at ansamle uholdbar sikkerheds-gæld, er ikke dem, der kører de fleste scannere. De er dem, der har truffet en bevidst beslutning om at styre, hvad der kommer ind i deres software-forsyningskæde, før det bliver et incident-response-problem. Den beslutning tilhører ledelsen. Værktøjerne til at udføre det findes i dag.