Waarom AI-gegenereerde code uw kwetsbaarheidsbeheersmodel breekt

AI-codegeneratoren hebben iets gedaan dat jaren van DevOps-hulpmiddelen nooit helemaal zijn gelukt: ze hebben het mogelijk gemaakt om functies te verzenden in dagen die eerder weken duurden. Het probleem is dat de snelheid evenzeer van toepassing is op de kwetsbaarheden.

In de loop van mijn jaren in cybersecurity heb ik gezien hoe organisaties hetzelfde reactieve patroon doorlopen: een kwetsbaarheid ontdekken, haasten om de omvang ervan te begrijpen, discussiëren over wie de verantwoordelijkheid voor de oplossing heeft en deze weken of maanden later oplossen. AI heeft dat patroon niet veranderd. Het heeft het versneld tot een tempo waarbij het oude model niet langer kan bijhouden. De gemiddelde MTTR voor kritieke CVE’s is meer dan 60 dagen. AI-geassisteerde ontwikkeling geeft u geen 60 dagen. Het geeft u een nieuwe codebasis bij elke sprint.

Het afhankelijkheidsprobleem is nu een AI-probleem

Zesennegentig procent van de ondernemingsapplicaties bevat open source-componenten. De meeste zijn nooit grondig gecontroleerd, maar zijn gewoon opgehaald uit openbare registers omdat ze werkten en iemand ze die middag nodig had. Beveiligingsteams hebben hier jarenlang aan verloren en AI-gecodeerde assistenten hebben een langzaam bloeden omgezet in iets veel moeilijker te controleren.

Wanneer een ontwikkelaar code handmatig schrijft, maakt hij bewuste keuzes over afhankelijkheden. Wanneer een AI-model code genereert, haalt het uit alles waarop het is getraind. Dat betekent vaak gehallucineerde pakketten, verouderde versies of componenten met bekende CVE’s die het model geen reden had om te vermijden. De code ziet er schoon uit. Het risico is ingebed in de afhankelijkheidsboom, enkele lagen diep, onzichtbaar voor iedereen die niet specifiek naar het kijken.

Ik heb in beveiligingsbeoordelingen gezeten waarin teams geschokt waren om een kritieke CVE te vinden in een transitive afhankelijkheid van een pakket dat ze maanden eerder hadden goedgekeurd. Het pakket was in orde. Wat het inpakte, was dat niet. Die dynamiek gebeurt nu op machineschaal, over honderden ontwikkelaars die AI-hulpmiddelen gebruiken die geen concept van uw organisatiebeveiligingspostuur hebben.

Scannen na de feiten is geen strategie

Het overheersende model voor open source-softwarebeveiliging is scannen-en-patchen: een scanner uitvoeren, de resultaten triëren, tickets toewijzen en wachten. Dat model is altijd reactief geweest en in een AI-versnelde ontwikkelomgeving is het volledig ingehaald.

Scanners vinden problemen nadat ze al in uw code zitten. Het venster tussen introductie en ontdekking is waar uw blootstelling leeft. Wanneer AI code op grote schaal genereert, wordt dat venster breder en groeit het volume van de resultaten sneller dan enig team handmatig kan oplossen. Het resultaat is een CVE-achterstand die oneindig uitbreidt, prioritering die tot gokwerk wordt en ontwikkelaars die 4 tot 8 uur per kwetsbaarheid besteden aan werk dat geen enkele bedrijfswaarde oplevert.

Voeg de governance-breuken toe die volgen en het beeld wordt erger. De eigenaar van de oplossing is vaak onduidelijk. Beveiliging markeert een CVE, engineering noemt het een configuratievraag en operations noemt het een codeprobleem. Ik zag dit patroon 20 jaar geleden en het is niet verdwenen. AI maakt de gevolgen van die ambiguïteit aanzienlijk moeilijker te absorberen.

De verschuiving die werkt: controleer wat erin gaat

