Gdy agent znajduje lukę bezpieczeństwa

Nicholas Carlini, naukowiec badawczy z Anthropic, skierował Claude Code na kod źródłowy jądra Linuksa i polecił mu znaleźć luki bezpieczeństwa. Konfiguracja: 10-liniowy skrypt bash plus kontener Docker z buildami instrumentowanymi ASAN. Pętla po plikach źródłowych, prośba do modelu o szukanie błędów, przejście do kolejnego pliku.¹³

Rezultat, szczegółowo opisany w relacji Michaela Lyncha z tego wystąpienia:² zdalnie wykorzystywalne przepełnienie bufora na stercie w cache’u powtórek NFSv4 LOCK, obecne od marca 2003 roku, starsze niż sam Git. Dwaj współpracujący klienci NFS mogą odczytać wrażliwą pamięć jądra, przepełniając 112-bajtowy bufor 1024-bajtowym identyfikatorem właściciela blokady. W tym samym przeglądzie Carlini znalazł co najmniej cztery kolejne luki w jądrze. Niezależnie ta sama metodologia wygenerowała 122 crashujące inputy wysłane do Mozilli, z których 22 otrzymało CVE.³ Wspomniał o „kilkuset awariach”, których nie zdążył zwalidować i zgłosić.²

Carlini potwierdził te luki i zgłosił je do maintainerów. Znalazł je za pomocą Opusa 4.6, tej samej klasy modelu, którą praktycy codziennie wykorzystują do przeglądu kodu, refaktoryzacji i tworzenia funkcji. Carlini zaprezentował wyniki na konferencji bezpieczeństwa AI [un]prompted w kwietniu 2026 roku.¹

Tak, agenci AI potrafią znaleźć prawdziwe luki bezpieczeństwa, które ludzcy eksperci przeoczali przez dziesięciolecia. Badacz z Anthropic użył Claude Code z 10-liniowym skryptem bash, aby odkryć 23-letnie, zdalnie wykorzystywalne przepełnienie bufora na stercie w jądrze Linuksa, a także wygenerować 22 CVE dla Firefoksa ze 122 crashujących inputów. Metodologia nie wymaga żadnego niestandardowego frameworka: wystarczy iterować po plikach źródłowych z buildami instrumentowanymi ASAN i poprosić model o znalezienie błędów.

W skrócie

Metodologia Carliniego była minimalistyczna: iteracja po plikach źródłowych, zapytanie Claude o znalezienie luk w każdym z nich, weryfikacja trafień asercjami ASAN. Opus 4.6 znalazł znacznie więcej luk niż Opus 4.1 (starszy o 8 miesięcy) czy Sonnet 4.5 (starszy o 6 miesięcy), co sugeruje, że zdolności modelu przekroczyły niedawno pewien próg.² Wąskim gardłem jest teraz ludzka walidacja, a nie odkrywanie przez AI. Zmiana ta niesie bezpośrednie konsekwencje dla tego, jak praktycy budują security hooks, prowadzą przegląd kodu i myślą o audycie wspomaganym przez agentów.

Kluczowe wnioski

• Inżynierowie bezpieczeństwa: Zdolność jest realna i szybko się rozwija. Jeśli prowadzi się przegląd kodu wspomagany agentem, PreToolUse security hooks mają większe znaczenie niż kiedykolwiek. Nie po to, aby blokować Claude, ale po to, aby kontrolować, co może zrobić z tym, co znajdzie.
• Twórcy harnessów: Wąskie gardło weryfikacji („kilkaset awarii, których nie zwalidowałem”) to problem harnessu. Zautomatyzowany triage, deduplikacja i klasyfikacja powagi to następna warstwa infrastruktury.
• Wszyscy pozostali: Ten sam model, który wprowadza 446-krotne regresje wydajności, znajduje też błędy, które umknęły 23 latom ludzkich przeglądów. Obie rzeczy są prawdziwe jednocześnie.

Metodologia

Podejście Carliniego nie wymagało niestandardowego frameworka bezpieczeństwa, dostrajanego modelu ani wyspecjalizowanych promptów. Określił je jako „10-liniowy skrypt bash plus kontener Docker”:³

1. Skompilowanie celu z instrumentacją ASAN (AddressSanitizer)
2. Iteracja po plikach źródłowych, z użyciem modelu do oceny istotności dla bezpieczeństwa
3. Wysłanie do Claude Code promptu z framingiem capture-the-flag dla plików o wysokiej istotności
4. Wykonanie wielu przebiegów na cel (od 5 do 20 w zależności od bazy kodu)
5. Użycie zautomatyzowanych agentów krytykujących do weryfikacji wyników przed ujawnieniem

