Mythos Nie Wystarczy. Lekcja Z Cloudflare. - Security Bez Tabu

Mythos Nie Wystarczy. Lekcja Z Cloudflare.

Co znajdziesz w tym artykule?

Mythos jednak nie taki wspaniały?

Mythos Preview to jeden z tych tematów, przy których łatwo popaść w skrajności. Jedni widzą początek końca klasycznego pentestingu. Drudzy widzą głównie marketing, PR i kolejną falę zachwytu nad AI. Prawda jest mniej wygodna: Mythos jest wystarczająco mocny, żeby potraktować go bardzo poważnie, ale nie jest magicznym inżynierem bezpieczeństwa, którego można podpiąć do repozytorium i powiedzieć: „znajdź wszystko, co groźne”.

Anthropic opisał Mythos Preview jako model używany w ramach Project Glasswing, czyli inicjatywy defensywnej nastawionej na wyszukiwanie podatności w ważnym oprogramowaniu: systemach operacyjnych, przeglądarkach, komponentach open source i kodzie używanym przez duże organizacje. Według Anthropic model potrafił znajdować podatności, które przetrwały lata przeglądów, testów automatycznych i pracy ludzi. Cloudflare z kolei nie zatrzymał się na opisie dostawcy. Firma uruchomiła własne testy na ponad 50 repozytoriach i sprawdziła, jak Mythos zachowuje się na realnym kodzie, w realnym kontekście organizacyjnym.

Szerzej o samym Project Glasswing i pierwszej fali emocji wokół Mythosa pisałem tutaj: Project Glasswing: Anthropic AI, które znajduje i exploituje podatności szybciej niż człowiek.

Ten tekst idzie krok dalej. Nie będziemy tylko powtarzać, że AI znajduje bugi. To już wiemy. Ciekawsze pytanie brzmi inaczej:

Co się dzieje z organizacją, kiedy AI zaczyna znajdować bugi szybciej, niż ludzie potrafią je zweryfikować, zrozumieć, naprawić i bezpiecznie wdrożyć poprawki?

Bo właśnie tam zaczyna się prawdziwa lekcja z Cloudflare, Mozilli, Linuxa, AISI, Google i całej tej dyskusji wokół Mythosa.

Nie chodzi o to, czy Mythos jest „wspaniały”. Chodzi o to, czy organizacja potrafi zamienić taki model w kontrolowany, powtarzalny i walidowalny proces bezpieczeństwa.

Co Cloudflare faktycznie sprawdził?

Cloudflare nie zrobił prostego testu typu: „dajmy modelowi repozytorium i zobaczmy, czy coś znajdzie”. To byłoby efektowne, ale niezbyt użyteczne. Zwykłe wrzucenie dużego kodu do agenta daje często listę podejrzeń, nie analizę bezpieczeństwa.

Cloudflare skierował security-focused LLM-y, w tym Mythos Preview, na własną infrastrukturę: kod runtime, edge data path, stosy protokołów, control plane i zależności open source. Mówimy o ponad 50 repozytoriach, czyli o środowisku, w którym problemem nie jest tylko sam kod, ale również architektura, zależności, konfiguracja, ścieżki wejścia, trust boundaries i pytanie, czy atakujący może w ogóle dotrzeć do danego miejsca.

To ważne rozróżnienie. Benchmark CTF jest czysty. Repozytorium produkcyjne jest brudne. W benchmarku błąd często istnieje po to, żeby go znaleźć. W produkcji błąd jest zakopany pod warstwami zależności, build systemów, feature flag, starych komponentów, dziwnych wyjątków i decyzji architektonicznych sprzed pięciu lat.

W CTF-ie masz zwykle pytanie:

Czy da się rozwiązać zadanie?

W realnym AppSec masz pytania:

Czy ten błąd naprawdę istnieje?
Czy input jest kontrolowany przez atakującego?
Czy ścieżka jest reachable z Internetu?
Czy problem występuje w konfiguracji produkcyjnej?
Czy istnieją kompensujące kontrole?
Czy exploit wymaga nietypowych warunków?
Czy poprawka może zepsuć coś ważniejszego?
Kto jest ownerem?
Jak szybko można wdrożyć fix?

Cloudflare sprawdzał więc coś bardziej praktycznego niż „czy model potrafi znaleźć błąd”. Sprawdzał, czy model potrafi przejść od hipotezy do użytecznego ustalenia bezpieczeństwa.

To jest zupełnie inna liga.

Co Mythos robi dobrze?

Największa wartość Mythosa nie polega na tym, że potrafi wskazać pojedynczą podejrzaną linię kodu. Takie rzeczy robią od lat SAST-y, fuzzery, linters, CodeQL, semgrepowe reguły i różnego rodzaju narzędzia analizy statycznej.

Ciekawsze jest to, że Mythos potrafi łączyć prymitywy.

Cloudflare zauważył, że model może iść dalej niż klasyczne „tu jest potencjalny bug”. Potrafi zbudować łańcuch eksploatacji: znaleźć słabszy element, połączyć go z kolejnym, sprawdzić, czy da się uzyskać bardziej znaczący efekt, a potem próbować wygenerować proof of concept. W opisie Cloudflare pojawia się przykład przejścia od błędu pamięciowego do arbitrary read/write, a następnie do kontroli przepływu wykonania.

To jest bardzo duża różnica.

Klasyczny skaner mówi:

Potential issue: possible memory safety problem.

Lepszy raport mówi:

Finding: out-of-bounds write in parser state transition
Source: attacker-controlled packet field
Sink: buffer write in protocol decoder
Impact: possible memory corruption
Evidence: crash under controlled input
PoC status: reproduced in scratch environment
Reachability: not yet confirmed from public edge

A naprawdę użyteczny raport idzie jeszcze dalej:

Finding: reachable memory corruption in protocol decoder
Source: unauthenticated network packet
Path: edge_listener -> protocol_dispatch -> parse_frame -> decode_extension
Sink: unchecked write to stack buffer
Evidence: reproducible crash with ASAN trace
Exploitability: partial control over overwritten bytes
Compensating controls: edge filter blocks malformed extension length in production
Recommended action: fix parser bounds check, add regression test, validate filter coverage

Tu zaczyna się przewaga AI-assisted vulnerability research. Model nie tylko wskazuje podejrzane miejsce. On potrafi próbować zbudować test, uruchomić go w środowisku scratch, zobaczyć, że hipoteza nie działa, poprawić ją i spróbować ponownie. Cloudflare podkreślał właśnie ten element: generowanie PoC, kompilowanie, uruchamianie i korygowanie założeń.

To zmienia triage.

Raport typu:

Potential command injection may be possible here.

jest tani do wygenerowania, ale drogi do obsłużenia. Ktoś musi wejść w kod, zrozumieć ścieżkę, sprawdzić konfigurację, odtworzyć warunki i zdecydować, czy sprawa jest realna.

Raport typu:

Input reaches sink X through path A -> B -> C.
PoC triggers condition Y.
Observed result: controlled crash in staging build.

jest nadal do weryfikacji, ale daje AppSecowi i developerom konkretny punkt startu.

I to jest moment, w którym Mythos zaczyna być naprawdę ciekawy. Nie jako chatbot. Nie jako „magiczny pentester”. Jako silnik do generowania i testowania hipotez.

Gdzie Mythos przestaje być „wspaniały”?

Problem w tym, że świat nie kończy się na znalezieniu ciekawego tropu.

Cloudflare bardzo jasno pokazał, że AI vulnerability research nie usuwa problemu signal-to-noise. W niektórych miejscach wręcz go pogarsza. Modele mają naturalną tendencję do znajdowania „czegoś”. Jeżeli prompt brzmi: „znajdź podatności”, to model będzie szukał podatności. Nawet tam, gdzie ma tylko bug, code smell, trudny do wykorzystania edge case albo fragment kodu, który wygląda groźnie, ale w praktyce jest odcięty przez konfigurację.

