Skill audytu bezpieczeństwa Cloudflare przekształca przegląd kodu AI w adversarialny workflow

Cloudflare udostępnił sześciofazowy workflow audytu kodu z użyciem AI, lecz skill audytu bezpieczeństwa Cloudflare nie jest kolejnym promptem proszącym model o znalezienie błędów. Przydziela osobnym agentom zadania mapowania kodu, wyszukiwania podatności, podważania ustaleń i weryfikowania pozostałych dowodów.

To rozróżnienie ma znaczenie, ponieważ raporty bezpieczeństwa generowane przez AI często zawierają wiarygodnie brzmiące twierdzenia bez poprawnej ścieżki ataku. Projekt Cloudflare traktuje każdą proponowaną podatność jako zarzut, który inny agent musi spróbować obalić. Rejestruje również zakres objęty audytem, dzięki czemu brakującą analizę łatwiej zauważyć.

Wydanie open source pakuje idee, które Cloudflare opracował podczas budowy znacznie większego wewnętrznego systemu do obsługi podatności. Publiczny skill jest przeznaczony dla jednego repozytorium i jednego uruchomienia audytu. Wewnętrzny system Cloudflare natomiast utrwala wyniki między repozytoriami, śledzi zależności i zarządza tysiącami ustaleń.

To tworzy główne napięcie wokół tego wydania. Wielokrotnego użytku skill obniża próg wejścia do ustrukturyzowanego przeglądu kodu AI, ale sam nie jest w stanie odtworzyć wewnętrznej infrastruktury Cloudflare. Deweloperzy zyskują silniejszy punkt wyjścia, a nie autonomiczny zamiennik inżynierów bezpieczeństwa.

Co faktycznie zmienia skill audytu bezpieczeństwa Cloudflare

Cloudflare zmienia przegląd bezpieczeństwa AI z rozmowy w proces wytwarzający dowody, z jasno określonym pokryciem i bramkami weryfikacyjnymi.

Publiczne repozytorium skillu audytu opisuje workflow zbudowany dla agentów programistycznych obsługujących narzędzia i izolowanych subagentów. Jest licencjonowany na warunkach MIT License i można go zainstalować przez interfejs wiersza poleceń Skills.

Skill audytu bezpieczeństwa Cloudflare dzieli audyt na sześć faz. Rozpoznanie mapuje architekturę oprogramowania, granice zaufania, powierzchnie wejściowe i dostępne dowody. Proces zapisuje tę mapę w dokumencie architektury oraz rejestrze pokrycia czytelnym maszynowo.

Następnie odbywa się wyszukiwanie prowadzone przez pokrycie. Agent nadrzędny przydziela izolowanym łowcom określone obszary i klasy ataków. Każdy łowca zapisuje, co sprawdził, zamiast zwracać wyłącznie listę podejrzewanych problemów.

Ten rejestr jest istotny, ponieważ krótki raport może w przeciwnym razie tworzyć fałszywe poczucie bezpieczeństwa. Agent może sprawdzić kod uwierzytelniania, niczego nie znaleźć i zasugerować, że cała aplikacja wygląda na bezpieczną. Rejestr pokrycia może pokazać, że parsowanie, konfiguracja wdrożenia, obsługa zależności lub izolacja tenantów otrzymały niewiele uwagi.

Walidacja kandydatów przekazuje każdy odrębny trop świeżemu weryfikatorowi. Weryfikator próbuje odrzucić proponowaną podatność, sprawdzając jej założenia, ścieżkę w kodzie źródłowym, dotknięty podmiot i rezultat z punktu widzenia bezpieczeństwa. Agent wyszukujący nie zatwierdza własnej pracy.

Pozostałe ustalenia trafiają następnie do ustrukturyzowanego wyniku. Skill rozdziela rekordy na potwierdzone ustalenia, kwestie wymagające walidacji i odrzuconych kandydatów. Schemat definiuje wymagane pola, a dołączone walidatory JavaScript mechanicznie sprawdzają pliki.

