Bezpieczeństwo AI oparte na niejawności przestało działać, a obrońcy mierzą się z trudniejszym problemem

Bezpieczeństwo AI oparte na niejawności załamało się w 2026 roku, gdy agenci znajdowali zaniedbane luki, przyspieszali rozwój exploitów i docierali do systemów chronionych głównie przez specjalistyczną złożoność.

Bezpośrednie dowody obejmują zapomniane komponenty Windows, szeroko analizowane biblioteki open source oraz sterowniki przemysłowe obsługujące kluczowe usługi. Systemy te różnią się technicznie, lecz łączyła je jedna dyskretna forma obrony. Atakujący potrzebowali rzadkiej wiedzy, znacznej cierpliwości albo wystarczającej zachęty ekonomicznej, aby je badać.

Wykrywanie podatności przez AI zmienia tę kalkulację. Modele potrafią interpretować nieznany kod, wyjaśniać własnościowe protokoły, tworzyć środowiska testowe i automatyzować powtarzalne rozpoznanie. Rezultatem nie jest nowa zasada bezpieczeństwa. To usunięcie tarcia, które pozwalało organizacjom odkładać stosowanie starych zasad.

Stawia to obrońców przed trudnym odwróceniem sytuacji. Znajdowanie słabości staje się tańsze i szybsze, podczas gdy weryfikacja poprawek, koordynowanie ujawnień, testowanie systemów operacyjnych oraz zmiana błędnych praktyk programistycznych pozostają procesami uporczywie zależnymi od ludzi.

Pytanie nie brzmi już, czy ukryte słabości wyjdą na jaw. Brzmi ono: czy obrońcy zdołają usunąć warunki, które je tworzą, zanim zautomatyzowane wykrywanie uczyni każdy zaniedbany system ekonomicznie opłacalnym celem.

Bezpieczeństwo AI oparte na niejawności straciło swoją ekonomiczną fosę

AI nie podważyła bezpieczeństwa opartego na niejawności. Usunęła niedobór pracy, który pozwalał organizacjom udawać, że niejawność działa.

Bezpieczeństwo oparte na niejawności opisuje założenie projektowe lub operacyjne, które zależy od tego, czy architektura, interfejsy albo słabości pozostają trudne do odkrycia. Nigdy nie było uznawane za rozsądny podstawowy mechanizm ochrony. Mimo to niejawność zapewniała praktyczną ochronę, gdy badanie nieznanego systemu wymagało deficytowych specjalistów i tygodni skoncentrowanej pracy.

Ta ochrona działała jak ekonomiczna fosa. Podatny komponent mógł pozostać nietknięty, ponieważ atakujący mogli zarobić więcej, celując w znane oprogramowanie. Własnościowy protokół mógł zniechęcać osoby z zewnątrz ze względu na ograniczoną dokumentację. Stary podsystem mógł uniknąć kontroli, bo niewielu badaczy pamiętało o jego istnieniu.

Oryginalna analiza bezpieczeństwa opublikowana 13 września pokazuje, jak zmieniła się ta równowaga. Dostawcy i niezależni badacze wykorzystują obecnie agentów AI do badania niejasnego, starego i intensywnie analizowanego oprogramowania. Atakujący używają pokrewnych możliwości do analizowania poprawek i tworzenia exploitów.

Brett Leatherman, zastępca dyrektora FBI Cyber Division, opisał modele znajdujące istotne podatności w komponentach open source, które społeczności analizowały przez dekadę. Niektóre z tych bibliotek mają podobno działać w znacznej części infrastruktury internetowej.

Nie oznacza to, że AI samodzielnie rozumie każdy system albo niezawodnie tworzy działający exploit. Oznacza to, że badacze mogą wejść na nieznany teren bez zaczynania od zera. Model może podsumować kod, przetłumaczyć dokumentację, wskazać prawdopodobne granice zaufania i wygenerować skrypty do testowania hipotez.

Agentowe systemy AI rozszerzają tę pomoc na sekwencję zadań. Agent może sprawdzać pliki, uruchamiać narzędzia, analizować wyniki, zmieniać podejście i kontynuować pracę, aż osiągnie określony cel. Operatorzy nadal wyznaczają cele i zapewniają infrastrukturę, lecz maszyna przejmuje znaczną część powtarzalnej pracy.