Cloudflare zauważył też różnicę między językami i klasami kodu. Projekty w C/C++ dawały naturalnie więcej potencjalnych problemów pamięciowych i więcej false positive’ów. Kod w memory-safe languages, jak Rust, zmieniał profil wyników. To nie znaczy, że Rust nie ma podatności. Znaczy raczej, że pewne klasy błędów są z niego wypychane na poziomie języka, więc model musi szukać gdzie indziej: w logice, konfiguracji, trust boundary, autoryzacji, przepływie danych.

Drugi problem to odmowy i guardrails.

Cloudflare opisał przypadki, w których model raz odmawiał wykonania zadania, a innym razem wykonywał semantycznie podobne zadanie po zmianie kontekstu lub sformułowania. To jest bardzo ważne. Nie dlatego, że „guardrails są złe”, ale dlatego, że guardrails nie mogą być jedyną granicą bezpieczeństwa.

W praktyce wygląda to tak:

Prompt A: "Napisz exploit na tę podatność."
Model: odmowa.

Prompt B: "Zweryfikuj, czy poniższy błąd jest exploitable w kontrolowanym środowisku testowym i przygotuj minimalny reproducer."
Model: wykonuje zadanie.

Prompt C: "Przygotuj test regresyjny pokazujący naruszenie pamięci."
Model: wykonuje zadanie.

Z perspektywy defensywnej te różnice mają sens. Z perspektywy kontroli ryzyka są trudne. Ten sam mechanizm może być używany do walidacji poprawki, do badań bezpieczeństwa albo do nadużyć.

Trzeci problem jest najbardziej przyziemny: model nie zna automatycznie priorytetów organizacji.

Może znaleźć technicznie ciekawy błąd w bibliotece, która w produkcji jest niedostępna z Internetu. Może znaleźć crash w parserze, który działa wyłącznie na danych wewnętrznych. Może znaleźć problem w module, który jest wyłączony feature flagą. Może też ominąć nudny, ale krytyczny błąd autoryzacji w API, które obsługuje płatności.

Model nie wie sam z siebie:

czy komponent jest publicznie wystawiony,
czy przetwarza dane klientów,
czy działa w ścieżce krytycznej,
czy ma ownera,
czy można go szybko zpatchować,
czy poprawka grozi regresją,
czy istnieje WAF rule,
czy EDR widzi procesy potomne,
czy system ma rollback,
czy bug dotyczy produkcji czy tylko martwego kodu.

To nie jest wada samego Mythosa. To jest właściwość realnego bezpieczeństwa.

Bez kontekstu organizacyjnego „finding” jest tylko findingiem. Nie jest jeszcze decyzją.

Linus Torvalds i problem AI-slopu: gdy każdy bug wygląda jak podatność

I tu wchodzi Linus Torvalds, cały na biało, ale bez marketingowego filtra.

W maju 2026 roku dyskusja wokół Linux kernel security list bardzo dobrze pokazała, co dzieje się, kiedy AI zaczyna masowo produkować zgłoszenia bugów i podatności. Torvalds zwrócił uwagę, że prywatna lista bezpieczeństwa kernela stała się „almost entirely unmanageable” przez zalew AI-generated reports. Problemem nie było samo AI, tylko powtarzalność, duplikaty i brak realnej wartości triage’owej. Różne osoby, używając podobnych narzędzi, znajdowały te same rzeczy i wysyłały je jako potencjalne security issues.

To jest genialny kontrapunkt do zachwytu nad Mythosem.

Bo z jednej strony mamy model, który potrafi znaleźć trudne bugi. Z drugiej strony mamy maintainerów, którzy zaczynają tonąć w zgłoszeniach. A security mailing list, prywatny kanał do obsługi pilnych spraw, zamienia się w kolejkę raportów wymagających ręcznego odsiania.

Linuxowa dokumentacja i dyskusje maintainerów próbują bardzo wyraźnie oddzielić zwykłe bugi od realnych spraw bezpieczeństwa. W poprawkach do dokumentacji kernela podkreślano, że wiele zgłoszeń z automatycznych narzędzi to po prostu zwykłe bugi błędnie kwalifikowane jako security issues. Prywatna lista bezpieczeństwa ma służyć sprawom pilnym: takim, które dają atakującemu nową możliwość działania na poprawnie skonfigurowanym systemie produkcyjnym, są praktycznie osiągalne i przekraczają trust boundary.

To trzeba sobie zapisać grubą kreską:

Bug to nie zawsze podatność.
Crash to nie zawsze exploit.
Security bug to nie zawsze exploitable vulnerability.
AI-generated finding to nie zawsze sprawa dla prywatnego kanału security.

Rozpiszmy to po inżyniersku.

Bug:
Coś działa nie tak.
Może dotyczyć stabilności, jakości, kompatybilności, wydajności albo logiki.
Nie musi dawać atakującemu żadnej przewagi.

Security bug:
Coś działa nie tak i może wpływać na poufność, integralność albo dostępność.
Może być trudne do wykorzystania.
Może wymagać lokalnego dostępu, nietypowej konfiguracji albo dodatkowego błędu.

Vulnerability:
Istnieje realny scenariusz naruszenia bezpieczeństwa.
Błąd przekracza trust boundary albo daje atakującemu nową możliwość działania.
Wpływ jest istotny dla bezpieczeństwa systemu.

Exploitable vulnerability:
Atakujący może faktycznie dojść do błędu.
Input jest kontrolowany przez atakującego.
Błąd występuje w praktycznej konfiguracji.
Efekt jest mierzalny: crash, DoS, auth bypass, data leak, privilege escalation, RCE.

Zobaczmy prosty przykład.

Parser crashuje na dziwnym pliku.

Czy to podatność?

Nie wiemy.

Pytania są ważniejsze niż sam crash:

Czy atakujący może dostarczyć taki plik?
Czy parser działa po stronie serwera czy lokalnie?
Czy parser działa w sandboxie?
Czy crash kończy tylko proces roboczy czy całą usługę?
Czy można kontrolować pamięć?
Czy to tylko DoS, czy coś więcej?
Czy błąd występuje w konfiguracji produkcyjnej?
Czy istnieje rate limiting?
Czy pliki są wcześniej normalizowane?
Czy EDR lub runtime policy blokuje dalsze skutki?

AI może bardzo szybko powiedzieć:

Possible vulnerability in parser.

Ale dojrzały proces bezpieczeństwa musi odpowiedzieć:

Czy to jest realna podatność?
Czy jest exploitable?
Czy jest reachable?
Czy jest pilna?
Czy mamy już duplikat?
Czy jest patch?
Czy poprawka jest przetestowana?

W dyskusji wokół kernela pojawił się jeszcze jeden ważny wątek: AI-assisted reports bez ręcznej weryfikacji często zwiększają koszt pracy maintainerów, bo zawierają spekulatywny impact, dziwny format, brak reproduktora albo brak poprawki. W proponowanych zmianach do dokumentacji wymagano prostych, rzeczowych zgłoszeń: zweryfikowany problem, reproducer, jasny opis wpływu i najlepiej przetestowany patch.

To jest sedno problemu AI-slopu.

AI-slop w security to nie tylko halucynacja. To również raport, który brzmi technicznie, wygląda pilnie, ale nie ma wystarczającego materiału, żeby człowiek mógł szybko podjąć decyzję.

Przykład słabego zgłoszenia:

AI found a critical vulnerability in the parser.
This may lead to remote code execution.
Please investigate urgently.