Końcowe fazy niezależnie weryfikują twierdzenia dotyczące źródeł i generują raporty niezależne od celu. Istotne zmiany w ustaleniu uruchamiają kolejną rundę weryfikacji. Ten projekt ma zapobiec sytuacji, w której autor raportu po cichu wzmacnia słabe twierdzenie podczas podsumowywania.

Wynik różni się od zwykłego audytu bezpieczeństwa kodu AI pod jednym kluczowym względem. Produkt końcowy obejmuje opis zbadanych powierzchni, odrzuconych pomysłów, nierozstrzygniętych faktów i niezależnie sprawdzonych ustaleń. Dobrze wyglądający raport nie jest już jedynym artefaktem.

Cloudflare definiuje też ścisłą granicę wykonywania. Kompilacje, testy, fuzzery, przeglądarki i kontrolowane przez cel fixture’y wymagają sandboxa systemu operacyjnego bez zewnętrznego dostępu do sieci. Bez tych zabezpieczeń workflow musi zachować trop jako niezweryfikowany, zamiast wykonywać niezaufany kod.

To ograniczenie sprawia, że wydanie jest mniej wygodne niż jednolinijkowy prompt do audytu. Odzwierciedla jednak rzeczywisty problem bezpieczeństwa. Kod poddawany przeglądowi może zawierać instrukcje lub zachowania podczas budowania, które atakują samo środowisko audytowe.

Dlaczego Cloudflare zbudował skill przed systemem obejmującym całą flotę

Publiczny skill jest wartościowy, ponieważ uchwytuje metodę audytową Cloudflare, a jednocześnie pokazuje, dlaczego pojedyncza sesja agenta osiąga operacyjny pułap.

Cloudflare podaje, że projekt rozpoczął się jako liczący około 450 linii skill bezpieczeństwa dla jednego repozytorium. Inżynierowie dopracowywali jego prompty, aż zaczął wykrywać użyteczne błędy, a następnie przenieśli jego scenariusze i zasady walidacji do większego systemu.

Firma opisała tę ewolucję w swoim wpisie inżynieryjnym o systemie do obsługi podatności. Pierwsza wersja wykorzystywała trzech agentów badawczych do rozpoznania, osobnych łowców dla klas ataków, walidatorów adversarialnych, ustrukturyzowane ustalenia oraz niezależną weryfikację źródeł.

Cloudflare wskazał trzy ograniczenia podczas tych wczesnych uruchomień. Długie sesje wyczerpywały kontekst modelu, przerwane wykonania traciły postęp, a przeglądy pojedynczych repozytoriów pomijały relacje z korzystającymi z nich usługami.

Te niepowodzenia nie były wyłącznie problemami jakości modelu. Były problemami zarządzania stanem.

Model może rozumować o kodzie aktualnie znajdującym się w jego kontekście, lecz duży audyt generuje wiele równoległych hipotez. Każda hipoteza obejmuje pliki, granice zaufania, założenia, eksperymenty, kontrargumenty i zmiany statusu. Kompresowanie tej historii do podsumowania rozmowy może odrzucić rozstrzygające szczegóły.

Cloudflare odpowiedział, wynosząc stan poza model. Jego późniejszy system traktuje modele językowe jako wymienialnych pracowników i przechowuje trwałe informacje audytowe poza ich oknami kontekstowymi. Baza danych przechowuje uruchomienie, repozytorium i etap dla każdego zadania.

To rozróżnienie wyjaśnia, dlaczego Cloudflare udostępnił punkt wyjścia, zamiast przedstawiać go jako gotowy wewnętrzny system. Skill może zakodować rygorystyczną sekwencję w środowisku programistycznym. Nie zapewni jednak automatycznie inwentaryzacji floty, trwałych kolejek, grafów zależności ani telemetrii produkcyjnej.

Cloudflare informuje, że przejście od pierwszego skillu do systemu obejmującego 128 repozytoriów zajęło około sześciu tygodni. Ten wewnętrzny system działa w projektach Rust, Go, C, Lua, TypeScript, Python oraz formatach konfiguracji, bez orkiestracji specyficznej dla języka.

