Dlaczego kod generowany przez AI niszczy Twój model zarządzania lukami w zabezpieczeniach

Generatory kodu AI zrobili coś, czego przez lata nie udało się osiągnąć za pomocą narzędzi DevOps: umożliwiły wydanie funkcji w ciągu dni, które wcześniej zajmowały tygodnie. Problem polega na tym, że prędkość ma zastosowanie równie dobrze do luk w zabezpieczeniach.

Przez lata pracy w branży cyberbezpieczeństwa obserwowałem, jak organizacje przechodzą przez ten sam reaktywny wzorzec: odkrywają lukę, szukają jej zakresu, spierają się o to, kto jest odpowiedzialny za naprawę, i naprawiają ją po tygodniach lub miesiącach. AI nie zmieniło tego wzorca. Przyspieszyło go do tempa, w którym stare modele nie mogą już dotrzymać kroku. Średni czas naprawy (MTTR) dla krytycznych luk w zabezpieczeniach wynosi ponad 60 dni. Rozwój wspomagany przez AI nie daje Ci 60 dni. Daje Ci nową bazę kodu za każdym sprintem.

Problem zależności jest teraz problemem AI

96% aplikacji korporacyjnych zawiera składniki open source. Większość z nich nie była dokładnie sprawdzona, po prostu pobrana z publicznych rejestrów, ponieważ działała i ktoś potrzebował jej tego popołudnia. Zespoły bezpieczeństwa traciły grunt pod nogami przez lata, a asystenci kodowania AI przekształcili powolne krwawienie w coś znacznie trudniejszego do kontrolowania.

Gdy deweloper pisze kod ręcznie, podejmuje świadome decyzje dotyczące zależności. Gdy model AI generuje kod, pobiera go z tego, czego się nauczył. Często oznacza to wyobrażone pakiety, przestarzałe wersje lub składniki z znanymi lukami w zabezpieczeniach, których model nie miał powodu unikać. Kod wygląda czysto. Ryzyko jest zakodowane w drzewie zależności, kilka warstw niżej, niewidoczne dla nikogo, kto nie szuka konkretnie.

Siedziałem na przeglądach bezpieczeństwa, gdzie zespoły były zaskoczone, znajdując krytyczną lukę w zależności przekazywanej pakietu, który został zatwierdzony miesiące wcześniej. Pakiet był w porządku. To, co on ściągał, nie było. Ta dynamika dzieje się teraz w skali maszynowej, wśród setek deweloperów korzystających z narzędzi AI, które nie mają pojęcia o Twojej organizacyjnej postawie wobec bezpieczeństwa.

Skanowanie po fakcie nie jest strategią

Dominujący model bezpieczeństwa oprogramowania open source to skanowanie i łatanie: uruchom skaner, rozpoznanie wyników, przypisanie biletów i czekanie. Ten model zawsze był reaktywny, a w środowisku rozwoju przyspieszonego przez AI jest zupełnie wyprzedzony.

Skanery znajdują problemy dopiero po tym, jak są już w Twoim kodzie. Okno między wprowadzeniem a odkryciem to miejsce, w którym żyje Twoje narażenie. Gdy AI generuje kod w skali, to okno staje się szersze, a objętość wyników rośnie szybciej niż jakikolwiek zespół może ręcznie naprawić. Wynikiem jest zapas luk w zabezpieczeniach, który rośnie nieograniczenie, priorytetyzacja staje się zgadywanką, a deweloperzy spędzają 4 do 8 godzin na lukę na pracy, która nie daje żadnej wartości biznesowej.

Dodaj do tego awarie w zarządzaniu, a obraz staje się gorszy. Własność naprawy jest często niejasna. Zespół bezpieczeństwa sygnalizuje lukę, inżynieria nazywa to pytaniem konfiguracyjnym, a operacje nazywają to problemem kodu. Widziałem ten wzorzec 20 lat temu i nie zniknął. AI sprawia, że konsekwencje tej niejasności stają się znacznie trudniejsze do zaakceptowania.

Przesunięcie, które naprawdę działa: Kontroluj to, co wchodzi