Framing capture-the-flag ma znaczenie. Powiedzenie modelowi „ten kod ma błąd” aktywuje inny tryb niż „przejrzyj ten kod pod kątem problemów”. Deweloperzy dostrzegają ten sam wzorzec w codziennym użyciu: Claude znajduje więcej problemów, gdy mu się powie, że problem istnieje, niż gdy się go spyta, czy może istnieć.²

Przegląd kosztuje tokeny API, a nie osobomiesiące. Carlini znalazł pięć potwierdzonych luk w jądrze Linuksa i 22 CVE dla Firefoksa, używając zwykłego agenta CLI.³ Tego samego narzędzia, które pisze testy jednostkowe i formatuje importy.

Próg zdolności

Najbardziej uderzającym odkryciem jest przepaść między generacjami modeli. Carlini próbował odtworzyć swoje wyniki za pomocą starszych modeli:²

• Opus 4.6 (wydany ~2 miesiące przed wystąpieniem): znalazł przepełnienie sterty i wiele dodatkowych luk
• Opus 4.1 (starszy o 8 miesięcy): znalazł tylko niewielki ułamek
• Sonnet 4.5 (starszy o 6 miesięcy): znalazł tylko niewielki ułamek

Między generacjami modeli przekroczony został pewien próg. Zdolność utrzymania złożonej bazy kodu w kontekście, rozumowania o przepływie danych przez granice funkcji i identyfikowania subtelnych niezgodności ze specyfikacją pojawiła się skokowo, a nie stopniowo.

Carlini stwierdził wprost: „Nigdy wcześniej w życiu nie znalazłem czegoś takiego. To jest bardzo, bardzo, bardzo trudne. Z tymi modelami językowymi mam ich całą kolekcję.”²

Paradoks

Ta sama architektura agenta, która wprowadza regresje wydajności — 118 funkcji ze spowolnieniami od 3x do 446x — znajduje też luki bezpieczeństwa, które umknęły dekadom eksperckich przeglądów. To komplementarne aspekty tego samego profilu zdolności. Badanie luk to zasadniczo dopasowywanie wzorców do znanych klas (przepełnienia bufora, use-after-free, problemy ze znakowością liczb całkowitych), co jest mocną stroną LLM.⁴ Optymalizacja wydajności wymaga czegoś przeciwnego: rozumowania o konkretnych kontekstach wykonania, zachowaniu cache’u i złożoności algorytmicznej. Model rozpoznaje przepełnienie bufora wśród milionów linii kodu, ale nie jest w stanie stwierdzić, że dla danego wzorca dostępu hash mapa jest wolniejsza niż posortowana tablica. Warto zbudować swój harness stosownie do tego — z security hookami, które flagują wyniki, i performance hookami, które mierzą przed zatwierdzeniem.

Wąskie gardło weryfikacji

Najbardziej odkrywcze wyznanie Carliniego: „Mam w jądrze Linuksa tyle błędów, że nie mogę ich zgłosić, bo jeszcze ich nie zwalidowałem.”²

Wąskie gardło znajduje się teraz w triage’u, nie w odkrywaniu. Znajdowanie potencjalnych luk kosztuje mniej niż potwierdzanie, że są prawdziwe. Ta inwersja tworzy nowy problem infrastrukturalny dla zespołów bezpieczeństwa:

Odkrywanie jest zautomatyzowane. Agent może przejrzeć bazę kodu w ciągu godzin.

Weryfikacja jest ręczna. Każda potencjalna luka wymaga proof of concept, oceny wpływu i procesu odpowiedzialnego ujawniania.

Triage to właśnie ta luka. Sortowanie setek wyników wygenerowanych przez agenta na prawdziwe luki, fałszywe pozytywy i szum o niskiej powadze to praca, dla której nie ma jeszcze dobrych narzędzi.

Wzorzec odzwierciedla przegląd kodu wspomagany agentem: agent produkuje surowe wyniki szybciej, niż ludzie są w stanie je ocenić. Wartość tkwi nie w generowaniu, lecz w infrastrukturze, która przetwarza, filtruje i kieruje wyniki.