Jego większy workflow oddziela wykrywanie od walidacji. Vulnerability Discovery Harness mapuje i wyszukuje potencjalne słabości. Odmienny Vulnerability Validation System usuwa duplikaty wyników, sprawdza znaczenie produkcyjne i zarządza remediacją.

Cloudflare twierdzi, że używa różnych modeli dla tych dwóch etapów. Ten wybór ogranicza zależność od powtarzających się schematów rozumowania jednego modelu. Pozwala też firmie zmieniać dostawców bez przebudowywania procesu bezpieczeństwa wokół konkretnego modelu.

To neutralne wobec modeli stanowisko wywiera presję na dostawców, którzy przedstawiają wyniki benchmarków jako główną miarę produktu bezpieczeństwa AI. Argument Cloudflare jest taki, że to orkiestracja, dowody i niezależne odrzucanie decydują o tym, czy wynik modelu staje się użyteczną pracą inżynieryjną.

Firma nie twierdzi, że skill odtwarza jej pipeline produkcyjny. Własne wskazówki Cloudflare mówią, że zespoły powinny zacząć od rozpoznania, wyszukiwania i walidacji. Śledzenie między repozytoriami oraz deduplikacja przeznaczona do tego celu stają się użyteczne dopiero wtedy, gdy wolumen audytów tworzy takie problemy.

Taka sekwencja daje mniejszym zespołom praktyczny punkt wejścia. Mogą sprawdzić, czy prompty i zasady dotyczące dowodów działają na ich kodzie, zanim zbudują wokół nich kosztowną infrastrukturę.

Zapobiega też temu, by publiczne wydanie stało się mylącym demo produktu. Repozytorium oferuje metodę, która zapoczątkowała system Cloudflare, a nie kompletny system działający obecnie w całej jego flocie.

Prawdziwym przeciwnikiem jest jednorazowy przegląd kodu AI

System Cloudflare do obsługi podatności podważa założenie, że jeden zdolny model może zbadać repozytorium, zidentyfikować rzeczywiste wady i wiarygodnie ocenić własne wnioski.

Jednorazowy przegląd zwykle przebiega według znajomego schematu. Deweloper daje agentowi programistycznemu dostęp do repozytorium i prosi go o znalezienie podatności bezpieczeństwa. Agent czyta wybrane pliki, identyfikuje podejrzane wzorce i pisze dopracowany raport.

Ten proces może dostarczać użytecznych tropów. Może też ukrywać trzy odrębne błędy.

Po pierwsze, model wybiera, co sprawdzić, bez zachowywania trwałego rejestru tego, co pominął. Po drugie, ten sam proces rozumowania generuje i ocenia każde twierdzenie. Po trzecie, przekonujący język może sprawiać, że niepełne dowody brzmią jak ostateczne.

Workflow Cloudflare atakuje każde z tych niepowodzeń osobno. Rejestr pokrycia zapisuje zamierzoną powierzchnię audytu. Niezależni łowcy badają ograniczone jednostki. Świeży walidator próbuje obalić kandydatów, zamiast poprawiać ich prezentację.

Ten podział adversarialny jest ważniejszy niż samo dodanie większej liczby agentów. Dziesięciu agentów dzielących te same założenia może wygenerować dziesięć wersji tego samego fałszywie pozytywnego wyniku. Cloudflare przydziela różne role i daje walidatorom uprawnienie do odrzucenia teorii łowcy.

Skill wymaga również konkretnego naruszenia granicy. Potwierdzona kwestia musi obejmować dotknięty podmiot, zasób lub rezultat bezpieczeństwa. Brak najlepszej praktyki nie staje się automatycznie podatnością.

To rozróżnienie filtruje ustalenia takie jak nieograniczone zachowanie dostępne wyłącznie dla już zaufanego administratora. Odrzuca także raporty opisujące brakującą ochronę bez pokazania, jak atakujący przekracza rzeczywistą granicę.

