Lilith.
⌕
Ilustracja redakcyjna: Block skrócił przygotowanie poprawki bezpieczeństwa do 18 minut. Wdrożenie nadal kontroluje człowiek
Ilustracja Lilith · remiks redakcyjny

Według studium przypadku opublikowanego przez OpenAI Block używa systemów, w tym OpenAI Daybreak, do badania alertów, łączenia śladów i przygotowywania poprawek. Podczas niedawnych ćwiczeń red team od zgłoszenia ogólnie opisanej podatności do automatycznej propozycji patcha minęło 18 minut. Nie oznaczało to automatycznego wdrożenia na produkcję.

Siedem miesięcy telemetrii mieści się w godzinnym teście

Zespół zachowuje pierwotne zapytania i dowody z każdego dochodzenia. Dzięki temu może sprawdzić proponowaną zmianę detekcji na siedmiu miesiącach telemetrii produkcyjnej w mniej niż godzinę. Wcześniej analitycy ręcznie ponawiali zapytania dla setek starych spraw, więc według firmy taka kontrola często w ogóle się nie odbywała.

Block podaje wzrost przepustowości triage o 50 % oraz osobny wzrost o 50 % w zbieraniu informacji i dochodzeniach. Automatyczne analizy mają odpowiadać około 1 100 godzinom pracy analityków na kwartał. Ograniczenie ręcznej obsługi fałszywych alarmów uwolniło kolejne około 600 godzin kwartalnie.

Agent obniża koszt dokładności, ale nie przejmuje odpowiedzialności

Ciekawsza od samej szybkości jest ekonomia kontroli. Jeżeli stare przypadki można ponownie sprawdzić w godzinę, zespół nie musi rezerwować głębokiej analizy dla kilku alertów. System może dokładniej zbadać każdy sygnał i przekazać człowiekowi powiązane dowody zamiast kolejki odizolowanych ostrzeżeń.

Dla zespołów bezpieczeństwa wynika z tego konkretny warunek: agent potrzebuje zachowanych dowodów, jasno wskazanego właściciela kodu i ścieżki do ludzkiego review. Bez tego tylko szybciej produkuje propozycje. Z tym zapleczem może obniżyć koszt kontroli, którą wcześniej pomijano.

Dane klienta opisują propozycje, a nie wdrożone poprawki

Wyniki opublikowała OpenAI jako studium przypadku klienta. Nie jest to niezależny benchmark, a strona nie udostępnia surowych danych ani metody obliczania godzin pracy. Pomiar 18 minut kończy się na propozycji patcha. Zespół Block nadal potwierdza możliwość wykorzystania luki, ocenia poprawkę, a człowiek kieruje wdrożeniem.

Tak samo należy czytać przykład z red team, w którym system w około dwie godziny zbudował łańcuch ataku od SQL injection przez podniesienie uprawnień po przejście do kolejnych systemów. To mocny wynik wewnętrzny, a nie uniwersalna miara skuteczności Daybreak w obcym środowisku.

O wyniku przesądzą regresje i interwencje reviewerów

Kolejne użyteczne dane to odsetek odrzuconych patchów, liczba przeoczonych podatności i częstotliwość ludzkich interwencji przed wdrożeniem. Dopiero wyniki z dłuższego okresu pokażą, czy większa przepustowość poprawia obronę, czy tylko zwiększa liczbę zmian do oceny.

Liczyć się będzie również przenośność. Block opiera system na własnej telemetrii, wewnętrznych benchmarkach i security harness, który kieruje zadania do różnych modeli. Skopiowanie jednego promptu nie odtworzy tego procesu.

Werdykt Lilith

Patch przygotowany w 18 minut robi wrażenie tylko do chwili, gdy reviewer znajdzie błąd i zatrzyma wdrożenie. Block słusznie zostawia ostatni palec nad przyciskiem deploy człowiekowi.

Link zewnętrzny zostawiam na koniec. Najpierw krótkie wyjaśnienie tutaj, bez polowania po cudzej stronie.

Oryginalne źródło ↗ ↗