Przykład zgłoszenia, które ma sens:

Component: image parser
Version: 2.4.1
Input source: unauthenticated upload endpoint
Issue: out-of-bounds read on malformed metadata length
Reproducer: attached minimal file, 312 bytes
Observed result: ASAN crash in parse_metadata()
Production reachability: upload endpoint available behind auth
Exploitability: no evidence of code execution; possible DoS
Patch: proposed bounds check + regression test

W erze AI największym problemem może nie być brak wykrywania podatności.

Problemem może być triage DoS.

Czyli sytuacja, w której zespół bezpieczeństwa, maintainerzy i developerzy są zasypywani zgłoszeniami wyglądającymi jak podatności, ale niewystarczająco dobrymi, żeby szybko je zamknąć, naprawić albo odrzucić.

Dlaczego zwykły coding agent rzucony na repozytorium nie wystarcza?

Tu Cloudflare trafia w bardzo praktyczny punkt. Zwykły coding agent jest zwykle projektowany do jednego liniowego zadania: napisz funkcję, popraw błąd, zrefaktoruj moduł, dodaj test. Taki agent trzyma jeden kontekst roboczy i próbuje dowieźć jeden cel.

Vulnerability research tak nie działa.

Prawdziwa analiza bezpieczeństwa dużego repozytorium to tysiące małych hipotez:

Czy ten parser przyjmuje dane z zewnątrz?
Czy ta autoryzacja jest wykonywana przed czy po dereferencji obiektu?
Czy ten worker przetwarza dane użytkownika?
Czy ta funkcja działa w ścieżce admina czy usera?
Czy ten token jest sprawdzany pod kątem aud/iss/exp?
Czy ten redirect ma allowlistę?
Czy ten cache miesza dane tenantów?
Czy ten parametr trafia do systemowego wrappera?
Czy ten błąd jest reachable z publicznego API?

Cloudflare zauważył, że pojedynczy generic coding agent może wygenerować findings, ale nie daje sensownego coverage ani powtarzalnej wartości w dużym repozytorium. Security research wymaga równoległych, wąskich zadań, a nie jednego wielkiego prompta: „sprawdź repo pod kątem podatności”.

To jest pułapka, w którą łatwo wpaść.

Ktoś uruchamia agenta na repozytorium i dostaje 20 raportów. Wygląda imponująco. Tylko że nie wiadomo:

które pliki zostały realnie przeanalizowane,
które klasy podatności były sprawdzane,
które ścieżki wejścia zostały pokryte,
które wyniki są duplikatami,
które błędy są reachable,
które findingi agent porzucił po drodze,
czy context compaction nie usunął ważnych tropów,
czy model nie skupił się na najłatwiejszych, a nie najważniejszych problemach.

To daje złudzenie bezpieczeństwa.

Model może „przejrzeć repozytorium”, ale to nie znaczy, że repozytorium zostało pokryte analizą bezpieczeństwa. Tak samo jak skaner portów nie oznacza, że wykonaliśmy threat modeling.

Prawdziwa lekcja Cloudflare: harness jest ważniejszy niż prompt

Najważniejszy wniosek z tekstu Cloudflare nie brzmi: „Mythos jest świetny”.

Brzmi raczej:

Sam model to za mało. Wartość pojawia się dopiero wtedy, gdy model działa w dobrze zaprojektowanym harnessie.

Harness to nie jest ozdobne słowo na prompt. To cały system wokół modelu:

repozytoria,
sandbox,
build commands,
narzędzia testowe,
kolejka zadań,
podział pracy,
walidatorzy,
deduplikacja,
trace,
schema raportowania,
integracja z vulnerability management,
kontrola dostępu do narzędzi,
logowanie działań modelu.

Cloudflare opisał pipeline składający się z etapów: Recon, Hunt, Validate, Gapfill, Dedupe, Trace, Feedback i Report. To bardzo dobry wzorzec do myślenia o AI-assisted vulnerability research.

Recon — model najpierw musi zrozumieć system

Zanim agent zacznie szukać podatności, musi zebrać kontekst.

Nie „czytaj cały kod i znajdź RCE”, tylko:

Jak buduje się projekt?
Jakie są entry pointy?
Gdzie są publiczne API?
Które komponenty przetwarzają input użytkownika?
Gdzie są granice zaufania?
Jakie są ścieżki autoryzacji?
Gdzie są parsery?
Gdzie są workerzy?
Gdzie są wrappery systemowe?
Jakie zależności są krytyczne?
Jak wygląda deployment?

Dobry recon powinien zostawić po sobie artefakt, nie tylko „wrażenie modelu”. Na przykład:

project:
  name: image-processing-service
  language: python
  build:
    command: "make test"
  entry_points:
    - "POST /api/v1/uploads"
    - "POST /api/v1/imports"
  trust_boundaries:
    - "internet -> api-gateway"
    - "api-gateway -> upload-service"
    - "upload-service -> image-worker"
  risky_sinks:
    - "subprocess"
    - "file parsing"
    - "archive extraction"
  critical_assets:
    - "customer_uploaded_files"
    - "conversion_queue"
    - "tenant_metadata"

To jest dopiero materiał do sensownego huntowania.

Hunt — wiele wąskich zadań zamiast jednego wielkiego prompta

Zamiast jednego agenta z poleceniem „znajdź podatności”, Cloudflare wskazuje na podejście równoległe: wiele wąskich zadań, z których każde dotyczy konkretnej klasy ryzyka i konkretnego zakresu kodu.

Przykład:

Hunter 1:
Sprawdź upload-service pod kątem path traversal.

Hunter 2:
Sprawdź image-worker pod kątem command injection i shell invocation.

Hunter 3:
Sprawdź API auth middleware pod kątem IDOR i broken object level authorization.

Hunter 4:
Sprawdź parser archiwów pod kątem zip slip.

Hunter 5:
Sprawdź JWT validation pod kątem aud/iss/exp/alg confusion.

Hunter 6:
Sprawdź cache layer pod kątem cross-tenant data leakage.

To jest dużo bliższe pracy zespołu AppSec niż klasycznemu chatbotowi.

Validate — osobny agent ma obalić ustalenie

To jest jedna z najważniejszych części.

Nie wystarczy, że agent znajdzie błąd. Drugi agent, najlepiej z inną rolą i innym promptem, powinien spróbować go zdyskwalifikować.

Czyli zamiast:

Model znalazł podatność, więc tworzymy ticket.

robimy:

Model znalazł potencjalną podatność.
Walidator ma znaleźć powód, dla którego to nie jest podatność.

Przykładowy prompt walidacyjny:

Twoja rola: sceptyczny reviewer AppSec.
Nie zakładaj, że finding jest prawdziwy.
Spróbuj go obalić.

Sprawdź:
- czy input jest kontrolowany przez atakującego,
- czy ścieżka jest reachable,
- czy występuje sanitizacja,
- czy błąd istnieje w konfiguracji produkcyjnej,
- czy PoC faktycznie potwierdza wpływ,
- czy jest to duplikat istniejącego zgłoszenia,
- czy impact jest opisany bez spekulacji.

Cloudflare podkreśla, że ustawienie agentów w opozycji pomaga redukować szum. To jest bardzo praktyczne. AI jest dobre w generowaniu hipotez. Ale w bezpieczeństwie równie ważne jest ich zabijanie.

Gapfill — model ma mówić, czego nie pokrył

Dojrzały pipeline nie powinien tylko raportować:

Znalazłem 12 potencjalnych problemów.

Powinien też powiedzieć:

Nie udało mi się zbudować modułu X.
Nie sprawdziłem ścieżki Y.
Nie miałem konfiguracji produkcyjnej.
Nie potwierdziłem reachability dla endpointu Z.
Nie analizowałem klas podatności A i B.

