Kiedy Twój agent znajduje podatność

Nicholas Carlini, badacz w Anthropic, skierował Claude Code na kod źródłowy jądra Linux i kazał mu szukać podatności. Konfiguracja: 10-wierszowy skrypt bash plus kontener Docker z kompilacjami instrumentowanymi przez ASAN. Pętla po plikach źródłowych, pytanie modelu o błędy, przejście do następnego pliku.¹³

Rezultat, opisany szczegółowo przez Michaela Lyncha:² zdalnie eksploatowalny przepełnienie bufora sterty w pamięci podręcznej powtórzeń operacji LOCK w NFSv4, obecne od marca 2003 — 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. Carlini znalazł co najmniej cztery kolejne podatności jądra w tym samym przebiegu. Niezależnie od tego, ta sama metodologia wygenerowała 122 dane wejściowe powodujące awarie przesłane do Mozilli, z których 22 otrzymały numery CVE.³ Opisał „kilkaset awarii”, których nie zdążył zweryfikować i zgłosić.²

To potwierdzone podatności zgłoszone opiekunom kodu, znalezione przez agenta korzystającego z Opus 4.6 — tej samej klasy modelu, którą praktycy uruchamiają codziennie do przeglądów kodu, refaktoryzacji i rozwijania funkcjonalności. Carlini zaprezentował wyniki na konferencji bezpieczeństwa AI [un]prompted w kwietniu 2026.¹

Podsumowanie

Metodologia Carliniego była minimalna: iteracja po plikach źródłowych, polecenie Claude szukania podatności w każdym z nich, weryfikacja trafień asercjami ASAN. Opus 4.6 znalazł znacznie więcej podatności niż Opus 4.1 (starszy o 8 miesięcy) czy Sonnet 4.5 (starszy o 6 miesięcy), co sugeruje niedawne przekroczenie progu zdolności.² Wąskim gardłem jest teraz walidacja przez człowieka, nie odkrywanie przez AI. Ma to bezpośrednie implikacje dla budowania hooków bezpieczeństwa, prowadzenia przeglądów kodu i myślenia o audytach wspomaganych przez agenty.

Kluczowe wnioski

• Inżynierowie bezpieczeństwa: ta zdolność jest realna i szybko się rozwija. Jeśli korzystasz z przeglądów kodu wspomaganych przez agenty, Twoje hooki bezpieczeństwa PreToolUse są ważniejsze niż kiedykolwiek — nie po to, by blokować Claude, lecz by kontrolować, co może zrobić z tym, co znajdzie.
• Twórcy infrastruktury: wąskie gardło weryfikacji („kilkaset awarii, których nie zweryfikowałem”) to problem infrastruktury. Automatyczny triage, deduplikacja i klasyfikacja ważności to następna warstwa narzędzi.
• Wszyscy inni: ten sam model, który wprowadza regresje wydajności rzędu 446x, znajduje też błędy przeoczone przez 23 lata ludzkiego przeglądu. Oba fakty są prawdziwe jednocześnie.

Metodologia

Podejście Carliniego nie wymagało dedykowanego frameworka bezpieczeństwa, dostrojonego modelu ani specjalistycznych promptów. Opisał je jako „10-wierszowy skrypt bash plus kontener Docker”:³

1. Kompilacja celu z instrumentacją ASAN (AddressSanitizer)
2. Iteracja po plikach źródłowych z wykorzystaniem modelu do oceny istotności z perspektywy bezpieczeństwa
3. Promptowanie Claude Code z ujęciem typu capture-the-flag dla plików o wysokiej istotności
4. Wielokrotne przebiegi na cel (5–20 w zależności od bazy kodu)
5. Automatyczni agenci krytyczni do weryfikacji wyników przed ujawnieniem

Ujęcie capture-the-flag ma znaczenie. Powiedzenie modelowi „ten kod ma błąd” aktywuje inny tryb niż „przejrzyj ten kod pod kątem problemów”. Programiści zauważają ten sam wzorzec w codziennym użyciu — Claude znajduje więcej problemów, gdy powiemy mu, że problem istnieje, niż gdy zapytamy, czy jakiś może istnieć.²

Koszt przeglądu mierzy się w tokenach API, nie w osobomiesiącach. Carlini znalazł pięć potwierdzonych podatności jądra Linux i 22 CVE w Firefoksie, korzystając ze standardowej infrastruktury agentowej CLI.³ To samo narzędzie, które pisze testy jednostkowe i formatuje importy.

Próg zdolności

Najbardziej uderzającym odkryciem jest różnica między generacjami modeli. Carlini próbował odtworzyć wyniki ze starszymi modelami:²

• Opus 4.6 (wydany ~2 miesiące przed wystąpieniem): znalazł przepełnienie bufora sterty i wiele dodatkowych podatności
• Opus 4.1 (8 miesięcy wcześniej): znalazł jedynie niewielki ułamek
• Sonnet 4.5 (6 miesięcy wcześniej): znalazł jedynie niewielki ułamek

Między generacjami modeli przekroczono 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 specyfikacji wydaje się emergentna, a nie stopniowo rosnąca.

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łą masę.”²

Paradoks