Organizacje, które wyprzedzają to, przestały próbować skanować się do bezpieczeństwa i zaczęły kontrolować to, co ich deweloperzy i narzędzia AI mogą spożywać od samego początku. Mechanizm to kuratoryjny, zarządzany przez politykę katalog składników open source, zbudowany z źródła, ciągle monitorowany i dostarczany jako prywatny wewnętrzny rejestr, który zastępuje bezpośrednie pobieranie z publicznych ekosystemów takich jak PyPI, npm lub Maven.

Ten podejście przesuwa bezpieczeństwo w lewo w najbardziej literalnym sensie. Luki w zabezpieczeniach są blokowane w punkcie konsumpcji, zanim kiedykolwiek wejdą do potoku budowania. Deweloperzy używają tych samych narzędzi, których zawsze używali. Asystenci kodowania AI rozwiązują zależności z tego samego zarządzanego źródła. Zespół bezpieczeństwa ustawia politykę raz, a ta polityka ma zastosowanie wszędzie, łącznie z kodem wygenerowanym przez model o 2 nad ranem bez żadnego przeglądu przez człowieka.

Wygląda to tak w praktyce

Dla liderów bezpieczeństwa pracujących nad tym, kilka rzeczy ma większe znaczenie niż cokolwiek innego:

1. Zdefiniuj swój zatwierdzony zestaw składników przed skalowaniem wdrożenia AI. Jeśli Twoje narzędzia do kodowania AI rozwiązują zależności z publicznych rejestrów, Twój proces zatwierdzania istnieje tylko na papierze. Ustal zarządzany wewnętrzny rejestr, przekieruj wszystko przez niego i wymagaj, aby składniki były budowane z źródła z weryfikowalnym pochodzeniem.
2. Traktuj naprawę jako zarządzany proces, a nie kolejkę biletów. Organizacje, które pozostają przed lukami w zabezpieczeniach, nie poruszają się szybciej w ręcznej naprawie. Usunęły ręczną naprawę z równania. Gdy dostępna jest zatwierdzona poprawka społeczności, jest automatycznie odbudowana w katalogu. Deweloperzy otrzymują aktualizację następnym razem, gdy ją ściągną. Nikt nie przydziela biletu. Nikt nie czeka 60 dni.
3. Mapuj swoją łańcuch narzędzi AI do Twoich zobowiązań związanych z zgodnością przed tym, zanim będziesz zmuszony. Obserwowałem zespoły, które budowały na narzędziach AI przez miesiące, tylko po to, by uderzyć w ścianę, gdy klient wymagał zgodności z FedRAMP lub dowodów SOC 2. Twój kuratoryjny katalog jest również Twoim śladem audytu zgodności. SBOM i rekordy pochodzenia powinny być dostarczane z każdym składnikiem, a nie montowane retroaktywnie pod presją terminu.
4. Przypisz wyraźną własność na poziomie zarządzania, a nie poziomie biletu. Zespoły, które poruszają się najszybciej w naprawie, nie są tymi z największą ilością deweloperów. Są to zespoły, w których zespół bezpieczeństwa posiada politykę, zespół platformy posiada dostarczenie, i żaden z nich nie czeka na drugiego, aby działać.

Bezpieczeństwo, które umożliwia, a nie blokuje

Istnieje utrwalone przekonanie, że bezpieczeństwo i prędkość rozwoju są w fundamentalnej sprzeczności. Nigdy nie znalazłem, aby to było prawdą, gdy bezpieczeństwo jest zaprojektowane w proces, a nie przykręcane do niego. Deweloperzy pracujący z kuratoryjnego zestawu składników naprawdę poruszają się szybciej, ponieważ nie wahają się nad zatwierdzeniami, nie czekają na przeglądy bezpieczeństwa ani nie czyszczą luk w zabezpieczeniach, które mogłyby zostać zablokowane wcześniej.

Organizacje, które będą nawigować rozwój napędzany przez AI bez gromadzenia nieznośnego długu bezpieczeństwa, nie są tymi, które uruchamiają najwięcej skanerów. Są to te, które podjęły świadomą decyzję, aby zarządzać tym, co wchodzi do ich łańcucha dostaw oprogramowania, zanim stanie się problemem reagowania na incydenty. Ta decyzja należy do kierownictwa. Narzędzia do jej wykonania istnieją już dzisiaj.