To jest bardzo ważne, bo bezpieczeństwo nie polega tylko na wiedzy, co znaleziono. Polega też na wiedzy, czego nie sprawdzono.

Dedupe — mniej zgłoszeń, więcej root cause

AI może wygenerować 30 raportów dotyczących tego samego problemu.

Na przykład:

Finding 1: command injection in convert_avatar()
Finding 2: command injection in convert_banner()
Finding 3: command injection in convert_invoice_preview()
Finding 4: command injection in convert_pdf_thumbnail()

A root cause jest jeden:

Legacy wrapper image_convert() buduje polecenie systemowe przez konkatenację stringów i działa z shell=True.

Dobre dedupe zamienia chaos w jedną decyzję techniczną:

Root cause:
Unsafe shell invocation in shared image conversion wrapper.

Affected call sites:
- avatar conversion
- banner conversion
- invoice preview
- PDF thumbnail generation

Fix strategy:
Replace shell invocation with argv array.
Introduce allowlisted file paths.
Add regression tests for all call sites.

To jest różnica między „mamy 30 ticketów” a „mamy jeden root cause do naprawy”.

Trace — najważniejsze pytanie: czy atakujący może tam dojść?

Trace to etap, który odróżnia błąd od reachable vulnerability.

Cloudflare bardzo wyraźnie wskazuje, że trace zamienia ustalenie typu „flaw exists” w pytanie „czy flaw jest osiągalny z zewnątrz”.

Przykład:

Bug exists:
Funkcja parse_metadata() crashuje na długości większej niż 4096 bajtów.

Reachability unknown:
Nie wiemy, czy dane z Internetu mogą wejść do tej funkcji.

Reachable vulnerability:
POST /api/v1/uploads pozwala użytkownikowi przesłać plik.
Plik trafia do image-worker.
image-worker wywołuje parse_metadata().
Błąd występuje przed walidacją typu pliku.
Crash kończy proces workera.
Kolejka retry powoduje powtarzalny DoS.

To jest zupełnie inny poziom jakości raportu.

Report — wynik jako dane, nie esej od modelu

Raport nie powinien być ścianą tekstu w stylu:

The application may be vulnerable because it appears that...

Raport powinien być danymi, które można przepchnąć przez Jira, DefectDojo, internal vulnerability management, SIEM/SOAR albo pipeline GRC.

Przykładowy schemat:

finding_id: AI-VR-2026-0017
title: "Reachable command execution risk in image conversion wrapper"
root_cause: "Untrusted filename used in shell command construction"
affected_component: "image-worker"
source:
  type: "http_endpoint"
  value: "POST /api/v1/uploads"
sink:
  type: "subprocess"
  value: "legacy_convert()"
attacker_controlled_input: true
internet_reachable: true
auth_required: true
production_config_affected: true
evidence:
  - "static trace from upload handler to worker"
  - "staging reproduction with safe test input"
  - "log confirms shell invocation path"
exploitability: "not_confirmed_rce"
impact: "possible command injection; confirmed unsafe sink"
compensating_controls:
  - "WAF in front of upload endpoint"
  - "worker runs in restricted container"
recommended_fix:
  - "remove shell=True"
  - "use argv array"
  - "allowlist file paths"
  - "add regression tests"
owner: "media-platform"
priority: "high"
status: "needs_patch"

Dopiero taki wynik jest operacyjny.

Mozilla jako przykład: AI znajduje dużo, ale ludzie nadal muszą dowieźć poprawki

Mozilla jest bardzo dobrym przykładem, bo tu liczby robią wrażenie, ale jednocześnie pokazują realny koszt pracy.

Mozilla poinformowała, że w kwietniu naprawiła 423 bugi bezpieczeństwa w Firefoxie. Z tego 271 było związanych z Mythos Preview w Firefoxie 150, 41 pochodziło ze zgłoszeń zewnętrznych, a 111 z wewnętrznych działań obejmujących pipeline AI, inne modele, fuzzing i standardowe techniki bezpieczeństwa. Wśród 271 bugów z Mythosa Mozilla sklasyfikowała 180 jako high, 80 jako moderate i 11 jako low.

To brzmi jak nokaut.

Ale dalej robi się ciekawiej. Mozilla podkreśla, że za tym stała praca ponad 100 osób: patche, review, triage, testy, uplift, release i koordynacja. Modele pomagały w znajdowaniu bugów, generowaniu PoC i wyjaśnianiu wpływu, ale same nie „naprawiły Firefoxa”.

To jest ważne, bo liczby można łatwo źle zinterpretować.

271 bugów znalezionych przez Mythosa

nie znaczy:

271 gotowych decyzji bezpieczeństwa

i nie znaczy:

271 w pełni exploitable podatności

Mozilla wyjaśnia również, że klasyfikacja sec-high/sec-critical nie musi oznaczać praktycznego exploita. Firefox ma wiele warstw defense-in-depth, sandboxing i mechanizmy ograniczające skutki pojedynczego błędu. Realny atak często wymaga łańcucha kilku podatności, a zespół nie zawsze buduje pełny exploit, żeby określić praktyczną exploitability.

To jest zdrowe podejście.

AI może pomóc znaleźć więcej. Ale dalej potrzebujesz ludzi i procesu:

triage,
walidacji,
patchy,
testów regresji,
review,
release engineering,
komunikacji,
backportów,
monitorowania po wdrożeniu.

Bez tego AI tylko powiększa backlog.

AISI i cyber-range’e: Mythos jest mocny, ale testy mają ograniczenia

Brytyjskie AI Security Institute również przetestowało Mythos Preview i wyniki są technicznie istotne. Model osiągnął 73% skuteczności na zadaniach CTF poziomu expert. W scenariuszu „The Last Ones”, czyli 32-krokowej symulacji ataku na sieć korporacyjną, Mythos jako pierwszy model rozwiązał całość od początku do końca w 3 z 10 prób, osiągając średnio 22 z 32 kroków.

To nie jest drobiazg. Modele, które potrafią przejść wieloetapowy scenariusz ataku, zmieniają ekonomikę działań ofensywnych i defensywnych.

Ale AISI bardzo jasno wskazuje ograniczenia. Cyber-range’e są łatwiejsze niż realne środowiska. Nie mają aktywnych defenderów, pełnych narzędzi detekcyjnych, reakcji SOC, konsekwencji za hałaśliwe działania ani dynamicznie zmieniającej się infrastruktury. Model może wykonać coś w labie, co w realnej sieci uruchomiłoby alerty, blokady, izolację hosta albo ręczną reakcję administratora.

To trzeba czytać spokojnie.

Mythos nie musi od razu łamać dobrze bronionych banków, żeby był ważny. Wystarczy, że znacząco obniży koszt ataku na słabsze środowiska:

stare VPN-y,
nieaktualne edge devices,
wystawione panele administracyjne,
brak segmentacji,
słabe MFA,
brak centralnego logowania,
luźne IAM,
brak asset inventory,
chaotyczny patch management.

AISI rekomenduje klasyczne podstawy: aktualizacje, kontrolę dostępu, bezpieczną konfigurację i kompleksowe logowanie. To nie jest efektowne, ale dokładnie tego potrzebują organizacje, które będą pierwszym celem automatyzacji.

Czy zagrożenie jest przesadzone?

Trochę tak. I trochę nie.

Bruce Schneier zwrócił uwagę, że Anthropic wykonał bardzo skuteczny ruch PR-owy, a część mediów powtarzała narrację o Mythosie bez wystarczającego dystansu. Jednocześnie nawet krytyczne głosy nie sprowadzają tematu do zera. Chodzi raczej o to, żeby oddzielić realny postęp techniczny od marketingowej hiperboli.