Dlatego wykrywanie podatności przez AI wywiera presję zarówno na oprogramowanie zamknięte, jak i otwarte. Publiczny kod ułatwia bezpośrednią analizę, lecz zamknięte oprogramowanie nadal ujawnia pliki binarne, firmware, zachowanie sieciowe, dokumentację, poprawki i artefakty konfiguracji. Modele mogą korelować te fragmenty z szybkością, która zmienia ekonomię inżynierii wstecznej.

Dustin Childs, który kieruje Zero Day Initiative firmy Trend Micro, wskazał na zapomniane technologie uwzględnione w rekordowej wrześniowej publikacji poprawek Microsoftu. Dotknięte komponenty obejmowały klienta Telnet, Windows RNDIS, NFS Portmapper oraz Link Layer Topology Discovery.

Ich wiek ma znaczenie, ponieważ ilustruje dawny układ. Starsze komponenty mogły przetrwać bez stałej uwagi ekspertów, gdy niewiele osób miało zainteresowanie lub przygotowanie, by je badać. AI daje ciekawskim badaczom i atakującym niedrogiego przewodnika po właśnie tych zaniedbanych obszarach.

Niejawność nadal powoduje niedogodności. Nieudokumentowany protokół może spowolnić agenta, a własnościowe urządzenie może ograniczyć dostępne dowody. Jednak niedogodność nie jest autoryzacją, izolacją, uwierzytelnianiem ani bezpieczeństwem pamięci. Nie można jej ufać jako mechanizmowi powstrzymującemu uporczywe zautomatyzowane dochodzenie.

Fosa przesunęła się więc z ukrytej wiedzy na weryfikowalne zabezpieczenia. Systemy potrzebują silnych granic tożsamości, minimalnej ekspozycji, bezpiecznych ustawień domyślnych, przetestowanej segmentacji oraz projektów, które pozostają bezpieczne, gdy ich działanie staje się znane.

To ugruntowana zasada bezpieczeństwa znana jako zasada Kerckhoffsa, stosowana poza kryptografią. System powinien pozostać bezpieczny nawet wtedy, gdy przeciwnik rozumie, jak działa, z wyjątkiem właściwie zarządzanych sekretów, takich jak klucze kryptograficzne.

AI nadaje tej zasadzie operacyjną pilność. Dokumentacja nie musi już być starannie opublikowana, aby zachowanie systemu stało się zrozumiałe. Wystarczająco dużo rozproszonych dowodów może dziś dać agentowi użyteczną mapę.

Pierwszym punktem presji jest zapomniane oprogramowanie

Systemy pod największą presją nie zawsze są najnowsze ani najcenniejsze. Są to te, których bezpieczeństwo zależało od tego, że nikt nie przyglądał się im uważnie.

Tradycyjne badania podatności obejmują kosztowne etapy. Badacze muszą poznać bazę kodu, odtworzyć jej środowisko działania, zrozumieć jej założenia i oddzielić znaczące słabości od nieszkodliwych anomalii. Kroki te często wymagają więcej czasu niż samo znalezienie podejrzanego kodu.

AI może skrócić kilka z nich. Potrafi pisać środowiska testowe, śledzić przepływy danych, porównywać powiązane implementacje i wyjaśniać nieznane wzorce programowania. Może też kontynuować skanowanie, gdy zadanie staje się monotonne, co ma znaczenie, ponieważ ludzka uwaga jest ograniczona.

Nie gwarantuje to użytecznych wyników. Modele generują fałszywe alarmy, błędnie rozumieją kontekst i czasem fabrykują techniczne wyjaśnienia. Mimo to niskokosztowa pomoc pozwala operatorom testować więcej celów i porzucać nieproduktywne ścieżki bez zużywania takiej samej ilości czasu specjalistów.

Szersze poszukiwania zmieniają to, jakie oprogramowanie staje się atrakcyjne. Opiekunowie starych bibliotek, niszowych produktów dla przedsiębiorstw, firmware urządzeń i słabo udokumentowanych usług wewnętrznych nie mogą już zakładać, że atakujący skupią się gdzie indziej. Ich rabat za niejawność maleje.