De organisaties die hierin voorop lopen, hebben opgehouden met scannen naar veiligheid en zijn begonnen met het controleren van wat hun ontwikkelaars en AI-hulpmiddelen kunnen consumeren in de eerste plaats. Het mechanisme is een gecureerde, beleidsgebonden catalogus van open source-componenten, opgebouwd vanuit de bron, continu gemonitord en aangeboden als een privé-interne register die directe pulls uit openbare ecosystemen zoals PyPI, npm of Maven vervangt.

Deze aanpak verschuift beveiliging naar links in de meest letterlijke zin. Kwetsbaarheden worden geblokkeerd op het moment van consumptie, voordat ze ooit de build-pipeline binnenkomen. Ontwikkelaars gebruiken dezelfde hulpmiddelen die ze altijd hebben gebruikt. AI-gecodeerde assistenten lossen afhankelijkheden op vanuit dezelfde gereguleerde bron. Het beveiligingsteam stelt beleid eenmaal vast en dat beleid is van toepassing overal, inclusief op code die door een model op 2 uur ‘s nachts is gegenereerd zonder dat iemand het heeft beoordeeld.

Hoe dit er in de praktijk uitziet

Voor beveiligingsleiders die hiermee werken, zijn een aantal dingen belangrijker dan alles anders:

1. Definieer uw goedgekeurde componentenset voordat u AI-adoptie opschalt. Als uw AI-codehulpmiddelen afhankelijkheden oplossen vanuit openbare registers, bestaat uw goedkeuringsproces alleen op papier. Stel een gereguleerd intern register in, routeer alles via dit register en vereis dat componenten vanuit de bron worden opgebouwd met verifieerbare herkomst.
2. Behandel oplossing als een gereguleerd proces, niet als een ticketwachtrij. De organisaties die voorop lopen in het oplossen van CVE-schulden, zijn niet sneller in het oplossen van handmatige oplossingen. Ze hebben handmatige oplossing uit de vergelijking verwijderd. Wanneer een community-goedgekeurde patch beschikbaar is, wordt deze automatisch opnieuw opgebouwd in de catalogus. Ontwikkelaars krijgen de update de volgende keer dat ze iets ophalen. Niemand wijst een ticket toe. Niemand wacht 60 dagen.
3. Kaart uw AI-hulpmiddelenketen naar uw nalevingsverplichtingen voordat u daartoe wordt gedwongen. Ik heb teams zien bouwen op AI-hulpmiddelen gedurende maanden, alleen om tegen een muur te lopen wanneer een klant FedRAMP-overeenstemming of SOC 2-bewijs vereiste. Uw gecureerde catalogus is ook uw nalevingsaudittrail. SBOM’s en herkomstrecords moeten bij elke component worden geleverd, niet retroactief onder deadline-druk worden samengesteld.
4. Wijs duidelijke eigenaar toe op het governance-niveau, niet op het ticketniveau. De teams die het snelst oplossen, zijn niet die met de meeste ontwikkelaars. Ze zijn degenen waar het beveiligingsteam het beleid in handen heeft, het platformteam de levering in handen heeft en geen van beiden wacht op de ander om te handelen.

Beveiliging die in staat stelt in plaats van blokkeert

Er is een hardnekkig geloof dat beveiliging en ontwikkelings snelheid fundamenteel met elkaar in conflict zijn. Ik heb nooit gevonden dat dit waar is wanneer beveiliging is ingebouwd in het proces in plaats van eraan vastgemaakt te zijn. Ontwikkelaars die werken vanuit een gecureerde componentenset, bewegen eigenlijk sneller, omdat ze geen goedkeuringen twijfelen, geen beveiligingsbeoordelingen wachten of kwetsbaarheden oplossen die stroomopwaarts hadden kunnen worden geblokkeerd.

De organisaties die AI-gedreven ontwikkeling zonder het accumuleren van niet-houdbare beveiligingsschulden zullen navigeren, zijn niet die met de meeste scanners. Ze zijn degenen die een bewuste beslissing hebben genomen om te reguleren wat hun softwareleverantieketen binnenkomt voordat het een incidentresponsprobleem wordt. Die beslissing behoort tot het leiderschap. De hulpmiddelen om dit uit te voeren, bestaan vandaag.