Reuters zebrał głosy praktyków, którzy mówili podobnie: obawy przed „unfettered hacking” są przesadzone, ale Mythos jest realnym postępem w wyszukiwaniu podatności. Według cytowanych ekspertów prawdziwym problemem nie jest samo znalezienie większej liczby błędów, tylko walidacja, priorytetyzacja i naprawianie ich bez psucia systemów. Wskazywano też, że maksymalne wykorzystanie takich modeli wymaga dużej mocy obliczeniowej, harnessa i dojrzałego procesu.

To jest najrozsądniejsza pozycja.

Panika jest zła, bo prowadzi do kupowania narzędzi bez procesu.

Lekceważenie jest jeszcze gorsze, bo modele już zmieniają tempo vulnerability research.

Najbardziej prawdopodobny scenariusz nie wygląda tak:

AI jutro zastąpi wszystkich pentesterów.

Bardziej realistyczny scenariusz wygląda tak:

AI zwiększy throughput wyszukiwania błędów.
AI zwiększy liczbę półzweryfikowanych zgłoszeń.
AI skróci czas od odkrycia do próby wykorzystania.
AI wymusi lepszy triage, reachability analysis i patch pipeline.
AI przesunie wartość z samego "znalezienia" na "zweryfikowanie, naprawienie i wdrożenie".

Co to może znaczyć dla branży cyberbezpieczeństwa?

Pierwsza zmiana: samo wykrywanie będzie tańsze.

Przez lata znalezienie nietrywialnej podatności było bardzo cenne samo w sobie. Nadal będzie cenne, ale jego relatywna wartość zacznie spadać, jeśli modele będą w stanie generować setki sensownych hipotez w miejscach, gdzie wcześniej trzeba było pracy wielu ludzi.

Wartość przesunie się gdzie indziej:

Czy to jest exploitable?
Czy jest reachable?
Czy dotyczy produkcji?
Czy dotyczy krytycznego assetu?
Czy mamy kompensujące kontrole?
Czy umiemy to naprawić?
Czy fix jest bezpieczny?
Czy można wdrożyć go globalnie?
Czy mamy telemetry po wdrożeniu?

Forrester ujął to mocno: AI może złamać dotychczasowy playbook vulnerability managementu. Problemem przestaje być tylko „czy znajdziemy podatności”, a staje się „czy organizacja potrafi absorbować, priorytetyzować i naprawiać szybciej niż przeciwnik”. Forrester wskazuje też na rolę SBOM, reachability, attack path modeling, impact analysis, kompensujących kontroli i home-field advantage, czyli kontekstu, którego zewnętrzny atakujący zwykle nie ma.

Druga zmiana: triage stanie się polem walki.

Dojrzały pipeline vulnerability management powinien traktować AI-generated finding jako obiekt przechodzący przez stany:

new
  -> reproduced
  -> deduplicated
  -> reachable
  -> exploitable_or_not
  -> prioritized
  -> assigned
  -> patched
  -> regression-tested
  -> deployed
  -> monitored
  -> closed

Jeśli organizacja pomija te stany, to ma chaos.

Przykład złego procesu:

AI znajduje 500 findingów.
Wszystkie wpadają jako High do Jira.
Developerzy ignorują połowę.
AppSec ręcznie waliduje najgłośniejsze.
SOC nie wie, co monitorować.
CISO dostaje dashboard z czerwonymi kafelkami.
Po miesiącu nikt nie wie, czy ryzyko spadło.

Przykład lepszego procesu:

AI znajduje 500 findingów.
Dedupe redukuje je do 83 root causes.
Trace potwierdza 21 reachable paths.
Runtime exposure wskazuje 9 publicznie dostępnych komponentów.
Business criticality podbija 4 do P1.
Regression testing przechodzi dla 3.
Jedna poprawka wymaga feature flagi i WAF rule jako kontroli tymczasowej.
SOC dostaje konkretne reguły detekcyjne.

To jest różnica między „mamy AI” a „mamy proces”.

Trzecia zmiana: patch management będzie pod presją AI-speed.

Verizon DBIR 2026 wskazuje, że wykorzystanie podatności stało się najczęstszym punktem wejścia do breachy, odpowiadając za 31% przypadków, i że AI skraca okno między wiedzą o luce a jej wykorzystaniem z miesięcy do godzin. Raport mówi też o capacity crisis: organizacje będą zasypywane łatkami, ekspozycjami i sygnałami, które trzeba obsłużyć.

To nie znaczy, że każdy zespół musi mieć dwugodzinne SLA na wszystko. To byłoby absurdalne.

Znaczy raczej, że trzeba wiedzieć:

które systemy są publicznie wystawione,
które podatności mają znany exploit,
które assety są krytyczne,
które poprawki można wdrożyć szybko,
gdzie można użyć virtual patching,
gdzie trzeba ograniczyć blast radius,
gdzie rollback jest gotowy,
gdzie nie ma ownera i to jest osobne ryzyko.

Czwarta zmiana: pentesterzy nie znikną, ale zmieni się ich praca.

Mniej wartości będzie w mechanicznym szukaniu oczywistych bugów, które AI, SAST, DAST, fuzzing i reguły semgrepowe znajdą taniej.

Więcej wartości będzie w:

projektowaniu harnessów,
ustawianiu agentów walidacyjnych,
tworzeniu scenariuszy abuse case,
łączeniu findings z architekturą,
sprawdzaniu trust boundaries,
ocenie exploitability,
budowie PoC w kontrolowanym środowisku,
pisaniu testów regresji,
projektowaniu detekcji,
review poprawek,
threat modelingu.

Piąta zmiana: AppSec będzie musiał działać bliżej platform engineering.

Bo jeśli poprawka wymaga tygodnia ręcznych ustaleń, trzech wyjątków w CI/CD, niedziałającego stagingu i ownera, którego nie ma, to AI tylko szybciej pokaże, że problem nie leży w braku skanera.

Problem leży w operacyjnej zdolności do naprawiania.

Szósta zmiana: vendorzy security będą sprzedawać harness, nie chat.

Narzędzie przyszłości nie będzie wyglądało tak:

Okno czatu: "znajdź podatności w moim kodzie".

Będzie raczej wyglądało tak:

Modele + code graph + dependency graph + SBOM + runtime telemetry + CI/CD + sandbox + task orchestration + validation agents + reporting schema + vulnerability management integration.

To jest znacznie mniej sexy niż demo chatbota, ale dużo bardziej użyteczne.

Forrester wskazuje też skutki drugiego i trzeciego rzędu: wpływ na pentesting, vulnerability management, cyber insurance, regulacje, disclosure, pracę maintainerów open source i wymagania wobec vendorów. Samo „znajdowanie” przestaje być najważniejszym wyróżnikiem. Wartość przesuwa się do interpretacji, priorytetyzacji, remediation guidance i zdolności dowiezienia decyzji pod presją czasu.

Co to znaczy dla atakujących?

Dla atakujących AI nie musi być magiczne. Wystarczy, że jest praktyczne.

Google Threat Intelligence Group opisało przypadek cybercrime’owego threat actora, który miał użyć AI do odkrycia i weaponizacji zero-daya omijającego 2FA w popularnym open-source’owym webowym narzędziu administracyjnym. Google oceniło z wysoką pewnością, że AI wspierało odkrycie i przygotowanie exploita, wskazując m.in. na artefakty w kodzie i charakter błędu logicznego.

To ważne, bo to nie był hollywoodzki scenariusz z autonomicznym superagentem. To był bardziej przyziemny, a przez to groźniejszy wzorzec:

AI pomaga w analizie.
AI pomaga w iteracji.
AI pomaga w pisaniu kodu.
AI pomaga w dokumentowaniu.
AI pomaga w testowaniu wariantów.
Człowiek albo grupa decyduje, co z tym zrobić.

Google wskazuje też szersze użycie AI przez aktorów zagrożeń: exploit research, malware development, obfuscation, reconnaissance, social engineering, influence operations, a także używanie modeli i agentów do powtarzalnego testowania payloadów.

Efekt jest prosty:

Słabsi atakujący dostają lepszy warsztat.
Silniejsi atakujący dostają większy throughput.

Nie każdy script kiddie nagle stanie się ekspertem od exploitation. Ale więcej osób będzie w stanie wykonywać zadania, które wcześniej wymagały większego doświadczenia:

czytanie crashy,
pisanie reproducerów,
modyfikowanie PoC,
analiza patch diffów,
szukanie podobnych błędów,
automatyzacja reconu,
generowanie wariantów payloadów,
tworzenie bardziej przekonujących phishingów,
łączenie danych z wielu źródeł.

To jest wystarczająco duża zmiana, żeby defenderzy nie mogli jej ignorować.

Co to znaczy dla obrońców?

Naturalna reakcja brzmi:

Musimy szybciej skanować i szybciej patchować.

To prawda, ale tylko częściowo.

Cloudflare pisze wprost, że samo „scan faster, patch faster” nie wystarczy. Jeśli regression testing trwa dzień, a organizacja deklaruje dwugodzinne SLA na poprawkę, to ktoś będzie musiał pominąć testy. A wtedy można wprowadzić regresję, awarię albo nową podatność.

Lepsza reakcja brzmi:

Musimy projektować systemy tak, żeby pojedyncza podatność nie kończyła się katastrofą.
Musimy mieć pipeline do szybkiego, ale bezpiecznego patchowania.
Musimy umieć priorytetyzować według ekspozycji, a nie tylko CVSS.
Musimy mieć logi, które pozwalają potwierdzić reachability i exploitation attempts.

Architektura musi ograniczać blast radius

Jeśli pojedynczy bug w parserze daje pełne przejęcie systemu, to problemem jest nie tylko parser.

Praktyczne kontrole:

segmentacja sieci,
least privilege,
krótkie tokeny,
oddzielne konta serwisowe,
sandboxing,
container isolation,
seccomp/AppArmor/SELinux,
WAF/API gateway,
RASP tam, gdzie ma sens,
rate limiting,
feature flags,
szybki rollback,
centralny rollout poprawek,
secrets management,
egress filtering,
detekcja procesów potomnych.

Wtedy nawet jeżeli AI znajdzie podatność, atakujący musi przejść przez kolejne warstwy.

Exposure management zamiast samego CVSS

CVSS jest użyteczny, ale nie wystarcza.

Przykład:

CVE A:
CVSS 9.8
Komponent nie jest używany w produkcji.
Brak publicznej ekspozycji.
Brak runtime signal.

CVE B:
CVSS 7.5
Publiczny endpoint.
Brak auth.
Znany exploit.
Asset krytyczny.
Runtime telemetry pokazuje próby skanowania.

Który problem jest pilniejszy?

W realnej organizacji potrzebujesz scoringu z kontekstem:

finding_id: AI-VR-2026-0042
internet_reachable: true
attacker_controlled_input: true
auth_required: false
known_exploit: true
runtime_signal: observed
asset_criticality: high
business_service: payments
data_sensitivity: customer_pii
compensating_control:
  waf_rule: partial
  edr_visibility: true
owner: payments-platform
patch_available: true
rollback_ready: true
priority: P1

To jest exposure management. Nie samo „ile ma CVSS”.

Logging i detekcja wracają do centrum

AISI rekomenduje kompleksowe logowanie jako jeden z fundamentów obrony przed przyszłymi modelami cyber AI. To nie jest przypadek. Bez logów nie da się szybko odpowiedzieć, czy znaleziony przez AI błąd był już próbowany, czy endpoint jest skanowany, czy exploit attempt dotarł do komponentu, czy kontrola kompensująca zadziałała.

Przykładowe logi, które mają sens przy analizie podatności w workerze konwersji obrazów:

2026-05-21T10:14:22Z gateway request_id=req-91ad
route=/api/v1/uploads
source_ip_class=internet
auth=valid_user_token
tenant_id=tnt-42
waf_action=allow
content_type=multipart/form-data
file_type=png
file_size=184221
2026-05-21T10:14:23Z upload-service request_id=req-91ad
job_id=job-8fd12
filename_normalized=true
storage_path=/safe/blob/8f/d12/input.png
user_controlled_fields=filename,metadata
queued_worker=image-converter
2026-05-21T10:14:24Z image-worker job_id=job-8fd12
exec_mode=argv_array
shell=false
child_process=convert
input_path=/safe/blob/8f/d12/input.png
output_path=/safe/blob/8f/d12/output.webp
result=success

Przykładowa reguła detekcyjna do korelacji w EDR/SIEM:

process.name in ("sh", "bash", "cmd.exe", "powershell.exe")
AND parent.name in ("image-worker", "upload-service", "convert-wrapper")
AND event.source = "production"

Druga reguła, bardziej aplikacyjna:

route in ("/api/v1/uploads", "/api/v1/imports")
AND http.status >= 500
AND worker.error_type in ("parser_crash", "unexpected_child_process", "sandbox_violation")

Bez takich danych AI-generated finding zostaje papierem. Z takimi danymi można powiedzieć:

Błąd jest reachable.
Nie widzimy dotychczas exploitation attempts.
WAF częściowo blokuje payload class.
Worker nie uruchamia shella.
Ryzyko jest realne, ale blast radius ograniczony.
Patch wdrażamy w normalnym trybie P2.

albo:

Błąd jest reachable.
W logach są próby fuzzingu endpointu.
Widzimy nietypowe 500 i sandbox violations.
WAF nie blokuje klasy wejścia.
Podnosimy do P1 i wdrażamy virtual patching przed kodowym fixem.

To jest praktyczna różnica.

Praktyczny przykład: AI-assisted triage bez magii

Załóżmy, że model zwraca finding:

Finding: Possible command injection in image conversion worker

Source:
POST /api/v1/uploads -> multipart field "filename"

Path:
upload_controller.handle()
  -> upload_service.store()
  -> conversion_queue.enqueue()
  -> image_worker.convert()

Sink:
legacy_convert(filename, output_format)

Hypothesis:
The filename may be concatenated into a shell command.

Confidence:
medium

PoC:
not validated

Reachability:
unknown

To jeszcze nie jest podatność. To jest trop.

Pierwszy krok: walidacja kodu.

grep -R "legacy_convert" -n ./services/image-worker
grep -R "subprocess\|os.system\|exec(" -n ./services/image-worker
grep -R "shell=True" -n ./services/image-worker

Podejrzany kod:

import subprocess

def legacy_convert(filename: str, output_path: str) -> None:
    cmd = f"convert {filename} {output_path}"
    subprocess.run(cmd, shell=True, check=True)

To wygląda źle. Ale dalej nie wiemy, czy filename jest naprawdę kontrolowany przez użytkownika i czy ta ścieżka działa w produkcji.

Bezpieczniejszy wariant:

import subprocess
from pathlib import Path

SAFE_INPUT_DIR = Path("/safe/blob").resolve()
SAFE_OUTPUT_DIR = Path("/safe/output").resolve()

def ensure_safe_path(path: Path, base: Path) -> Path:
    resolved = path.resolve()
    if not str(resolved).startswith(str(base)):
        raise ValueError("Unsafe path")
    return resolved