Ta sama presja dotyczy znanych podatności oczekujących na wdrożenie. Gdy dostawca publikuje poprawkę, atakujący mogą porównać wersje załatane i niezałatane. Proces ten, nazywany patch diffing, ujawnia, który kod się zmienił, i pomaga badaczom odtworzyć podstawową słabość.

AI przyspiesza patch diffing, interpretując zmianę, proponując dane wejściowe wyzwalające problem i generując kod testowy. Badania Anthropic nad szybkim rozwojem exploitów analizowały, jak modele mogą badać niedawno ujawnione podatności i wspierać eksploatację, zanim każda organizacja zainstaluje poprawkę.

Skraca to lukę wdrożeniową, czyli okres między udostępnieniem poprawki a jej faktycznym otrzymaniem przez użytkowników. Luka ta zawsze była niebezpieczna. Zautomatyzowana analiza sprawia, że każda godzina w jej ramach jest cenniejsza dla atakujących.

Niedawna kampania wykorzystująca zestaw exploitów oparty na Chromium pokazała ryzyko operacyjne. Grupy szpiegowskie miały wykorzystywać podatności po opublikowaniu poprawki przez projekt nadrzędny, lecz przed dotarciem stabilnych wydań podrzędnych do wszystkich użytkowników. AI niekoniecznie odpowiadała za każdy element tej kampanii, ale wzmacnia metodę, która czyni takie wyczucie czasu skutecznym.

Open source nie jest w tym modelu wyjątkowo skazane na zagładę. Publiczny przegląd daje obrońcom dostęp do tego samego kodu i umożliwia szeroką współpracę. Głębszym problemem jest asymetria wykonania. Atakujący mogą testować wiele możliwości, podczas gdy opiekunowie muszą weryfikować zgłoszenia, unikać regresji, koordynować wydania i wspierać użytkowników.

Zamknięte oprogramowanie mierzy się z pokrewnym problemem przy mniejszej widoczności publicznej. Badacz wspierany przez AI może nadal analizować pliki binarne, interfejsy, zachowanie błędów, pakiety aktualizacji, aplikacje mobilne i firmware urządzeń. Dostawcy nie mogą zakładać, że ukrywanie kodu źródłowego zachowuje trwałą tajemnicę techniczną.

Pozostawia to opiekunów z rosnącym problemem napływu zgłoszeń. Więcej raportów wygenerowanych przez AI nie oznacza automatycznie większej liczby potwierdzonych podatności. Część zgłoszeń będzie duplikatami, niepełnymi twierdzeniami lub wiarygodnie wyglądającymi błędami wygenerowanymi bez odpowiedniego testowania.

Ta fala może pochłonąć tych samych ekspertów, którzy są potrzebni do naprawiania rzeczywistych słabości. Małe projekty open source są szczególnie narażone, ponieważ szeroko wdrożony komponent może mieć zaledwie kilku opiekunów. Zautomatyzowane wykrywanie może skalować się niezależnie od ich zdolności do przeglądu.

Organizacje muszą więc mierzyć więcej niż liczbę raportów. Przydatne wskaźniki obejmują czas do odtworzenia problemu, czas do określenia jego wagi, udział zduplikowanych ustaleń, czas weryfikacji poprawki oraz powtarzalność według klasy podatności.

Te miary odróżniają poprawę bezpieczeństwa od samej aktywności. Zespół zamykający setki zgłoszeń niskiego ryzyka, podczas gdy powtarzający się błąd wstrzykiwania pozostaje w jego procesie programistycznym, działa szybciej, nie ograniczając przyszłej ekspozycji.

Systemy przemysłowe tracą barierę specjalistycznej wiedzy

Technologia operacyjna pokazuje, dlaczego załamanie niejawności niesie konsekwencje wykraczające poza zwykłe utrzymanie oprogramowania.

Technologia operacyjna, czyli OT, kontroluje procesy fizyczne, takie jak uzdatnianie wody, linie produkcyjne, dystrybucja paliw i urządzenia elektryczne. Przemysłowe systemy sterowania często łączą sprzęt o długim cyklu życia, własnościowe protokoły, specjalistyczne oprogramowanie inżynierskie i rygorystyczne wymagania dotyczące dostępności.