Wewnętrzny proces Cloudflare stosuje silniejsze wymogi dowodowe. Potwierdzone ustalenie musi zawierać odtwarzalny test na oryginalnej bazie kodu. Test nie może zależeć od zmian w kodzie źródłowym wprowadzonych przez agenta wyszukującego.

Ta zasada odnosi się do szczególnie niebezpiecznego trybu awarii. Agent może zmodyfikować kod podczas eksperymentów, a następnie zademonstrować exploit na zmodyfikowanej wersji. Bez kontroli stanu źródeł powstały raport może przypisać aplikacji wadę stworzoną przez agenta.

Walidacja mechaniczna dodaje kolejną warstwę. Zwykłe sprawdzenia kodu weryfikują, czy cytowane pliki, ścieżki, patche i testy istnieją albo poprawnie się parsują. Model językowy nie decyduje, czy jego własny wynik spełnia te podstawowe wymagania strukturalne.

Cloudflare podaje, że pojedyncze uruchomienie skillu znalazło około połowy podatności, które ostatecznie wykryto w powtarzanych uruchomieniach. Jest to obserwacja raportowana przez firmę, a nie niezależnie zmierzony wskaźnik wykrywalności.

Mimo to wynik wspiera kluczowy wybór projektowy tego wydania. Jedno zakończone uruchomienie nie potwierdza pełnego pokrycia, nawet gdy każde zgłoszone ustalenie jest prawidłowe.

Rygorystyczny audyt bezpieczeństwa kodu AI wymaga więc dwóch różnych deklaracji pewności. Jedna dotyczy prawidłowości każdego ustalenia. Druga dotyczy tego, jak dokładnie audyt poszukiwał ustaleń.

Skill audytu bezpieczeństwa Cloudflare ujawnia oba pytania. Jego potwierdzone, nierozstrzygnięte i odrzucone werdykty opisują pewność dowodową. Rejestr pokrycia opisuje proces wyszukiwania.

Tradycyjna analiza statyczna pozostaje istotna w tym modelu. Deterministyczne skanery doskonale radzą sobie ze znanymi wzorcami, regułami przepływu danych i powtarzalnymi kontrolami. Agent może badać specyficzne dla aplikacji założenia dotyczące zaufania lub łączyć słabości w nieznanej logice.

Wewnętrzne doświadczenia Cloudflare ostrzegają również przed zakładanymi preferencjami narzędziowymi. Firma podaje, że jej łowcy nie uruchomili zintegrowanej ścieżki Semgrep podczas jednego miesiąca działania. Woleli czytać i wykonywać kod, jednocześnie często prosząc o brakujące środowiska lub fixture’y.

Ta obserwacja nie dowodzi, że analiza statyczna nie ma wartości. Pokazuje, że zainstalowanie narzędzia nie gwarantuje, iż agent będzie używać go skutecznie. Zespoły muszą mierzyć rzeczywiste zachowanie narzędzi w swoim procesie pracy.

Konkurencja nie przebiega więc między AI a konwencjonalnymi skanerami. Chodzi o nieustrukturyzowane wyniki modeli kontra proces audytowy łączący deterministyczne kontrole, wyspecjalizowane badanie i weryfikację adversarialną.

Ustrukturyzowane ustalenia ograniczają szum, ale nie dowodzą bezpieczeństwa

Najmocniejszą stroną wydania jest odmowa traktowania wiarygodnie brzmiących wyników modelu jako potwierdzonych dowodów, jednak taka dyscyplina nie pozwala zmierzyć niewykrytych podatności.

Cloudflare podaje, że jego wewnętrzny mechanizm wykrywania wygenerował 20 799 surowych kandydatów. Około 12 057 przeszło początkowy etap walidacji, zanim trafiło do większej puli walidacyjnej.

Po dołączeniu ustaleń z innego mechanizmu centralna pula zawierała 13 841 rekordów. Deduplikacja usunęła 5 442, a 1 154 przekierowano jako przypadki dotyczące niewłaściwego repozytorium lub niskiego ryzyka. Cloudflare twierdzi, że dla zespołów inżynieryjnych pozostało 7 245 możliwych do podjęcia ustaleń.