Dla twórców harnessów oznacza to, że następnym hookiem o wysokiej wartości nie jest skaner bezpieczeństwa. Jest nim system triage’u bezpieczeństwa: deduplikacja, klasyfikacja powagi, filtrowanie fałszywych pozytywów i automatyczne generowanie proof of concept. Governance hooks, które kontrolują wyjście agenta, są ważniejsze niż same zdolności skanowania.

Co to oznacza dla praktyków

Jeśli uruchamia się Claude Code na produkcyjnych bazach kodu, uruchamia się już system zdolny znaleźć prawdziwe luki bezpieczeństwa. Pytanie nie brzmi, czy ta zdolność istnieje, ale czy harness potrafi obsłużyć to, co agent znajdzie.

Trzy praktyczne kroki:

Warto dodać przegląd bezpieczeństwa do pipeline’u recenzji. PostToolUse hook na Write/Edit może uruchomić ukierunkowane skanowanie bezpieczeństwa na zmienionych plikach. Hook czyta ścieżkę pliku ze stdin (Claude Code przekazuje do hooków event JSON przez stdin):

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking, runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

Powyższy hook to punkt wyjścia, a nie rozwiązanie produkcyjne. Należy dołożyć deduplikację, filtrowanie powagi i ograniczanie tempa. Rdzeń wzorca odpowiada jednak metodologii Carliniego: pętla po plikach z ukierunkowanym promptem.³

Warto zbudować infrastrukturę triage’u. Surowe wyniki luk bez klasyfikacji powagi to szum. Jeśli agent produkuje 50 wyników na przegląd, potrzebna jest zautomatyzowana deduplikacja i scoring priorytetu, zanim człowiek zobaczy listę. Wąskie gardło to problem harnessu, a nie problem modelu.

Warto zaakceptować paradoks. Ten sam model, który wymaga barierek wydajnościowych, jest autentycznie świetny w dopasowywaniu wzorców bezpieczeństwa. Warto zaprojektować harness tak, aby wykorzystywał mocną stronę i kompensował słabą. Security hooki, które skanują. Performance hooki, które mierzą. Quality hooki, które weryfikują. Każdy pokrywa to, czego brakuje pozostałym.

23-letnia luka w Linuksie wcale się nie ukrywała. Była na widoku, w pliku, który przeczytały tysiące inżynierów. Model ją znalazł, ponieważ dopasowywanie wzorców w skali to właśnie to, co robią takie systemy. Lekcja nie brzmi, że agenci są lepsi od ludzi w kwestiach bezpieczeństwa. Lekcja brzmi, że agenci pokrywają inną powierzchnię — a harness, który orkiestruje oba, sprawia, że połączenie staje się niezawodne.

Aktualizacja (7 kwietnia 2026): Anthropic ogłosił Project Glasswing, nowy model o nazwie Claude Mythos, który skalował podejście Carliniego do tysięcy zero-dayów na wszystkich głównych platformach. Mythos pozostaje ograniczony do 12 partnerów i nie jest publicznie dostępny. Powyższy post dotyczy pierwotnych badań Carliniego; kontynuacja opisuje produktyzację.

Źródła

Najczęściej zadawane pytania

Czy można odtworzyć podejście Carliniego za pomocą Claude Code?

Carlini udokumentował metodologię w wywiadzie podcastowym.³ Rdzeń pętli: kompilacja z ASAN, iteracja po plikach źródłowych, wysłanie do Claude promptu z framingiem capture-the-flag, weryfikacja trafień. Carlini wskazał, że Opus 4.6 znajdował znacznie więcej luk niż starsze modele, zatem wyniki dla innych generacji modeli mogą się różnić.

Czy to oznacza, że agenci AI są lepsi od ludzi w znajdowaniu błędów bezpieczeństwa?

Nie. Oznacza to, że agenci pokrywają inną powierzchnię. Agenci wyróżniają się w dopasowywaniu wzorców do znanych klas luk w dużych bazach kodu. Ludzie wyróżniają się w rozumieniu nowych wektorów ataku, błędów logiki biznesowej i właściwości bezpieczeństwa zależnych od kontekstu. Połączenie jest silniejsze niż każdy z osobna.

Czy warto obawiać się wykorzystania tej zdolności przez atakujących?

Carlini wyraźnie ostrzegł przed „nadchodzącą wielką falą”. Ta sama zdolność, która pomaga obrońcom znajdować luki, jest dostępna atakującym. Asymetria polega na tym, że obrońcy mogą automatyzować triage i łatanie, podczas gdy atakujący wciąż muszą opracowywać exploity. Jednak ta przepaść w odkrywaniu się zamyka.