To środowisko historycznie zniechęcało wielu atakujących. Zrozumienie programowalnego sterownika logicznego, czyli PLC, wymagało wiedzy o procesach przemysłowych i komunikacji specyficznej dla urządzenia. Testowanie teorii mogło również grozić zakłóceniem fizycznych operacji.

John Hultquist, główny analityk w Google Threat Intelligence Group, argumentował, że specjalistyczna wiedza zapewniała znaczną część praktycznej ochrony systemów przemysłowych. AI ułatwia zdobywanie, organizowanie i stosowanie tej wiedzy.

Ryzyko stało się konkretne w sierpniu, gdy pięć agencji Stanów Zjednoczonych ostrzegło przed atakującymi używającymi skryptów wspieranych przez AI przeciwko dostępnym z internetu sterownikom Siemens S7 Series PLC. Dotknięte środowiska obejmowały obiekty wodociągowe, produkcyjne, energetyczne, chemiczne, rolnicze i komercyjne.

Według federalnego ostrzeżenia o zagrożeniu, operatorzy łączyli publiczne biblioteki automatyki przemysłowej z asystentami programowania AI. Ich narzędzia imitowały legalne oprogramowanie monitorujące i wchodziły w interakcje z pamięcią PLC, danymi konfiguracji i logiką drabinkową.

Logika drabinkowa to graficzny język programowania używany do definiowania zachowania sterowania przemysłowego. Nieautoryzowane zmiany mogą wpływać na rzeczywiste urządzenia, a nie jedynie zmieniać informacje na ekranie.

Zgłoszona aktywność zmniejszyła poziom wiedzy potrzebnej do pracy z protokołem S7comm używanym przez te sterowniki. AI mogła pomóc operatorom tworzyć lub modyfikować skrypty na podstawie informacji publicznych. Nie umożliwiała dostępu do odizolowanego sterownika ani nie omijała każdej prawidłowo skonfigurowanej kontroli bezpieczeństwa.

Ekspozycja pozostawała warunkiem umożliwiającym atak. Atakujący mieli podobno wyszukiwać sterowniki PLC podłączone do internetu, działające na przestarzałym oprogramowaniu lub chronione domyślnymi poświadczeniami. Słaba segmentacja dawała następnie wygenerowanym skryptom drogę do funkcji krytycznych.

To rozróżnienie ma znaczenie. Nazywanie tych incydentów „atakami AI” może odwracać uwagę organizacji od zabezpieczeń, które już potrafią wdrożyć. Usunięcie bezpośredniego dostępu z internetu, zmiana domyślnych poświadczeń, aktualizowanie wspieranych urządzeń oraz oddzielenie sieci inżynieryjnych nadal są niezbędne.

Bezpieczeństwo AI oparte na niejawności zawodzi najbardziej widocznie wtedy, gdy organizacje mylą nieznajomość z izolacją. Rzadki protokół nie zapobiega dostępowi. Własnościowy interfejs inżynieryjny nie uwierzytelnia użytkownika. Nieudokumentowana komenda nie powstrzyma modelu wyszkolonego w porównywaniu przykładów i testowaniu odpowiedzi.

Jednocześnie obrońcy nie mogą aktualizować środowisk przemysłowych tak jak laptopów konsumenckich. Zakłady mogą planować konserwację z wielomiesięcznym wyprzedzeniem. Dostawcy mogą potrzebować certyfikować zmiany. Starsze sterowniki mogą działać przez dekady, a ich wymiana może wymagać znacznych prac fizycznych.

Dostępność tworzy również dylemat testowania. Błędne działanie obronne może przerwać produkcję lub uszkodzić sprzęt. Atakujący mają mniej powodów, by unikać zakłóceń, podczas gdy operatorzy muszą weryfikować każdą zmianę pod kątem ograniczeń bezpieczeństwa i operacyjnych.

Ta asymetria wyjaśnia, dlaczego sama lepsza detekcja nie wystarcza. Właściciele potrzebują dokładnych inwentaryzacji zasobów, kontrolowanego dostępu zdalnego, monitorowania sieci oraz wymuszonych ścieżek komunikacji. Powinni identyfikować każdy ruch do PLC z nieinżynieryjnej stacji roboczej i badać zapisy poza zatwierdzonymi oknami zmian.