Liczby te są użyteczne, ponieważ pokazują, jak wiele filtrowania zachodzi między generowaniem a usunięciem problemu. Nie należy jednak interpretować ich jako niezależnego benchmarku dokładności wykrywania.

Cloudflare samodzielnie wybiera repozytoria, modele, prompty, klasy ataków i definicje. Opublikowane dane opisują jego proces operacyjny. Nie dowodzą, jak publiczny skill działa na niepowiązanej bazie kodu.

Firma wyraźnie unika deklarowania współczynnika fałszywie ujemnych wyników. Rzeczywiste repozytorium nie ma kompletnego zbioru etykiet obejmującego wszystkie podatności, więc nie można bezpośrednio obliczyć czułości. Powtarzane uruchomienia, które nadal znajdują błędy, wskazują na niepełne pokrycie, ale nie na rozmiar pozostałej luki.

Ta niepewność powinna znaleźć się w centrum każdej oceny. Zweryfikowany raport może potwierdzić, że kilka ustaleń jest prawdziwych. Nie może potwierdzić, że audytowany kod jest bezpieczny.

Publiczny skill próbuje przekazać tę różnicę za pomocą trzech werdyktów.

Potwierdzone ustalenie ma pełny ślad źródłowy i ograniczony zaobserwowany rezultat. Rekord wymagający walidacji zachowuje dokładne nierozstrzygnięte pytanie bez przypisywania nieuzasadnionej wagi problemu. Odrzucony rekord dokumentuje, dlaczego kandydat nie przeszedł oceny.

Zachowywanie odrzuconych kandydatów ma praktyczną wartość. Przyszłe uruchomienia mogą odróżnić rzeczywiście nową ścieżkę od wcześniej obalonej hipotezy. Recenzenci mogą także sprawdzić, czy odrzucenie zależało od faktów, które później się zmieniły.

Ustrukturyzowane dane wyjściowe mogą jednak tworzyć własne złudzenie pewności. Poprawny rekord JSON nie musi oznaczać poprawnego wniosku dotyczącego bezpieczeństwa. Walidacja schematu może potwierdzić wymagane pola i akceptowane wartości, lecz nie może dowieść, że exploit przekracza rzeczywistą granicę.

Cloudflare rozwiązuje to ograniczenie przez ponowną weryfikację źródeł. Weryfikator niezależnie ocenia twierdzenie dotyczące kodu, a istotna poprawka zastępcza otrzymuje kolejną kontrolę. Jakość nadal zależy jednak od zachowania modelu, dostępnego kontekstu i poprawności modelu zagrożeń.

Sandboxing stanowi kolejne wyzwanie wdrożeniowe. Skill wymaga kontroli systemu operacyjnego wokół kompilacji i eksperymentów kontrolowanych przez cel. Wiele codziennych środowisk agentów programistycznych nie zapewnia takiej izolacji z jasno określonymi limitami zasobów i sieci.

Zespoły, które ignorują ten wymóg, ryzykują uruchamianie złośliwych zależności, skryptów kompilacji lub zestawów testowych. Zespoły, które go przestrzegają, muszą pozostawić część obiecujących tropów jako nierozstrzygnięte, dopóki nie będzie dostępne bezpieczne środowisko.

Prompt injection rodzi powiązane obawy. Pliki źródłowe, dokumentacja, tekst zgłoszeń i wygenerowane artefakty mogą zawierać instrukcje wymierzone w agenta. Późniejszy komercyjny proces Cloudflare mówi, że traktuje kod, logi i metadane jako dowody, a nie instrukcje.

Ta sama granica musi istnieć przy lokalnym użyciu. Agent bezpieczeństwa nigdy nie powinien interpretować zawartości repozytorium jako upoważnienia do ujawniania poświadczeń, rozszerzania dostępu sieciowego ani modyfikowania niepowiązanych systemów.