Ta sama architektura agentowa, która wprowadza regresje wydajności — 118 funkcji ze spowolnieniami od 3x do 446x — znajduje również podatności bezpieczeństwa przeoczone przez dziesięciolecia eksperckiego przeglądu. To komplementarne aspekty tego samego profilu zdolności. Badanie podatności to zasadniczo dopasowywanie wzorców do znanych klas (przepełnienia buforów, use-after-free, błędy znakowości liczb całkowitych), co stanowi mocną stronę LLM.⁴ Optymalizacja wydajności wymaga czegoś odwrotnego: rozumowania o konkretnych kontekstach wykonania, zachowaniu pamięci podręcznej i złożoności algorytmicznej. Model rozpoznaje przepełnienie bufora w milionach linii kodu, ale nie powie, że mapa haszująca jest wolniejsza od posortowanej tablicy dla danego wzorca dostępu. Buduj swoją infrastrukturę odpowiednio — hooki bezpieczeństwa do flagowania znalezisk, hooki wydajności do pomiarów przed commitem.

Wąskie gardło weryfikacji

Najbardziej wymowne przyznanie Carliniego: „Mam tyle błędów w jądrze Linux, że nie mogę ich zgłosić, bo jeszcze ich nie zweryfikowałem.”²

Wąskie gardło przesunęło się z odkrywania na triage. Znajdowanie potencjalnych podatności jest teraz tańsze niż potwierdzanie ich realności. Stwarza to nowy problem infrastrukturalny dla zespołów bezpieczeństwa:

Odkrywanie jest zautomatyzowane. Agent może przeskanować bazę kodu w kilka godzin.

Weryfikacja jest ręczna. Każda potencjalna podatność wymaga dowodu koncepcji, oceny wpływu i procesu odpowiedzialnego ujawniania.

Triage to luka. Sortowanie setek znalezisk generowanych przez agenta na realne podatności, fałszywe alarmy i szum o niskiej ważności to praca, dla której nie istnieją jeszcze dobre narzędzia.

To ten sam wzorzec, który obserwujemy w przeglądach kodu wspomaganych przez agenty: agent generuje surowe wyniki szybciej, niż ludzie są w stanie je ocenić. Wartość nie tkwi w generowaniu — tkwi w infrastrukturze, która przetwarza, filtruje i kieruje wyniki.

Dla twórców infrastruktury oznacza to, że kolejnym wartościowym hookiem nie jest skaner bezpieczeństwa. To system triage bezpieczeństwa: deduplikacja, klasyfikacja ważności, filtrowanie fałszywych alarmów i automatyczne generowanie dowodów koncepcji. Hooki zarządzania kontrolujące wyniki agenta są ważniejsze niż same zdolności skanowania.

Co to oznacza dla praktyków

Jeśli uruchamiasz Claude Code na produkcyjnych bazach kodu, korzystasz już z systemu zdolnego do znajdowania realnych podatności. Pytanie nie brzmi, czy ta zdolność istnieje — lecz czy Twoja infrastruktura jest przygotowana na obsługę tego, co agent znajdzie.

Trzy praktyczne kroki:

Dodaj przegląd bezpieczeństwa do pipeline’u review. Hook PostToolUse na Write/Edit może uruchomić ukierunkowane skanowanie bezpieczeństwa zmienionych plików. Hook odczytuje ścieżkę pliku ze stdin (Claude Code przekazuje zdarzenie JSON na stdin do hooków):

#!/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" }]
    }]
  }
}

To punkt wyjścia, nie rozwiązanie produkcyjne — należałoby dodać deduplikację, filtrowanie ważności i ograniczanie częstotliwości. Jednak podstawowy wzorzec odpowiada metodologii Carliniego: pętla po plikach z ukierunkowanym promptem.³

Zbuduj infrastrukturę triage. Surowe znaleziska podatności bez klasyfikacji ważności to szum. Jeśli agent generuje 50 wyników na przebieg, potrzebna jest automatyczna deduplikacja i punktacja priorytetów, zanim lista trafi do człowieka. To problem infrastruktury, nie problem modelu.

Zaakceptuj paradoks. Ten sam model, który wymaga zabezpieczeń wydajnościowych, jest naprawdę doskonały w dopasowywaniu wzorców bezpieczeństwa. Zaprojektuj swoją infrastrukturę tak, by wykorzystywać mocne strony i kompensować słabości. Hooki bezpieczeństwa, które skanują. Hooki wydajności, które mierzą. Hooki jakości, które weryfikują. Każdy pokrywa to, co inne pomijają.

23-letnia podatność jądra Linux nie była ukryta. Była na widoku, w pliku, który przeczytały tysiące inżynierów. Model ją znalazł, ponieważ dopasowywanie wzorców na dużą skalę to właśnie domena tych systemów. Wniosek nie jest taki, że agenty są lepsze od ludzi w bezpieczeństwie. Wniosek jest taki, że agenty pokrywają inną powierzchnię — a infrastruktura orkiestrująca oba podejścia sprawia, że kombinacja staje się niezawodna.

Źródła

Najczęściej zadawane pytania

Czy można odtworzyć podejście Carliniego z Claude Code?

Metodologia jest udokumentowana w wywiadzie podcastowym.³ Podstawowa pętla: kompilacja z ASAN, iteracja po plikach źródłowych, promptowanie Claude z ujęciem capture-the-flag, weryfikacja trafień. Carlini stwierdził, że Opus 4.6 znalazł znacznie więcej podatności niż starsze modele — wyniki z innymi generacjami modeli mogą się różnić.

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

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

Czy powinienem się martwić, że atakujący wykorzystają tę zdolność?

Carlini wyraźnie ostrzegł przed „nadchodzącą dużą falą”. Ta sama zdolność, która pomaga obrońcom znajdować podatności, jest dostępna dla atakujących. Asymetria polega na tym, że obrońcy mogą zautomatyzować triage i łatanie, podczas gdy atakujący wciąż muszą opracowywać exploity — ale luka w odkrywaniu się zamyka.