Dioda danych, która pozwala na przepływ informacji tylko w jednym kierunku, może chronić środowiska, w których telemetria musi wychodzić, lecz polecenia nigdy nie muszą wracać. Silna segmentacja może ograniczyć skutki przejęcia stacji roboczej lub użycia wygenerowanego skryptu.

Są to zabezpieczenia architektoniczne, a nie próby ukrycia systemu. Zakładają, że atakujący rozumieją sprzęt, a mimo to odmawiają im użytecznej drogi dostępu.

Wniosek dotyczy również oprogramowania korporacyjnego. System nie powinien pozostawać bezpieczny wyłącznie dlatego, że jego wewnętrzne API jest nieudokumentowane lub panel administracyjny korzysta z nieprzewidywalnego adresu. AI systematycznie przekształca te niedogodności w krótkie zadania badawcze.

Odkrywanie podatności przez AI wyprzedza ich naprawianie

Podstawowym kompromisem w bezpieczeństwie nie jest już odkrywanie kontra niewiedza. Jest nim odkrywanie z szybkością maszyn kontra naprawa ograniczona ludzkimi możliwościami.

Katie Moussouris, założycielka i CEO Luta Security, wskazała triage, ustalanie priorytetów i naprawę jako rzeczywiste wąskie gardła. Znajdowanie kolejnych słabości ma ograniczoną wartość, jeśli organizacje nie potrafią określić, które z nich mają znaczenie, ani usunąć ich przyczyn.

To właśnie tutaj optymistyczne opisy odkrywania podatności przez AI stają się niepełne. Model, który generuje dziesięć razy więcej wiarygodnych ustaleń, może pogorszyć bezpieczeństwo, gdy kolejce weryfikacyjnej brakuje zaufanych dowodów, odtwarzalnych testów i jasno określonej odpowiedzialności.

Obrońcy muszą odpowiedzieć na kilka pytań w przypadku każdego zgłoszenia. Czy dane zachowanie jest rzeczywiste? Czy atakujący może do niego dotrzeć? Jakie uprawnienia są wymagane? Czy wykorzystanie podatności przekracza istotną granicę zaufania? Czy proponowana naprawa zakłóci oczekiwane zachowanie?

Łaty generowane przez AI wydają się oferować odpowiadające temu przyspieszenie. Model może przeanalizować podatny kod, zasugerować modyfikację i wygenerować testy. Obecne dowody pokazują jednak, że tworzenie łat pozostaje znacznie mniej niezawodne niż znajdowanie podejrzanych zachowań.

Zespół badawczy 1Password ocenił 6 080 łat wygenerowanych dla sześciu niedawno ujawnionych podatności przy użyciu dwóch modeli frontier. Tylko 26,0 procent w pełni rozwiązało problem bez istotnej zmiany zachowania aplikacji.

Kolejne 20,1 procent naprawiło podatność, lecz zmieniło sposób działania aplikacji. Co poważniejsze, 53,9 procent nie usunęło słabości, wprowadziło kolejną podatność lub zrobiło jedno i drugie, zgodnie z badaniem walidacji łat.

Wyniki te nie ustanawiają uniwersalnego wskaźnika niepowodzeń dla każdego modelu, języka ani podatności. Badacze celowo wybrali niedawne, złożone błędy wymagające znaczących napraw. Prostsze defekty i silniejsze zestawy testów mogą dawać inne wyniki.

Badanie nadal ujawnia kluczową nierównowagę. Wygenerowanie przekonującej zmiany w kodzie jest łatwiejsze niż udowodnienie, że zachowuje ona każdą ważną właściwość bezpieczeństwa i funkcjonalności.

Niektóre proponowane naprawy wąsko blokowały znane dane wejściowe proof-of-concept, nie rozwiązując przy tym podstawowej przyczyny. Taki wzorzec może stworzyć łatę, która przejdzie podstawowy test, a jednocześnie pozostanie podatna na alternatywne dane wejściowe.

Łaty generowane przez AI dziedziczą także słabości środowisk, które je oceniają. Niekompletny zestaw testów nie może potwierdzić zachowania, którego nigdy nie sprawdza. Model może optymalizować wyniki pod kątem przejścia widocznych testów, nawet jeśli testy te obejmują jedynie część kontraktu bezpieczeństwa.