Secure Software Framework NIST stanowi użyteczny punkt odniesienia. Traktuje bezpieczne tworzenie oprogramowania jako zestaw praktyk organizacyjnych obejmujących przygotowanie, ochronę, produkcję i reagowanie na podatności.

Skill do audytu AI obejmuje tylko część tego cyklu życia. Może pomóc badać kod źródłowy i dokumentować potencjalne słabości. Nie ustanawia jednak bezpiecznego projektu, zarządzania dostępem, pochodzenia zależności, kontroli wdrożeń ani gotowości na incydenty.

Z tego samego powodu niezbędna pozostaje ocena człowieka. Inżynierowie rozumieją zamierzone zachowanie, architekturę produkcyjną, wpływ biznesowy i kontrole kompensacyjne, które mogą nie być widoczne w repozytorium.

Wydanie powinno zatem zmienić kształt przeglądu, a nie eliminować recenzentów. Zespoły bezpieczeństwa mogą poświęcać mniej czasu na sortowanie niepopartych dowodami twierdzeń, a więcej na testowanie dowodów, ustalanie priorytetów ekspozycji i zatwierdzanie poprawek.

Cloudflare łączy ustalenia z kodu z kontekstem produkcyjnym

Szersza strategia Cloudflare polega na łączeniu ustaleń dotyczących kodu źródłowego z telemetrią ruchu i mechanizmów obronnych, czego samodzielny skill nie jest w stanie zrobić.

Skaner kodu źródłowego może zidentyfikować niebezpieczny handler, nie wiedząc, czy działa on w środowisku produkcyjnym. Może nie wiedzieć, która trasa prowadzi do tego kodu, jak często korzystają z niej klienci ani czy aktywne mechanizmy kontroli blokują odpowiednie żądania.

Zaproszeniowa usługa Vulnerability Discovery and Remediation firmy Cloudflare próbuje zamknąć tę lukę. Firma ogłosiła tę usługę 3 września 2026 roku jako część Cloudflare Managed Defense.

Zgodnie z zapowiedzią dotyczącą usuwania problemów świadomego kontekstu, usługa łączy autoryzowaną analizę kodu z Web Assets, danymi Web Application Firewall i obserwowalnością Workers.

Usługa wykorzystuje modele OpenAI Daybreak, w tym GPT-5.6 Cyber, do rozpoznania, poszukiwania i walidacji. Cloudflare podaje, że prompty przechodzą przez AI Gateway do serwerów OpenAI. Wnioskowanie modelu nie działa na edge Cloudflare.

Ta implementacja pokazuje, dlaczego open-source skill i usługa komercyjna pełnią różne role. Skill organizuje dochodzenie na poziomie repozytorium. Usługa dodaje informacje o wdrożonych trasach, wolumenie żądań, zdarzeniach bezpieczeństwa i istniejących mechanizmach kontroli.

Kontekst produkcyjny może zmienić priorytet bez zmiany ważności technicznej. Rzeczywista podatność na nieosiągalnej ścieżce deweloperskiej wymaga innego traktowania niż ten sam błąd na intensywnie używanym publicznym endpointzie.

Cloudflare twierdzi, że jego proces może zaproponować poprawkę kodu oraz precyzyjnie ograniczoną regułę WAF, gdy dowody uzasadniają oba działania. Reguła na edge może ograniczyć ekspozycję, podczas gdy inżynierowie analizują trwałą zmianę w kodzie.

Usługa nie pozwala modelowi wdrażać własnej propozycji. Wywołania narzędzi są rejestrowane i oceniane względem polityki dostępu. Zewnętrzne kontrole testują poprawki i reguły, podczas gdy klienci decydują o wdrożeniu zmian.

To podejście przekształca mechanizm wykrywania podatności Cloudflare w coś więcej niż silnik odkrywania. Staje się częścią systemu zarządzania ekspozycją, który łączy dowody źródłowe, kontekst czasu działania, ograniczanie ryzyka i usuwanie problemów.

