Hvorfor AI-generert kode bryter din sårbarhetsmodell

AI-kodegeneratorene har gjort noe som år med DevOps-verktøy aldri helt klarte: de har gjort det mulig å levere funksjoner på noen dager som tidligere tok uker. Problemet er at hastigheten også gjelder for sårbarhetene.

Gjennom mine år i cybersikkerhet, har jeg sett organisasjoner sykle gjennom samme reaktive mønster: oppdage en sårbarhet, kjempe for å forstå omfanget, diskutere hvem som eier fikset, og fikse det uker eller måneder senere. AI har ikke endret dette mønsteret. Det har akselerert det til en hastighet hvor den gamle modellen ikke lenger kan holde pace. Industri-gjennomsnittet for MTTR for kritiske CVE’er er over 60 dager. AI-assistert utvikling gir deg ikke 60 dager. Det gir deg en ny kodebase hver sprint.

Avhengighetsproblemet er nå et AI-problem

Nittiseks prosent av bedriftsapplikasjonene inkluderer åpne kildekomponenter. De fleste ble aldri grundig verifisert, bare trukket fra offentlige registre fordi de fungerte og noen trengte dem den ettermiddagen. Sikkerhetsteamene har tapt terreng på dette i årevis, og AI-kodestøtten har forvandlet en langsom blødning til noe mye hardere å kontrollere.

Når en utvikler skriver kode manuelt, tar de bevisste valg om avhengigheter. Når en AI-modell genererer kode, den trekker fra hva den ble trent på. Det betyr ofte hallucinerte pakker, utdaterte versjoner eller komponenter med kjente CVE’er som modellen ikke hadde noen grunn til å unngå. Koden ser ren ut. Risikoen er innebygget i avhengighetstreet, flere lag ned, usynlig for noen som ikke ser spesielt etter det.

Jeg har sittet i sikkerhetsgjennomganger hvor teamene var sjokkerte over å finne en kritisk CVE i en transittiv avhengighet av en pakke de hadde godkjent måneder tidligere. Pakken var fin. Det den trakk inn var ikke. Denne dynamikken skjer nå på maskin-skala, over hundrevis av utviklere som bruker AI-verktøy som ikke har noen forestilling om organisasjonens sikkerhetsposture.

Scanning etter faktum er ikke en strategi

Den rådende modellen for åpne kildeprogramvare-sikkerhet er scan-og-fiks: kjør en skanner, triage funn, tildele billetter og vent. Denne modellen har alltid vært reaktiv, og i en AI-akselerert utviklingsmiljø er den fullstendig forbigått.

Skannere finner problemer etter at de allerede er i koden din. Vinduet mellom innføring og oppdagelse er der eksponeringen din bor. Når AI genererer kode i skala, blir vinduet bredere og volumet av funn vokser raskere enn noe team kan manuelt fikse. Resultatet er en CVE-venteliste som utvides uendelig, prioritering som blir gjetting, og utviklere som bruker 4 til 8 timer per sårbarhet på arbeid som produserer null forretningsverdi.

Legg til styringsbruddene som følger, og bildet blir verre. Eierskap av fiksing er ofte uklart. Sikkerhet flagger en CVE, ingeniører kalder det en konfigurasjonsproblem, og operasjoner kalder det et kodeproblem. Jeg så dette mønsteret for 20 år siden, og det har ikke gått bort. AI gjør konsekvensene av denne uklarheten betydelig hardere å absorbere.

Skiftet som faktisk fungerer: Kontroller hva som kommer inn

Organisasjonene som kommer foran dette, har stoppet å prøve å skanne seg til sikkerhet og startet å kontrollere hva deres utviklere og AI-verktøy kan forbruke fra første sted. Mekanismen er en kuratert, politistyringskatalog over åpne kildekomponenter, bygget fra kilde, kontinuerlig overvåket og tjent som en privat intern registry som erstatter direkte trekk fra offentlige økosystemer som PyPI, npm eller Maven.

Dette tilnærmingen flytter sikkerhet til venstre i den mest bokstavelige forstand. Sårbarheter blokkeres på forbrukspunktet, før de noen gang kommer inn i byggepipeline. Utviklerne bruker samme verktøy de alltid har brukt. AI-kodestøtten løser avhengigheter fra samme styrt kilde. Sikkerhetsteamet setter policy én gang, og den politikken gjelder overalt, inkludert for kode en modell genererte klokken 02.00 uten at noen menneske gjennomgikk den.

Hva dette ser ut som i praksis

For sikkerhetsledere som jobber gjennom dette, er noen ting viktigere enn noe annet:

1. Definer din godkjente komponentsett før du skalerer AI-tilpasning. Hvis dine AI-kodetverktøy løser avhengigheter fra offentlige registre, eksisterer din godkjenningsprosess bare på papir. Etablér en styrt intern registry, rout alt gjennom den, og krever at komponenter bygges fra kilde med verifiserbar proveniens.
2. Behandle fiksing som en styrt prosess, ikke en billett-kø. Organisasjonene som holder pace med CVE-gjeld, er ikke de som flytter raskere på manuell fiksing. De har fjernet manuell fiksing fra ligningen. Når en fellesskaps-godkjent patch er tilgjengelig, blir den bygget inn i katalogen automatisk. Utviklerne får oppdateringen neste gang de trekker. Ingen tildele billett. Ingen venter 60 dager.
3. Kartlegg din AI-verktøykjede til dine etterlevelsesforpliktelser før du blir tvunget til det. Jeg har sett team bygge på AI-verktøy i måneder, bare for å treffen en vegg når en kunde krevde FedRAMP-justering eller SOC 2-bevis. Din kuraterte katalog er også din etterlevelses-audit-spor. SBOM’er og proveniensrekorder bør følge med hver komponent, ikke samles retroaktivt under tidspress.
4. Tildel tydelig eierskap på styringslaget, ikke billett-laget. Teamene som flytter raskest på fiksing, er ikke de med flest utviklere. De er de hvor sikkerhetsteamet eier policy, plattformteamet eier leveranse, og ingen venter på den andre til å handle.

Sikkerhet som muliggjør fremfor å blokkere

Det er en varig tro på at sikkerhet og utviklingshastighet er i grunnleggende konflikt. Jeg har aldri funnet det å være sant når sikkerhet er designet inn i prosessen fremfor å bli boltet på. Utviklere som arbeider fra et kuratert komponentsett, flytter faktisk raskere, fordi de ikke tviler på godkjenninger, venter på sikkerhetsgjennomganger eller rydder opp i sårbarheter som kunne ha blitt blokkert oppstrøms.

Organisasjonene som kommer til å navigere AI-drevet utvikling uten å akkumulere uholdbar sikkerhetsgjeld, er ikke de som kjører flest skannere. De er de som har tatt en bevisst beslutning om å styre hva som kommer inn i deres programvareforsyningskjede før det blir et hendelsesrespons-problem. Den beslutningen tilhører ledelsen. Verktøyene for å utføre det eksisterer i dag.