Oddzielne badania obejmujące ponad 100 modeli i 80 zadań programistycznych wykazały średni wskaźnik bezpiecznego kodu na poziomie 56 procent. Wynik ten dotyczył generowanego kodu, a nie usuwania podatności, jednak wzmacnia potrzebę niezależnej walidacji.

Organizacje powinny unikać interpretowania tych liczb jako dowodu, że AI nie może wspierać pracy obronnej. Modele mogą przygotowywać zmiany, generować testy regresji, wyjaśniać nieznane funkcje i porównywać alternatywne poprawki. Zastosowania te mogą zmniejszyć nakład pracy inżynieryjnej, gdy eksperci zachowują ostateczną decyzyjność.

Niebezpieczeństwo zaczyna się, gdy szybkość staje się główną miarą sukcesu. Łata wdrożona szybko, lecz bez odpowiedniej walidacji, może zachować pierwotny błąd, stworzyć nowy lub po cichu zmienić zasady dostępu.

Automatyzacja obronna musi zatem opierać się na wykonaniu. Oznacza to kompilowanie i uruchamianie proponowanych zmian, testowanie właściwości bezpieczeństwa, porównywanie zachowania oraz odrzucanie łat naruszających zdefiniowane niezmienniki. Niezmiennik to warunek, który musi pozostać prawdziwy w każdej akceptowalnej implementacji.

W przypadku systemów o dużym wpływie przegląd człowieka pozostaje konieczny, ponieważ testy nigdy nie obejmują całego kontekstu operacyjnego. Inżynierowie muszą rozumieć, dlaczego słabość istniała, które założenia zawiodły oraz czy powiązany kod zawiera ten sam wzorzec.

Jest to wolniejsze niż wygenerowanie łaty. Jest to także praca, która przekształca raport o podatności w trwałe ograniczenie ryzyka.

Więcej ustaleń nie naprawi wadliwych procesów bezpieczeństwa

Organizacje, które odpowiedzą na AI większą kolejką łat, pozostaną w pułapce, ponieważ wolumen nie skoryguje procesu, który stworzył defekty.

Program zarządzania podatnościami może wyglądać na produktywny, podczas gdy ryzyko nadal rośnie. Zespoły liczą krytyczne ustalenia, czasy zamknięcia i łączną liczbę łat, ponieważ te liczby łatwo zbierać. Pokazują aktywność, ale nie zawsze ujawniają, czy oprogramowanie staje się bezpieczniejsze.

Moussouris ostrzegła, że organizacje nie mogą wygrać, nieustannie dodając zasoby do pojedynczych działań związanych z odkrywaniem i naprawą. Zrównoważona odpowiedź polega na identyfikowaniu wzorców i zmianie systemów, które tworzą powtarzające się klasy podatności.

Załóżmy, że wspomagany przez AI przegląd wykrywa dziesiątki błędów typu injection. Naprawienie każdego przypadku ma znaczenie, lecz większa szansa pojawia się wcześniej w procesie rozwoju. Zespoły mogą wprowadzić bezpieczniejsze szablony, scentralizowaną obsługę danych wejściowych, zabezpieczenia frameworków i testy, które zapobiegają powrotowi tego samego defektu.

To różnica między usuwaniem ustaleń a ulepszaniem mechanizmu bezpieczeństwa. Pierwsze działanie zmniejsza natychmiastową ekspozycję. Drugie zmienia przyszłe tempo, w jakim pojawia się ekspozycja.

Organizacje powinny łączyć dane o podatnościach z odpowiedzialnością za kod, decyzjami architektonicznymi i standardami rozwoju. Jeśli jedna usługa wielokrotnie powoduje błędy autoryzacji, kierownictwo powinno przeanalizować jej model dostępu, zamiast świętować szybsze zamykanie zgłoszeń.

To samo rozumowanie dotyczy infrastruktury. Powtarzające się ustalenia dotyczące wystawionych interfejsów administracyjnych wskazują na błąd zarządzania zasobami lub nadzoru nad siecią. Naprawienie jednego serwera bez skorygowania wzorca wdrożenia pozostawia podstawowy mechanizm nienaruszony.