Strategia wyjaśnia również nacisk firmy na raporty niezależne od celu. Ta sama metoda audytu może badać różne języki i typy aplikacji, podczas gdy systemy specyficzne dla produkcji dostarczają kontekstu potrzebnego do ustalania priorytetów.

Większość zespołów używających publicznego skilla nie będzie mieć równoważnej widoczności sieciowej. Nadal mogą poprawić jakość decyzji, dostarczając manifesty wdrożeniowe, mapy tras, rejestry właścicieli i zanonimizowane logi jako kontrolowane dowody.

Powinny zachować jasne pochodzenie informacji. Ustalenie dotyczące kodu źródłowego, deklaracja wdrożeniowa i obserwacja ruchu to różne twierdzenia. Połączenie ich w jednym akapicie nie powinno zacierać źródła każdego faktu.

W tym miejscu znaczenie ma zdyscyplinowane zarządzanie wiedzą. Zespoły inżynieryjne potrzebują przeszukiwalnego rejestru łączącego decyzje architektoniczne, dowody audytowe, odrzucone hipotezy i późniejsze poprawki. Utrzymywana techniczna baza wiedzy może zapewnić dostęp do tych zapisów także po zakończeniu jednej sesji agenta.

Publiczny skill już zmierza w tym kierunku dzięki trwałym artefaktom. Notatki architektoniczne, rejestry pokrycia, ustalenia możliwe do odczytu maszynowego i raporty dla ludzi zapewniają przyszłym recenzentom coś trwalszego niż transkrypcja czatu.

Mimo to repozytorium pozostaje niepełnym obrazem. Polityka infrastruktury, zarządzanie sekretami, konfiguracja autoryzacji, zależności usług i zachowania użytkowników mogą decydować o tym, czy słabość na poziomie kodu źródłowego stanie się możliwa do wykorzystania.

Zespoły, które najprawdopodobniej odniosą korzyści, będą traktować skill jako jeden z generatorów dowodów w szerszym programie bezpieczeństwa. Zespoły, które najprawdopodobniej napotkają trudności, będą oczekiwać od skanowania repozytorium odpowiedzi na pytania o ryzyko produkcyjne, na które repozytorium nie zawiera odpowiedzi.

Trzy sygnały pokażą, czy wydanie ma znaczenie

Kolejnym testem będzie to, czy deweloperzy potrafią odtworzyć dyscyplinę Cloudflare bez prywatnej infrastruktury, danych i personelu bezpieczeństwa Cloudflare.

Pierwszym sygnałem jest jakość publicznych artefaktów audytowych. Użyteczne wdrożenie będzie generować raporty z precyzyjnymi granicami zaufania, odtwarzalnymi dowodami, znaczącymi odrzuconymi kandydatami i uczciwie opisanymi nierozstrzygniętymi pytaniami.

Rosnąca liczba instalacji wskazywałaby na zainteresowanie, ale nie na skuteczność. Lepszą miarą będzie to, czy niezależne zespoły publikują audyty, których potwierdzone ustalenia przetrwają ocenę opiekunów projektu.

Obecny projekt wydania wspiera taką ocenę. Jego schematy pokrycia i ustaleń tworzą porównywalne artefakty, a walidatory mogą wychwycić nieprawidłowo sformowane rekordy, zanim rozpocznie się przegląd przez człowieka.

Drugim sygnałem jest sposób, w jaki repozytorium ewoluuje po rzeczywistym użyciu. Wewnętrzny mechanizm Cloudflare uczył się na podstawie powtarzanych uruchomień, brakujących środowisk, płytkiego pokrycia i odrzuconych ustaleń. Publiczny skill zmierzy się z szerszym zakresem języków, systemów budowania i platform agentowych.

Warto obserwować zmiany w wytycznych dotyczących klas ataków, wymaganiach sandboxingu, modelowaniu pokrycia i obsłudze fałszywych alarmów. Aktualizacje te pokażą, które elementy procesu Cloudflare łatwo przenoszą się do innych środowisk, a które zależą od systemów wewnętrznych.

