Proč kód generovaný umělou inteligencí ničí váš model správy zranitelností

Generátory kódu AI udělaly něco, co roky nástrojů DevOps nikdy úplně nezvládly: umožnily dodávat funkce za dny, které dříve trvaly týdny. Problém je, že rychlost se stejným způsobem vztahuje na zranitelnosti.

Během svých let v kybernetické bezpečnosti jsem sledoval, jak organizace procházejí stejným reaktivním vzorcem: objeví zranitelnost, spěchají pochopit její rozsah, hádají se o to, kdo je za opravu zodpovědný, a opraví ji týdny nebo měsíce později. Umělá inteligence tento vzorec nezměnila. Zrychlila ho na tempo, kde starý model již nemůže držet krok. Průměrná doba MTTR pro kritické CVE je nad 60 dní. Pomocí umělé inteligence při vývoji vám nejsou dány 60 dní. Máte nový kódový základ každou sprint.

Problém závislosti je nyní problémem umělé inteligence

Šestadevadesát procent podnikových aplikací zahrnuje open source komponenty. Většina z nich nebyla nikdy důkladně prověřena, pouze byly staženy z veřejných registrů, protože fungovaly a někdo je potřeboval odpoledne. Týmy bezpečnosti již roky ztrácejí půdu pod nohama a pomocníci pro kódování AI změnily pomalé krvácení v něco mnohem těžšího na kontrolu.

Když vývojář píše kód ručně, dělá úmyslné volby týkající se závislostí. Když model AI generuje kód, čerpá z toho, na čem byl vyškoleno. To často znamená halucinované balíčky, zastaralé verze nebo komponenty se známými CVE, kterým se model neměl důvod vyhnout. Kód vypadá čistě. Riziko je zabudováno v závislostním stromu, několik vrstev níže, neviditelné pro kohokoli, kdo se na něj nezaměřuje.

Seděl jsem na bezpečnostních kontrolách, kde týmy byly šokovány, když našly kritickou CVE v transitive závislosti balíčku, který schválily měsíce dříve. Balíček byl v pořádku. Co do něj bylo zahrnuto, nebylo. Tato dynamika se nyní odehrává v měřítku strojů, napříč stovkami vývojářů, kteří používají nástroje AI, které nemají žádný koncept bezpečnostní pozice vaší organizace.

Skenování po faktu není strategie

Prevalentní model pro bezpečnost open source software je skenovat a opravovat: spustit skener, třídit výsledky, přiřadit lístky a čekat. Tento model byl vždy reaktivní a v prostředí zrychleného vývoje AI je zcela překonán.

Skenery najdou problémy poté, co jsou již ve vašem kódu. Okno mezi zavedením a objevením je tam, kde žije vaše expozice. Když AI generuje kód ve velkém měřítku, toto okno se rozšiřuje a objem výsledků roste rychleji, než jakýkoli tým může manuálně opravit. Výsledkem je seznam CVE, který se neustále rozšiřuje, priorita se stává hádáním a vývojáři tráví 4 až 8 hodin na zranitelnost, aby provedli práci, která nevytváří žádnou obchodní hodnotu.

Přidejte k tomu governance rozpad a obraz se zhoršuje. Vlastnictví oprav je často nejasné. Bezpečnost označí CVE, inženýrství jej nazývá otázkou konfigurace a provoz jej nazývá problémem kódu. Viděl jsem tento vzorec před 20 lety a nezmizel. AI činí důsledky této nejednoznačnosti mnohem těžší na vstřebání.

Přepnutí, které skutečně funguje: Kontrolujte, co vstupuje

Organizace, které jsou před tímto problémem, přestaly se snažit skenovat se k bezpečnosti a začaly kontrolovat, co jejich vývojáři a nástroje AI mohou spotřebovat již na začátku. Mechanismus je kurátorský, řízený zásadami katalog open source komponent, postavený ze zdroje, průběžně monitorovaný a sloužený jako soukromý interní registr, který nahrazuje přímé stažení z veřejných ekosystémů, jako je PyPI, npm nebo Maven.

Tento přístup posouvá bezpečnost doleva v nejpřízemnějším smyslu. Zranitelnosti jsou blokovány v bodě spotřeby, předtím, než vstupují do build pipeline. Vývojáři používají stejné nástroje, které vždy používali. Pomocníci pro kódování AI řeší závislosti ze stejného řízeného zdroje. Tým bezpečnosti nastaví zásadu jednou a tato zásada se uplatňuje všude, včetně kódu, který model vygeneroval ve 2 hodiny ráno bez jakéhokoli lidského přezkumu.

To, jak vypadá v praxi

Pro bezpečnostní lídry, kteří pracují na tomto problému, existuje několik věcí, které jsou důležitější než cokoli jiného:

1. Definujte svůj schválený soubor komponent předtím, než budete škálovat přijetí AI. Pokud vaše nástroje pro kódování AI řeší závislosti z veřejných registrů, váš schvalovací proces existuje pouze na papíru. Založte řízený interní registr, směrujte vše skrze něj a vyžadujte, aby komponenty byly postaveny ze zdroje s ověřeným původem.
2. Zacházejte s opravami jako s řízeným procesem, ne jako s frontou lístků. Organizace, které zůstávají před dluhem CVE, nejsou ty, které se pohybují rychleji na manuálních opravách. Odstranily manuální opravu z rovnice. Když je k dispozici komunitně schválená oprava, je automaticky znovu postavena do katalogu. Vývojáři dostanou aktualizaci příště, kdy budou tahat. Nikdo neřiďte lístek. Nikdo nečeká 60 dní.
3. Mapujte svou nástrojovou řetězec AI na vaše compliance závazky předtím, než budete nuceni. Sledoval jsem týmy, které stavěly na nástrojích AI po měsíce, pouze aby narazily na zeď, když zákazník vyžadoval shodu s FedRAMP nebo důkaz SOC 2. Váš kurátorský katalog je také vaší compliance auditní stopou. SBOM a záznamy o původu by měly být dodány s každou komponentou, ne shromažďovány retroaktivně pod tlakem termínu.
4. Přiřaďte jasnou vlastnictví na úrovni governance, ne na úrovni lístků. Týmy, které se pohybují nejrychleji na opravách, nejsou ty, které mají nejvíce vývojářů. Jsou to ty, kde tým bezpečnosti vlastní zásady, tým platformy vlastní dodávku a ani jeden z nich nečeká na druhý, aby jednal.

Bezpečnost, která umožňuje spíše než blokuje

Existuje přetrvávající víra, že bezpečnost a vývojová rychlost jsou ve fundamentálním konfliktu. Nikdy jsem nenašel, že by tomu tak bylo, když je bezpečnost navržena do procesu, spíše než připevněna k němu. Vývojáři pracující z kurátorského souboru komponent se skutečně pohybují rychleji, protože nejsou second-guessing schválení, nečekají na bezpečnostní kontroly nebo nečistí zranitelnosti, které mohly být zablokovány na horní úrovni.

Organizace, které budou navigovat vývoj řízený AI bez akumulace neudržitelného bezpečnostního dluhu, nejsou ty, které běhají s nejvíce skenery. Jsou to ty, které učinily úmyslné rozhodnutí řídit, co vstupuje do jejich softwarového dodavatelského řetězce, předtím, než se stane problémem reakce na incident. To rozhodnutí patří vedení. Nástroje pro jeho provedení existují dnes.