Dojrzała odpowiedź na bezpieczeństwo AI oparte na niejawności zaczyna się od uczciwej inwentaryzacji. Zespoły muszą wiedzieć, które komponenty są wdrożone, kto je utrzymuje, które interfejsy są osiągalne i co dzieje się po zakończeniu wsparcia.

Wykazy materiałowe oprogramowania mogą pomóc zidentyfikować zależności, lecz inwentaryzacja musi wykraczać poza nazwy pakietów. Organizacje potrzebują także wersji firmware, modeli urządzeń, usług chmurowych, wewnętrznych API, dziedziczonych uprawnień i zasobów technologii operacyjnej.

Systemy wiedzy tworzą kolejną formę ryzyka wynikającego z niejawności. Asystenci AI mogą ujawniać dokumenty, wiadomości, transkrypcje i notatki, do których pracownicy byli technicznie uprawnieni, lecz których rzadko szukaliby ręcznie.

Nie musi to oznaczać obejścia autoryzacji przez AI. Może ujawniać uprawnienia, które od początku były zbyt szerokie. AI zmniejsza wysiłek potrzebny do znalezienia wrażliwych materiałów w ramach tych uprawnień.

Zespoły wdrażające wyszukiwanie korporacyjne lub systemy retrieval powinny przed szerokim wdrożeniem przeanalizować własność treści, retencję, dziedziczenie dostępu i granice indeksowania. Dobrze zaprojektowana baza wiedzy AI powinna zachowywać uprawnienia źródłowe zamiast traktować wszystkie indeksowane informacje jako jednakowo dostępne.

Wymaga to także starannego logowania. Zespoły bezpieczeństwa potrzebują zapisów pokazujących, do czego agent uzyskał dostęp, których narzędzi użył, jakie zmiany zaproponował i kto zatwierdził istotne działania. Bez tych dowodów zautomatyzowane przepływy pracy stają się trudniejsze do zbadania niż starsze systemy, które zastępują.

Reforma procesów powinna obejmować rygorystyczne wymagania dotyczące przyjmowania raportów o podatnościach generowanych przez AI. Zgłoszenia powinny wskazywać dotknięte wersje, opisywać granicę zaufania, zawierać kroki reprodukcji oraz oddzielać zaobserwowane zachowanie od spekulacji wygenerowanych przez model.

Opiekunowie oprogramowania mogą następnie wykorzystywać automatyzację do grupowania duplikatów, weryfikowania szczegółów środowiska i nadawania priorytetu ustaleniom o wykazanym wpływie. Celem nie jest odrzucanie badań wspomaganych przez AI. Chodzi o wymaganie dowodów, które skalują się wraz z liczbą twierdzeń.

Zespoły zakupowe również mają swoją rolę. Nabywcy powinni pytać dostawców, jak testują łaty generowane przez agentów, zarządzają komponentami starszymi, obsługują skoordynowane ujawnianie podatności i mierzą powtarzające się klasy podatności. Obietnica „wykorzystania AI w bezpieczeństwie” daje niewielką pewność bez tych szczegółów.

Sceptyczne spojrzenie pozostaje ważne. Obecne modele są niespójne, a imponujące demonstracje często korzystają z wyselekcjonowanych środowisk. Niektóre ustalenia AI wymagają rozległej korekty przez człowieka, podczas gdy w pełni autonomiczne wykorzystanie podatności pozostaje mniej powszechne niż wspomagane skryptowanie i rozpoznanie.

Jednak niespójność nie przywraca dawnej fosy. Atakujący nie potrzebuje, by każda próba zadziałała. Tanie równoległe próby mogą uczynić niski wskaźnik sukcesu operacyjnie wartościowym, szczególnie wobec wielu podobnych celów.

Obrońcy muszą planować z uwzględnieniem tej ekonomii. Powinni zakładać, że dostępny kod, binaria, konfiguracje i łaty będą poddawane zautomatyzowanej analizie. Ich przewaga musi wynikać z bezpieczniejszego projektowania i szybszej, zweryfikowanej reakcji, a nie z nadziei, że analiza zawiedzie.

Trzy sygnały pokażą, czy obrońcy mogą nadrobić zaległości

