Varför AI-genererad kod bryter din sårbarhetsmodell

AI-kodgenererare har gjort något som år av DevOps-verktyg aldrig riktigt lyckades med: de har gjort det möjligt att leverera funktioner på dagar som tidigare tog veckor. Problemet är att hastigheten gäller lika mycket för sårbarheterna.

Under mina år inom cybersäkerhet har jag sett organisationer gå igenom samma reaktiva mönster: upptäcka en sårbarhet, skynda sig för att förstå dess omfattning, argumentera om vem som äger lösningen och åtgärda den veckor eller månader senare. AI har inte förändrat det mönstret. Det har accelererat det till en takt där den gamla modellen inte längre kan hålla jämna steg. Genomsnittstiden för att åtgärda kritiska CVE är över 60 dagar. AI-assisterad utveckling ger dig inte 60 dagar. Den ger dig en ny kodbas varje sprint.

Det beroendeproblem som nu är ett AI-problem

96 procent av företagsapplikationer innehåller öppen källkodskomponenter. De flesta har aldrig granskats noggrant, utan har bara hämtats från offentliga register eftersom de fungerade och någon behövde dem samma eftermiddag. Säkerhetsteam har tappat mark under åren, och AI-kodhjälpmedel har förvandlat en långsam blödning till något mycket svårare att kontrollera.

När en utvecklare skriver kod manuellt, gör de medvetna val om beroenden. När en AI-modell genererar kod, hämtar den från vad den har tränats på. Det betyder ofta hallucinerade paket, föråldrade versioner eller komponenter med kända CVE som modellen inte hade någon anledning att undvika. Koden ser ren ut. Risken är inbäddad i beroendeträdet, flera lager ner, osynlig för alla som inte letar specifikt efter det.

Jag har suttit i säkerhetsgranskningar där team blev chockade över att hitta en kritisk CVE i en transitiv beroende av ett paket som de godkände månader tidigare. Paketet var okej. Vad det drog in var inte det. Den dynamiken sker nu på maskinskalig nivå, över hundratals utvecklare som använder AI-verktyg som inte har någon kunskap om organisationens säkerhetsläge.

Att skanna efteråt är inte en strategi

Den rådande modellen för öppen källkodssäkerhet är skanna-och-laga: kör en skanner, triagera resultaten, tilldela biljetter och vänta. Den modellen har alltid varit reaktiv, och i en AI-accelererad utvecklingsmiljö är den helt föråldrad.

Skannrar hittar problem efter att de redan är i din kod. Fönstret mellan introduktion och upptäckt är där din exponering lever. När AI genererar kod i stor skala, blir fönstret bredare och volymen av resultat växer snabbare än något team kan manuellt åtgärda. Resultatet är en CVE-kö som expanderar oändligt, prioritering som blir gissningslek och utvecklare som spenderar 4 till 8 timmar per sårbarhet på arbete som producerar noll affärsverdi.

Lägg till de governancebrott som följer och bilden blir värre. Ägandet av åtgärd är ofta oklart. Säkerhet flaggar en CVE, ingenjörer kallar det en konfigurationsfråga och drift kallar det ett kodproblem. Jag såg det mönstret för 20 år sedan och det har inte försvunnit. AI gör konsekvenserna av den oklarheten betydligt svårare att absorbera.

Den skift som faktiskt fungerar: Kontrollera vad som kommer in

De organisationer som kommer före det har slutat försöka skanna sig till säkerhet och börjat kontrollera vad deras utvecklare och AI-verktyg kan konsumera från början. Mekanismen är en kuraterad, policy-styrd katalog av öppen källkodskomponenter, byggd från källan, kontinuerligt övervakad och serverad som en privat intern register som ersätter direkt hämtning från offentliga ekosystem som PyPI, npm eller Maven.

Detta tillvägagångssätt flyttar säkerhet till vänster på det mest bokstavliga sättet. Sårbarheter blockeras vid konsumtionspunkten, innan de någonsin kommer in i byggröret. Utvecklare använder samma verktyg som de alltid har använt. AI-kodhjälpmedel löser beroenden från samma styrda källa. Säkerhetsteamet ställer in policy en gång, och den policyn gäller överallt, inklusive för kod som en modell genererar klockan 02.00 utan att någon människa granskar den.

Vad det här ser ut i praktiken

För säkerhetsledare som arbetar med det här, är några saker viktigare än allt annat:

1. Definiera din godkända komponentuppsättning innan du skalar upp AI-antagandet. Om dina AI-kodverktyg löser beroenden från offentliga register, existerar din godkännandeprocess bara på papper. Etablera en styrd intern register, dirigera allt genom den och kräv att komponenter byggs från källan med verifierbar proveniens.
2. Behandla åtgärd som en hanterad process, inte en biljettkö. De organisationer som håller jämna steg med CVE-skulden är inte de som flyttar snabbare på manuell åtgärd. De har tagit bort manuell åtgärd från ekvationen. När en community-godkänd lapp är tillgänglig, byggs den om automatiskt in i katalogen. Utvecklare får uppdateringen nästa gång de hämtar. Ingen tilldelar en biljett. Ingen väntar 60 dagar.
3. Mappa din AI-verktygskedja till dina efterlevnadsskyldigheter innan du tvingas till det. Jag har sett team bygga på AI-verktyg i månader, bara för att stöta på ett vägg när en kund krävde FedRAMP-justering eller SOC 2-bevis. Din kuraterade katalog är också din efterlevnadsgranskningslogg. SBOM och proveniensposter bör följa med varje komponent, inte sättas samman retroaktivt under tidsbegränsning.
4. Tilldela tydligt ägande på governance-nivå, inte biljett-nivå. De team som flyttar snabbast på åtgärd är inte de med flest utvecklare. De är de där säkerhetsteamet äger policy, plattformsteamet äger leverans och ingen av dem väntar på den andra att agera.

Säkerhet som möjliggör snarare än blockerar

Det finns en bestående tro att säkerhet och utvecklingshastighet är i grundläggande konflikt. Jag har aldrig funnit att det är sant när säkerhet är designad in i processen snarare än skruvad på den. Utvecklare som arbetar från en kuraterad komponentuppsättning flyttar faktiskt snabbare, eftersom de inte tvivlar på godkännanden, väntar på säkerhetsgranskningar eller rensar sårbarheter som kunde ha blockats uppströms.

De organisationer som kommer att navigera AI-driven utveckling utan att ackumulera ohållbar säkerhetsskuld är inte de som kör de flesta skannrar. De är de som har tagit ett medvetet beslut att styra vad som kommer in i deras programvaruleveranskedja innan det blir ett incident-svar-problem. Det beslutet tillhör ledningen. Verktygen för att genomföra det finns idag.