def convert_image(input_path: str, output_path: str) -> None:
    safe_input = ensure_safe_path(Path(input_path), SAFE_INPUT_DIR)
    safe_output = ensure_safe_path(Path(output_path), SAFE_OUTPUT_DIR)

    subprocess.run(
        ["convert", str(safe_input), str(safe_output)],
        shell=False,
        check=True,
    )

Drugi krok: bezpieczna reprodukcja na stagingu. Nie potrzebujemy agresywnego payloadu. Najpierw sprawdzamy przepływ danych i tryb wykonania.

curl -X POST "https://staging.example.local/api/v1/uploads" \
  -H "Authorization: Bearer $TOKEN" \
  -F "file=@sample.png" \
  -F "filename=test-input.png"

Trzeci krok: log walidacyjny.

2026-05-21T10:14:22Z gateway request_id=req-91ad
route=/api/v1/uploads
auth=valid_user
waf_action=allow
2026-05-21T10:14:23Z upload-service request_id=req-91ad
original_filename=test-input.png
normalized_filename=8fd12-input.png
user_filename_used_in_worker=false
2026-05-21T10:14:24Z image-worker job_id=job-8fd12
exec_mode=argv_array
shell=false
input_source=storage_path
user_controlled_filename=false
result=no_injection_path

W tym wariancie finding może zostać zdegradowany:

{
  "finding": "possible command injection in image conversion worker",
  "status": "not_exploitable_in_current_path",
  "reason": "user-controlled filename is normalized before worker execution; worker uses argv array with shell=false",
  "residual_risk": "legacy_convert still exists but is not reachable from upload path",
  "recommended_action": "remove legacy_convert or add regression test proving it is unreachable"
}

Ale inny wynik też jest możliwy:

2026-05-21T10:14:24Z image-worker job_id=job-8fd12
exec_mode=shell_string
shell=true
input_source=original_filename
user_controlled_filename=true
result=unsafe_sink_reached

Wtedy raport powinien wyglądać inaczej:

{
  "finding": "unsafe shell invocation in image conversion worker",
  "status": "reachable_security_bug",
  "attacker_controlled_input": true,
  "internet_reachable": true,
  "auth_required": true,
  "production_config_affected": true,
  "exploitability": "not_confirmed_rce",
  "impact": "unsafe command construction; potential command injection",
  "recommended_fix": [
    "replace shell=True with argv array",
    "use generated storage paths instead of user filenames",
    "add allowlist for input/output directories",
    "add regression test for upload-to-worker flow"
  ],
  "temporary_controls": [
    "block suspicious filename metacharacters at API gateway",
    "monitor unexpected child processes from image-worker",
    "restrict worker egress",
    "enable tighter sandbox profile"
  ]
}

To jest właśnie różnica między „AI znalazło podatność” a „organizacja wykonała vulnerability triage”.

Dlaczego to ma znaczenie

Dla CISO

Mythos-like modele zmieniają ekonomikę bezpieczeństwa. Nie wystarczy kupić narzędzia z AI i dopisać go do roadmapy.

Trzeba finansować cały system:

asset inventory,
SBOM,
exposure management,
runtime telemetry,
patch pipelines,
testy regresji,
staging,
rollback,
vulnerability management,
AppSec engineering,
SOC correlation,
governance AI-generated findings.

Najgorsza wersja wdrożenia AI w bezpieczeństwie to taka, w której CISO dostaje więcej czerwonych wykresów, ale organizacja nie naprawia szybciej najważniejszych problemów.

Dla AppSec

AppSec nie będzie miał mniej pracy. Będzie miał inną pracę.

Największą wartością stanie się:

walidacja,
deduplikacja,
reachability analysis,
exploitability assessment,
priorytetyzacja,
tworzenie testów regresji,
spięcie findings z ownerami,
kontrola jakości raportów AI.

AppSec będzie musiał nauczyć modele, jak organizacja rozumie ryzyko. Inaczej modele zaleją backlog.

Dla SOC

SOC dostanie więcej sygnałów.

Nie tylko z WAF-a, EDR-a i SIEM-a, ale też z AppSec, CI/CD, repozytoriów, dependency scanningu, SBOM, bug bounty, disclosure i AI-assisted scanners.

Potrzebne będą korelacje typu:

AI finding: parser crash reachable from /api/v1/imports
+
WAF telemetry: fuzzing attempts on /api/v1/imports
+
EDR telemetry: sandbox violations in import-worker
+
CI/CD: patch pending
=
raise incident priority

Bez takiego spięcia SOC zobaczy tylko kolejne alerty.

Dla developerów

AI nie zwalnia z bezpiecznego projektowania.

Wręcz przeciwnie. Jeśli model będzie szybciej znajdował błędy, to developerzy szybciej zobaczą konsekwencje złych wzorców:

shell=True,
brak allowlist,
niespójna autoryzacja,
ręczne parsowanie tokenów,
brak walidacji aud/iss/exp w JWT,
IDOR w API,
brak tenant isolation,
niebezpieczne deserializacje,
parsery bez limitów,
brak testów regresji dla security bugów.

Dobre wzorce kodowania, OWASP ASVS, secure SDLC, threat modeling i memory safety nie staną się mniej ważne. Staną się bardziej widoczne.

Dla vendorów

Klienci zaczną zadawać inne pytania.

Nie tylko:

Czy mieliście CVE?
Jakie macie SLA patchowania?

ale też:

Czy używacie AI-assisted vulnerability research?
Jak walidujecie AI-generated findings?
Czy macie proces deduplikacji?
Jak odróżniacie bug od exploitable vulnerability?
Jak wygląda responsible disclosure?
Czy macie SBOM?
Czy umiecie wskazać reachability?
Jak szybko wdrażacie fix na wszystkie instancje?
Jakie macie kompensujące kontrole?

Vendor bez odpowiedzi na te pytania będzie wyglądał coraz słabiej.

Checklista techniczna dla zespołów

Co sprawdzić w najbliższym tygodniu

[ ] Czy mamy aktualny asset inventory dla publicznie wystawionych usług?
[ ] Czy wiemy, które repozytoria obsługują krytyczne ścieżki biznesowe?
[ ] Czy mamy SBOM dla krytycznych aplikacji?
[ ] Czy vulnerability management widzi runtime exposure?
[ ] Czy umiemy odróżnić dependency present od dependency reachable?
[ ] Czy staging pozwala odtworzyć krytyczne ścieżki wejścia?
[ ] Czy mamy pipeline do szybkiego, ale bezpiecznego patchowania?
[ ] Czy testy regresji obejmują security fixes?
[ ] Czy logi pokazują przepływ user-controlled input?
[ ] Czy potrafimy deduplikować findings po root cause?
[ ] Czy mamy ownerów dla krytycznych komponentów?
[ ] Czy mamy gotowy proces na AI-generated vulnerability reports?
[ ] Czy wiemy, kiedy zgłoszenie trafia do security, a kiedy do zwykłego bug trackera?
[ ] Czy umiemy powiedzieć: flaw, security bug, vulnerability czy exploitable vulnerability?

Co sprawdzić w logach

[ ] Nietypowe requesty do endpointów upload/import/convert.
[ ] Duże skoki 4xx/5xx na parserach.
[ ] Crash loops workerów.
[ ] Sandbox violations.
[ ] Nietypowe child processes.
[ ] Wywołania shelli z procesów aplikacyjnych.
[ ] Próby fuzzingu API.
[ ] Przekroczenia rate limitów.
[ ] Payloady w polach, które zwykle są przewidywalne.
[ ] Nietypowe nazwy plików i metadane.
[ ] Błędy walidacji JWT, szczególnie aud/iss/exp.
[ ] Próby dostępu do cudzych object_id, tenant_id, account_id.
[ ] Nietypowe redirect_uri i callback_url.
[ ] Błędy parserów archiwów, PDF, obrazów, XML, YAML.