Na szczególną uwagę zasługuje rozróżnienie między ustaleniami potwierdzonymi a wymagającymi walidacji. Jeśli zewnętrzni użytkownicy będą regularnie przekształcać nierozstrzygnięte tropy w pewne raporty, zabezpieczenia procesu będą istnieć tylko na papierze.

Trzecim sygnałem jest to, czy inne platformy bezpieczeństwa przyjmą podobnie niezależną weryfikację. Narzędzia AI do pracy z kodem już konkurują szybkością, liczbą problemów i pomocą w usuwaniu błędów. Cloudflare przesuwa uwagę w kierunku pochodzenia dowodów, wskaźników odrzuceń i rozliczania pokrycia.

Taka zmiana wzmocniłaby szerszy wpływ skilla do audytu bezpieczeństwa Cloudflare, nawet gdyby deweloperzy nigdy nie zainstalowali tego konkretnego pakietu. Rynek, który pyta, kto zweryfikował ustalenie, jest zdrowszy niż taki, który nagradza największą liczbę alertów.

Wyniki wewnętrzne Cloudflare sugerują, dlaczego ma to znaczenie. Tysiące surowych kandydatów zniknęło podczas walidacji, deduplikacji i oceny kontekstowej. Generowanie większej liczby kandydatów nie było ograniczonym zasobem. Było nim przekształcanie ich w wiarygodną pracę.

Istnieją również praktyczne sygnały wewnątrz poszczególnych organizacji. Liderzy bezpieczeństwa powinni śledzić, ile ustaleń przechodzi niezależny przegląd, jak rośnie pokrycie w kolejnych uruchomieniach oraz ile poprawek przechodzi testy regresji.

Powinni także rejestrować koszt audytu i czas jego trwania. Cloudflare podaje, że jego pełne wewnętrzne skany mogą trwać wiele godzin, a najdłuższe uruchomienie przekroczyło 14 godzin. Publiczny skill może zużywać znaczący czas modelu, gdy łowcy i weryfikatorzy badają odrębne obszary.

Ten wydatek może być uzasadniony w przypadku wrażliwych repozytoriów lub okresowych, pogłębionych przeglądów. Nie musi jednak pasować do każdego pull requesta. Mniejsze kontrole, deterministyczne reguły i ukierunkowane przeglądy zagrożeń nadal lepiej sprawdzają się, gdy potrzebna jest szybka informacja zwrotna.

Kluczową decyzją nie jest to, czy zastąpić istniejące skanery umiejętnością agenta. Chodzi o określenie, gdzie audyt prowadzony przez agenta i oparty na dowodach dostarcza informacji pomijanych przez obecne mechanizmy kontrolne.

Programiści mogą zacząć od jednego, jasno ograniczonego repozytorium i precyzyjnie zdefiniowanej granicy zaufania. Przed przeczytaniem końcowego raportu powinni sprawdzić rejestr pokrycia, a następnie zweryfikować każdy potwierdzony problem względem niezmienionego kodu źródłowego.

Powinni zachować nierozstrzygnięte wpisy zamiast wymuszać werdykt. Testy należy uruchamiać wyłącznie w odpowiednim sandboxie, a decyzje dotyczące napraw powinny pozostać pod kontrolą człowieka.

Jeśli ten proces przynosi powtarzalne ustalenia akceptowane przez opiekunów projektu, Cloudflare udostępniło istotną metodę bezpieczeństwa. Jeśli użytkownicy sprowadzą ją do kolejnego ogólnego promptu, jej sześć faz zwiększy złożoność bez budowania zaufania.

Umiejętność audytu bezpieczeństwa Cloudflare stanowi więc konkretne wyzwanie dla dostawców rozwiązań AI w zakresie bezpieczeństwa i zespołów inżynieryjnych: przestańcie mierzyć sukces liczbą słabości, które model potrafi opisać. Mierzcie, które twierdzenia przetrwają konfrontacyjną weryfikację, które obszary faktycznie zbadano oraz jakie fakty pozostają nieznane.