O kolejnej fazie zdecydują weryfikacja łat, ekspozycja infrastruktury krytycznej oraz to, czy organizacje zapobiegają powtarzającym się błędom, zamiast je liczyć.

Pierwszym sygnałem jest mierzona niezawodność poprawek generowanych przez AI. Przyszłe oceny powinny testować niedawno ujawnione podatności, zachowywać realistyczne zachowanie aplikacji i publikować metody umożliwiające odtworzenie wyników. Rosnący odsetek kompletnych poprawek zmniejszyłby obecną lukę między wykryciem a usunięciem problemu.

Ważnym wynikiem nie jest to, czy poprawka się kompiluje. Badacze muszą sprawdzić, czy eliminuje pierwotną przyczynę, nie wprowadza nowych słabości i zachowuje oczekiwane działanie. Usprawnienia, które przetrwają niezależną ocenę, wzmocnią argumenty za nadzorowaną automatyzacją działań obronnych.

Utrzymywanie się wskaźników niepowodzeń blisko obecnych poziomów przemawiałoby za ostrożniejszym wnioskiem. AI nadal zwiększałaby wolumen wykrywanych problemów, podczas gdy ekspercka walidacja pozostałaby ograniczającym zasobem.

Drugim sygnałem jest poziom ekspozycji sterowników przemysłowych i innych systemów starszego typu. Agencje i operatorzy powinni śledzić, czy liczba dostępnych z internetu PLC spada, czy znikają domyślne dane uwierzytelniające oraz czy organizacje wykrywają nieautoryzowany ruch wykorzystujący protokoły przemysłowe.

Kolejna fala wspomaganych przez AI ataków na wystawione sterowniki wzmocniłaby główną ocenę. Pokazałaby, że atakujący wielokrotnie przekształcają publicznie dostępną wiedzę w działające narzędzia przeciwko systemom nadal chronionym przez słabą architekturę.

Trwałe ograniczenie ekspozycji osłabiłoby najbardziej alarmującą prognozę. Nie przywróciłoby to bezpieczeństwa przez niejawność, ale pokazałoby, że podstawowa izolacja i zarządzanie zasobami mogą odebrać agentom praktyczną drogę ataku.

Trzecim sygnałem jest sposób, w jaki organizacje bezpieczeństwa mierzą postęp. Zespół skupiony wyłącznie na liczbie zgłoszeń i medianie czasu ich zamykania będzie miał trudności, gdy zautomatyzowane raporty zaczną się mnożyć. Zespół śledzący powtarzające się klasy defektów, wystawione zasoby, przyczyny źródłowe i zweryfikowane działania naprawcze może ograniczyć przyszłe zapotrzebowanie.

Warto obserwować, czy dostawcy i duże projekty programistyczne zaczną publikować takie głębsze miary. Dowody na spadek liczby defektów związanych z wstrzykiwaniem, autoryzacją, bezpieczeństwem pamięci lub konfiguracją sugerowałyby, że zmiany procesów działają.

Jeśli liczba ujawnionych podatności nadal będzie bić rekordy, podczas gdy te same klasy defektów będą powracać, obrońcy pozostaną na tym, co Moussouris opisała jako bieżnię. Szybsze wykrywanie ujawni więcej ryzyka, nie zmieniając mechanizmu, który je wytwarza.

Praktyczna odpowiedź zaczyna się teraz. Zinwentaryzuj zapomniane systemy, usuń niepotrzebną ekspozycję, przetestuj granice uprawnień i wymagaj dowodów dla każdego zautomatyzowanego twierdzenia dotyczącego bezpieczeństwa. Wykorzystuj agentów do wspierania badaczy i inżynierów, ale istotne naprawy pozostaw za powtarzalnymi testami i odpowiedzialnym przeglądem.

Bezpieczeństwo AI oparte na niejawności jest już przegraną pozycją, ponieważ stara obrona zależała od rzadkiej ciekawości i wyspecjalizowanej pracy. Oba te zasoby stają się dostępne jako usługi programowe.

Trudniejszym zadaniem jest budowanie systemów, które pozostają bezpieczne, gdy ich szczegóły stają się zrozumiałe. Którą ukrytą zależność, odziedziczone uprawnienie lub wystawiony sterownik Twoja organizacja najmniej chciałaby dziś oddać do analizy agentowi AI?