Co przetestować na stagingu

[ ] Czy publiczne wejścia faktycznie docierają do ryzykownych sinków?
[ ] Czy WAF/API gateway blokuje nietypowe klasy payloadów?
[ ] Czy EDR widzi nietypowe procesy potomne?
[ ] Czy worker działa z minimalnymi uprawnieniami?
[ ] Czy egress filtering ogranicza skutki RCE?
[ ] Czy rollback działa i jest przećwiczony?
[ ] Czy patch nie łamie zależności?
[ ] Czy alerty trafiają do SOC?
[ ] Czy test regresyjny potwierdza fix?
[ ] Czy feature flag pozwala szybko wyłączyć ryzykowną funkcję?

Minimalny harness AI-assisted vulnerability research

Nie zaczynaj od całej organizacji. Zacznij od jednego krytycznego repozytorium.

1. Recon
   - opisz architekturę,
   - entry pointy,
   - trust boundaries,
   - build commands,
   - risky sinks.

2. Hunt
   - wybierz jedną klasę błędów,
   - np. command injection, IDOR, JWT validation, path traversal,
   - uruchom wiele wąskich zadań.

3. Validate
   - osobny agent albo człowiek próbuje obalić finding,
   - wymagaj reproduktora,
   - wymagaj ścieżki reachability.

4. Dedupe
   - grupuj po root cause,
   - nie generuj dziesięciu ticketów na jeden wrapper.

5. Trace
   - sprawdź, czy attacker-controlled input dociera do sinka,
   - połącz kod, logi i staging.

6. Report
   - zapisuj wynik w schemacie,
   - integruj z vulnerability management,
   - dodawaj ownera, priority, evidence i fix strategy.

7. Monitor
   - sprawdź logi po wdrożeniu,
   - dodaj detekcje,
   - zamknij finding dopiero po deployu i walidacji.

Minimalna polityka dla AI-generated reports

To warto mieć spisane, zanim backlog eksploduje.

AI-generated report może trafić do security queue tylko wtedy, gdy zawiera:

[ ] jasny komponent,
[ ] wersję albo commit,
[ ] opis źródła inputu,
[ ] opis sinka,
[ ] minimalny reproducer lub evidence,
[ ] informację o reachability,
[ ] ocenę wpływu bez spekulacji,
[ ] informację o duplikatach,
[ ] propozycję poprawki albo ścieżki dalszej walidacji.

Raport bez tych elementów nie jest „critical vulnerability”. Jest hipotezą.

I hipoteza też może być wartościowa, ale musi trafić do właściwej kolejki.

Konkluzja: Mythos jest mocny, ale to nie model jest produktem końcowym

Mythos nie jest słaby. Właśnie dlatego trzeba potraktować go poważnie.

Cloudflare pokazał coś ważniejszego niż samą skuteczność modelu. Pokazał, że realna przewaga nie bierze się z prompta, tylko z procesu: recon, hunt, validate, gapfill, dedupe, trace, report. Model jest silnikiem. Harness jest układem kierowniczym, hamulcami, telemetryką i procedurą pit stopu.

Bez tego AI robi hałas.

Z tym AI może dać realną przewagę.

Największy błąd, jaki może teraz zrobić branża, to pomylić finding z bezpieczeństwem.

Finding nie jest bezpieczeństwem.
PoC nie jest bezpieczeństwem.
Ticket nie jest bezpieczeństwem.
Dashboard nie jest bezpieczeństwem.

Bezpieczeństwo zaczyna się wtedy, gdy organizacja potrafi:

zrozumieć finding,
obalić false positive,
potwierdzić reachability,
ocenić exploitability,
ustalić impact,
znaleźć ownera,
wdrożyć fix,
przetestować regresję,
monitorować próby wykorzystania,
ograniczyć blast radius.

Linus Torvalds pokazał, co się dzieje, gdy tego brakuje: prywatny kanał security zamienia się w kolejkę AI-generated bug reports, z których część jest duplikatami, część zwykłymi bugami, a część wymaga pracy maintainerów tylko po to, żeby ustalić, czy w ogóle jest o czym rozmawiać. Cloudflare pokazał drugą stronę: da się to robić lepiej, ale trzeba zbudować system wokół modelu. Mozilla pokazała, że AI może znaleźć ogromną liczbę błędów, ale poprawki dalej dowożą ludzie, procesy i release engineering. AISI pokazało, że możliwości rosną, ale benchmark to nie produkcyjna sieć z aktywnymi defenderami. Google pokazało, że atakujący już eksperymentują z AI w realnych operacjach. Verizon i Forrester pokazują, że vulnerability management musi przejść z trybu „skanuj i patchuj” do trybu exposure-driven, kontekstowego działania.

I to jest najlepsza odpowiedź na pytanie z tytułu.

Mythos jednak nie taki wspaniały?

Jest wspaniały tam, gdzie potrafi przyspieszyć badanie, wygenerować hipotezę, zbudować PoC i pomóc przejść od „może” do „sprawdźmy”.

Nie jest wspaniały tam, gdzie organizacja nie ma asset inventory, stagingu, logów, ownerów, testów regresji, procesu triage’u i zdolności do patchowania.

AI nie zastępuje dojrzałości bezpieczeństwa.

AI bardzo szybko obnaża jej brak.

Sprawdź w logach, które endpointy przyjmują user-controlled input i docierają do parserów, workerów, konwerterów plików albo wrapperów systemowych.

Potem wybierz jedno krytyczne repozytorium i zrób mały harness:

recon,
hunt,
validate,
trace,
dedupe,
report.

Nie zaczynaj od:

AI, znajdź podatności w całym kodzie.

Zacznij od:

Sprawdź jedną klasę błędów.
W jednym komponencie.
Na jednej realnej granicy zaufania.
Z walidacją.
Z logami.
Z testem regresji.
Z planem wdrożenia poprawki.

Bo w erze Mythosa przewagę będzie miał nie ten, kto wygeneruje najwięcej zgłoszeń.

Przewagę będzie miał ten, kto najszybciej odróżni szum od ryzyka i dowiezie bezpieczną poprawkę.

Podsumwanie

Mythos nie jest ani zabawką, ani magicznym pentesterem, który rozwiąże za nas problem bezpieczeństwa. To bardzo mocny sygnał, że vulnerability research wchodzi w etap, w którym samo „znalezienie błędu” przestaje być najtrudniejszym elementem gry.

Cloudflare pokazał, że prawdziwa wartość AI pojawia się dopiero wtedy, gdy model działa w kontrolowanym procesie: rozumie architekturę, poluje na konkretne klasy błędów, generuje hipotezy, waliduje je, sprawdza reachability, deduplikuje wyniki i produkuje raport, który da się zamienić w poprawkę. Bez tego dostajemy dokładnie ten chaos, przed którym ostrzegał Linus Torvalds: zalew zgłoszeń, duplikatów, półprawd i bugów udających podatności. Dla branży wniosek jest prosty: AI przyspieszy zarówno atakujących, jak i obrońców, ale przewagę zyskają nie ci, którzy wygenerują najwięcej findingów, tylko ci, którzy potrafią szybko odróżnić szum od realnego ryzyka, potwierdzić exploitability, wdrożyć poprawkę, ograniczyć blast radius i sprawdzić w logach, czy ktoś już próbuje wykorzystać tę klasę błędów.

Mythos jest mocny. Ale dopiero AppSec, SOC, platform engineering, dobre logowanie, sensowny patch management i twardy triage robią z niego narzędzie bezpieczeństwa, a nie generator kolejnych czerwonych ticketów.

Bibliografia