Project Glasswing (Anthropic): AI, Które Znajduje I Exploituje Podatności Szybciej Niż Człowiek - Security Bez Tabu

Project Glasswing (Anthropic): AI, Które Znajduje I Exploituje Podatności Szybciej Niż Człowiek

Co znajdziesz w tym artykule?

Nie chodzi o model. Chodzi o zmianę zasad gry

Jeśli spojrzysz na Project Glasswing jak na kolejny launch modelu AI, przeoczysz sedno. Anthropic nie zrobiło publicznej premiery „nowego Claude’a do cybera”. Zrobiło coś dużo ciekawszego: zamknęło dostęp do modelu, uruchomiło program defensywny z udziałem AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA i Palo Alto Networks, rozszerzyło dostęp na ponad 40 kolejnych organizacji utrzymujących krytyczne oprogramowanie, dorzuciło do 100 mln USD kredytów oraz zapowiedziało publiczny raport z wnioskami i poprawkami w ciągu 90 dni. To nie wygląda jak marketing produktu. To wygląda jak zarządzanie ryzykiem wokół capability, które zaczynają mieć znaczenie systemowe dla bezpieczeństwa software’u.

Anthropic twierdzi przy tym rzeczy, obok których trudno przejść obojętnie: ich nieudostępniony publicznie model Claude Mythos Preview ma już znajdować tysiące podatności wysokiej wagi, w tym luki w każdym głównym systemie operacyjnym i każdej dużej przeglądarce, a w testach potrafił nie tylko wykrywać, ale też eksploatować zero-daye i samodzielnie zamieniać N-daye w działające exploity. Ponieważ ponad 99% znalezionych przez nich luk nie było jeszcze załatanych, opisali tylko wycinek wyników. Sama ta proporcja jest wymowna.

I tu pojawia się najważniejsza myśl do całego tekstu. Nie chodzi o to, czy za rok model będzie nazywał się Mythos, Opus 6 czy jeszcze inaczej. Chodzi o zmianę mechaniki gry. Przez lata zakładaliśmy, że największym problemem jest znalezienie podatności. Glasswing sugeruje coś innego: wchodzimy w moment, w którym discovery zaraz przestanir być głównym bottleneckiem, a prawdziwe wąskie gardła przesuwają się do triage’u, walidacji, disclosure, patchingu i incident response. Anthropic zresztą samo wskazuje te obszary jako te, które trzeba teraz przeprojektować.

Jest tu też ważny bezpiecznik. Tytuł tego artykułu jest mocny, ale warto być precyzyjnym: Anthropic nie pokazuje otwartego benchmarku „model kontra zespół komercyjnych pentesterów we wszystkich typach engagementów”. Ich teza dotyczy przede wszystkim wykrywania i eksploatacji podatności w zadaniach technicznych. Gdy zestawimy to z niezależnym badaniem Stanforda z 2025 roku, dostajemy dużo bardziej użyteczny obraz: mocny agent AI może pokonać większość ludzi w realistycznym środowisku, ale najlepszy człowiek nadal wygrywa overall, a AI ma konkretne słabości — zwłaszcza przy zadaniach GUI i przy kontroli jakości wyników. I właśnie w tej luce między hype’em a praktyką siedzi prawdziwa wartość Glasswing.

Zanim przejdziemy dalej, warto jasno oddzielić trzy rzeczy:

  • fakty: Glasswing istnieje jako inicjatywa defensywna, a Anthropic raportuje bardzo wysokie capability modeli w cyberze
  • obserwacje: AI już dziś osiąga wyniki porównywalne do ludzi w części zadań (np. badanie Stanford ARTEMIS)
  • prognoza: te capability będą się rozszerzać i zmieniać sposób, w jaki działa security

Ten artykuł łączy te trzy warstwy — ale warto mieć świadomość, gdzie kończą się dane, a zaczynają wnioski.

Project Glasswing: co Anthropic naprawdę ogłosiło

To nie jest publiczny model. To jest kontrolowany research preview

Najpierw porządek. Claude Mythos Preview nie jest zwykłym modelem dostępnym z panelu i z samodzielnym signupem. Według dokumentacji Anthropic jest to osobny research preview przeznaczony do defensywnych workflow bezpieczeństwa w ramach Project Glasswing, z dostępem wyłącznie na zaproszenie i bez self-service. Anthropic pisze wprost, że nie planuje udostępnić go szeroko teraz; najpierw chce zbudować zabezpieczenia, które ograniczą najbardziej niebezpieczne odpowiedzi modelu.

To bardzo dużo mówi. Jeżeli vendor AI uznaje, że capability modelu są na tyle mocne, iż wymagają ograniczonej dystrybucji, to znaczy, że przestajemy rozmawiać o „fajnej funkcji dla devów”. Zaczynamy rozmawiać o dual-use capability, która może pomóc defenderom, ale przy nieostrożnym release równie dobrze skrócić czas od disclosure do masowego exploitation.

Glasswing to program defensywny, a nie produkt

Zakres projektu też jest charakterystyczny. Partnerzy Glasswing mają używać Mythos Preview do szukania i naprawiania słabości w swoich systemach bazowych i w dużej części wspólnej powierzchni ataku internetu. Anthropic przewiduje tu takie zadania jak lokalne wykrywanie podatności, black-box testing binarek, zabezpieczanie endpointów i pentesty systemów. Dodatkowo firma zapowiedziała zestaw praktycznych rekomendacji dla branży w obszarach vulnerability disclosure, software updates, open-source i supply chain security, secure-by-design SDLC, automatyzacji triage’u i automatyzacji patchowania.

To jest moment, w którym warto zatrzymać się na chwilę. Normalny komunikat produktowy mówiłby: „nasz model jest świetny do secure codingu”. Tutaj przekaz brzmi inaczej: „mamy capability, które mogą rozwalić obecny rytm bezpieczeństwa oprogramowania, więc zbieramy hyperscalerów, vendorów security, bank i maintainerów open source, żeby nauczyć się bronić, zanim podobne możliwości rozpłyną się po rynku”. To jest jakościowo inna kategoria problemu.

Najciekawsze w Glasswing jest to, czego nie trzeba było trenować „na hakera”

Anthropic podkreśla jeszcze jedną rzecz: tych zdolności nie uzyskało przez jawne trenowanie „cyber modelu do exploitów”. Według ich opisu capability Mythos Preview wyniknęły z ogólnej poprawy w kodowaniu, rozumowaniu i autonomii. To ważne, bo oznacza, że cyber capability są pochodną ogólnego postępu w frontier models, a nie czymś, co można zamknąć do jednego, egzotycznego toru rozwoju. Innymi słowy: nawet jeśli zablokujesz jeden model, trend pozostaje.

Dla praktyka w AppSec i blue teamie to oznacza prostą rzecz. Nie można już myśleć o AI security tylko jako o „funkcji w SIEM” albo „copilocie do kodu”. Gdy poprawiają się kodowanie, reasoning i autonomia, poprawia się też zdolność modeli do robienia rzeczy, które wcześniej wymagały lat doświadczenia w vulnerability research.

Co naprawdę znaczy, że AI „znajduje zero-daye szybciej niż pentester”

Zero-day, N-day i exploit chain — bez porządkowania pojęć łatwo wpaść w hype

Zero-day to podatność nieznana wcześniej obrońcom i producentowi albo co najmniej niezałatana publicznie w momencie, gdy atakujący może z niej skorzystać. N-day to błąd już znany — zwykle z CVE i patchem — ale nadal praktycznie groźny, bo organizacje nie wdrożyły poprawki. Exploit chain to z kolei sekwencja podatności i technik, które pojedynczo mogą wyglądać niegroźnie, ale razem prowadzą do realnego przejęcia systemu: na przykład info leak, potem memory corruption, potem escape z sandboxa, potem privilege escalation.

To rozróżnienie jest kluczowe, bo marketing lubi wrzucać wszystko do worka „AI hackuje”. Tymczasem obrona ma różne wyzwania dla 0-dayów i N-dayów. Zero-day zmienia priorytety w researchu i disclosure. N-day zmienia priorytety w patch management i exposure management. Glasswing dotyka obu tych światów jednocześnie.

Anthropic opisuje capability, które wcześniej kojarzyliśmy z top-tier research

Na oficjalnej stronie Anthropic pisze, że Mythos Preview potrafi identyfikować i eksploatować zero-daye w każdym głównym systemie operacyjnym i każdej dużej przeglądarce. W technicznym wpisie badawczym idą jeszcze dalej: opisują m.in. znalezienie 27-letniego błędu w OpenBSD, autonomiczne napisanie exploita RCE na serwer NFS FreeBSD dającego pełny root bez uwierzytelnienia oraz browser exploit chain złożony z czterech podatności. Do tego w jednym z benchmarków, który wcześniej Opus 4.6 przechodził ledwie sporadycznie, Mythos wygenerował działające exploity 181 razy i uzyskał kontrolę nad rejestrami w 29 kolejnych próbach.

To nie są już opowieści w stylu „model wykrył brak csrf w formularzu”. To jest teren, na którym zwykle pracują ludzie siedzący w memory corruption, reverse engineeringu, exploit devie i internalsach systemowych.

Najbardziej niepokojące nie jest nawet to, że model znajduje błędy. Najbardziej niepokojące jest obniżenie progu wejścia

Anthropic pisze też, że osoby bez formalnego przygotowania security były w stanie zlecić Mythosowi znalezienie RCE i rano dostać gotowy exploit. To jest moment, który powinien zapalić lampkę nie tylko researchowi, ale też liderom zespołów obronnych. Bo prawdziwa zmiana nie polega wyłącznie na tym, że topowy ekspert staje się trochę szybszy. Prawdziwa zmiana polega na tym, że capability zaczynają przesuwać się w dół piramidy umiejętności.

W świecie ludzi dostęp do wysokiej klasy exploit developmentu był kosztowny: wymagał czasu, warsztatu, porażek, bardzo specyficznej wiedzy. W świecie modeli część tego kosztu może zostać zamieniona na koszty obliczeń, scaffolding i dobrą walidację. To właśnie dlatego Glasswing jest tak interesujące: ono pokazuje nie tylko wzrost jakości, ale też groźbę skali.

Ale „szybciej” nie znaczy „lepiej we wszystkim”

Tu znowu warto zdjąć nogę z gazu. Fakt, że model potrafi znaleźć i zamienić luki w exploity, nie oznacza automatycznie, że wygra każdy pentest, każdy red team, każdą ocenę bezpieczeństwa architektury czy każdą rozmowę z biznesem. Pentest to nie tylko wykrywanie memory corruptions albo CVE reachability. To również czytanie niejednoznacznych procesów, rozumienie intencji biznesowej, wykrywanie błędów autoryzacji ukrytych w workflow, pivoty przez nieoczywiste zależności i umiejętność powiedzenia klientowi: „ten bug sam w sobie nie wygląda groźnie, ale w waszym modelu rozliczeń oznacza realne nadużycie”.

I właśnie dlatego tytuł „AI znajduje zero-daye szybciej niż pentester” jest dobry jako haczyk, ale słaby jako pełna diagnoza. Lepsza diagnoza brzmi tak: AI bardzo szybko zwiększa swoją skuteczność w technicznych fragmentach pracy ofensywnej i defensywnej, a to wymusza przebudowę całego pipeline’u security.

Dlaczego Glasswing jest punktem zwrotnym dla vulnerability research

Discovery przestaje być głównym bottleneckiem

Przez długi czas myśleliśmy o bezpieczeństwie software’u tak: najtrudniej jest znaleźć naprawdę ważny błąd. Reszta — triage, patch, rollout — to już „organizacja pracy”. Glasswing odwraca tę intuicję. Jeśli model może w krótkim czasie znaleźć dużo więcej błędów wysokiej wagi niż wcześniej, discovery przestaje być rzadkim zasobem. Zaczyna nim być to, co organizacja zrobi dalej.

Anthropic mówi to wprost między wierszami. Ich rekomendacje nie koncentrują się na kupowaniu większej liczby skanerów. Koncentrują się na triage’u, software updates, disclosure, patching automation i automatyzacji IR. To bardzo mocny sygnał, gdzie naprawdę pękną procesy.

Dla wielu organizacji discovery nadal pozostaje problemem — Glasswing pokazuje raczej kierunek dla dojrzałych zespołów niż stan całego rynku.

Nowym bottleneckiem stają się triage, walidacja i patching

Spójrzmy na najbardziej praktyczny fragment z technicznego wpisu Anthropic. Firma pisze, że w przypadku N-dayów model potrafił przejść od identyfikatora CVE i hasha commita do działającego exploita w pełni autonomicznie, szybciej, taniej i bez interwencji człowieka. To oznacza, że czas „po ujawnieniu, ale przed wdrożeniem poprawki” staje się jeszcze bardziej toksyczny niż dotychczas. Jeśli kiedyś na weaponization było potrzeba dni albo tygodni pracy specjalisty, a teraz zaczyna wystarczać pipeline z modelem, to miesięczne okno patchingu przestaje być niedoskonałością procesu. Zaczyna być zaproszeniem.

To zmienia wszystko dla:

  • PSIRT i disclosure,
  • właścicieli produktów,
  • zespołów release engineering,
  • właścicieli systemów legacy,
  • maintainerów open source,
  • blue teamów monitorujących „patch gap exploitation”.

I nie trzeba wcale mieć dostępu do Mythos, żeby problem był realny. Wystarczy, że podobne capability będą stopniowo pojawiały się w kolejnych modelach.

Zmienia się ekonomia bugfindingu

Badanie Stanforda pokazuje jeszcze drugi wymiar tej zmiany: koszt. ARTEMIS działał w niektórych wariantach za około 18 USD na godzinę wobec około 60 USD na godzinę dla profesjonalnych pentesterów, przy jednoczesnej przewadze w systematycznej enumeracji i pracy równoległej. To nie jest tylko pytanie „czy AI jest tak dobre jak człowiek”. To jest również pytanie „jak często można uruchomić taką analizę i na jakiej skali”.

W praktyce oznacza to przejście z modelu:

  • jeden duży pentest kwartalny lub roczny,
  • kilka ręcznych review,
  • trochę SAST, trochę DAST,

do modelu:

  • ciągłe przeglądy kodu i zależności,
  • częste testy ukierunkowane na exposure,
  • automatyczny triage,
  • człowiek skupiony na walidacji, chainingu i impact analysis.

To nie znaczy, że klasyczny pentest znika. To znaczy, że przestaje być jedynym momentem prawdy.

Open source i supply chain wracają na środek stołu

Nieprzypadkowo Anthropic połączyło Glasswing z donacjami dla organizacji open source security i z rozszerzeniem dostępu na maintainerów krytycznej infrastruktury software’owej. Jeśli model potrafi znajdować dużo więcej podatności w popularnym kodzie bazowym, to ryzyko przenosi się błyskawicznie do całego łańcucha zależności. Jedna podatna biblioteka nie jest już „problemem jednego projektu”. Jest problemem setek lub tysięcy produktów, które ją transitively wciągnęły.

Tu właśnie wchodzą do gry SBOM, VEX, dependency hygiene, provenance i szybki rollout poprawek. Nie dlatego, że regulator tak chce. Dlatego, że bez tego nie będziesz nawet wiedzieć, gdzie kończy się twój blast radius.

Czy AI zastąpi pentestera? Nie tak, jak myśli marketing

Stanford 2025 dał nam lepszą odpowiedź niż nagłówki z social mediów

Wcześniej na Security Bez Tabu pojawił się materiał o badaniu Stanforda i to był bardzo zdrowy kontrapunkt do marketingowego szumu. Sam paper mówi jasno: w środowisku obejmującym około 8 000 hostów i 12 podsieci agent ARTEMIS zajął 2. miejsce, znalazł 9 poprawnych podatności, osiągnął 82% trafnych zgłoszeń i wyprzedził 9 z 10 ludzkich uczestników. Jednocześnie autorzy podkreślają przewagi agentów w systematycznej enumeracji, równoległej eksploatacji i koszcie, ale też wskazują dwa konkretne braki: wyższy poziom false positives i problemy z zadaniami opartymi o GUI. To bardzo dobrze koreluje z wnioskami, które już wcześniej wyciągano na łamach Security Bez Tabu: to nie jest zmierzch pentesterów, tylko zmiana proporcji między pracą manualną a pracą orkiestracyjną.

Gdzie AI realnie wygrywa

AI wygrywa tam, gdzie praca da się rozbić na systematyczne kroki:

  • enumeracja,
  • powtarzalne mutacje inputów,
  • szerokie przeszukiwanie dużej powierzchni ataku,
  • równoległe uruchamianie subagentów,
  • szybkie odtwarzanie N-dayów,
  • analiza dużych ilości kodu i diffa.

To nie są marginalne przewagi. To są dokładnie te fragmenty pracy, które przez lata zjadały czas zespołom AppSec i ofensywnym. Gdy agent nie męczy się, nie traci uwagi po sześciu godzinach i potrafi równolegle odpalić wiele torów eksploracji, zaczyna być po prostu lepszym robotnikiem do ciężkiej, szerokiej roboty. Stanford pokazuje to empirycznie, Anthropic — na jeszcze wyższym poziomie capability — praktycznie.

Gdzie człowiek nadal wygrywa

Człowiek nadal wygrywa tam, gdzie ważne są:

  • kontekst biznesowy,
  • rozumienie celu procesu,
  • odróżnienie „dziwnego zachowania” od realnego exploit path,
  • rozmowa z właścicielem systemu,
  • twórcze łączenie technicznych obserwacji z wiedzą domenową,
  • engagementy wymagające pracy w GUI, środowiskach z dużą ilością stanów, albo systemach, gdzie zachowanie zależy od niestandardowych interakcji.

Paper Stanforda daje tu dobry, twardy punkt zaczepienia: GUI i false positives dalej bolą agentów. A jeśli już agent ma problem z takim zadaniem w kontrolowanym badaniu, to tym bardziej ostrożnie trzeba podchodzić do obietnicy pełnej automatyzacji w światach typu gruby workflow biznesowy, ERP, systemy przemysłowe, środowiska hybrydowe czy testy wymagające mocnego modelowania wpływu.

Najważniejszy wniosek: AI nie zabiera zawodu. Zabiera część rzemiosła

Najrozsądniej opisać to tak: AI nie zastępuje pentestera jeden do jednego. AI zabiera mu dużą część pracy manualnej i mechanicznej, a zostawia albo wręcz wzmacnia rolę operatora, walidatora i architekta ścieżek ataku.

Stary model roli był mniej więcej taki:

  • szukam błędów,
  • ręcznie odtwarzam,
  • ręcznie piszę notatki,
  • ręcznie priorytetyzuję.

Nowy model wygląda tak:

  • projektuję workflow dla bugfindingu,
  • zlecam szeroką eksplorację,
  • waliduję wyniki,
  • łączę podatności w sensowne łańcuchy,
  • tłumaczę wpływ na biznes,
  • decyduję, co naprawdę jest warte eskalacji.

To nie jest degradacja zawodu. To jest jego specjalizacja na wyższym poziomie.

Dlaczego to ma znaczenie

Dla blue teamu

Blue team nie może już myśleć o exploicie jako o czymś, co „pojawi się za jakiś czas”. Jeśli weaponization N-dayów przyspiesza, to telemetryczna widoczność w krótkim oknie po disclosure staje się krytyczna. Trzeba szybciej:

  • korelować advisories z realnym exposure,
  • mapować assety do wersji,
  • wdrażać tymczasowe mitigacje,
  • szukać aktywnego skanowania i exploit attempts,
  • zamykać okno od publicznej informacji do wdrożonej poprawki.

To oznacza również zmianę pracy SOC. Więcej automatycznego triage’u, więcej wzbogacania alertów, więcej korelacji z exposure management, mniej ręcznego przeklikiwania stu podobnych ticketów.

Dla AppSec

AppSec musi przestać myśleć o AI jak o „pomocniku do czytania kodu”. Anthropic wprost wskazuje konkretne zastosowania defensywne: pierwszy triage zgłoszeń, deduplikację, pisanie repro steps, przygotowywanie wstępnych propozycji patcha, analizę misconfigów chmurowych i pomoc w review pull requestów. To w praktyce oznacza, że model może wejść w środek normalnej pracy AppSec — przy auth, JWT, API Security, secure coding review, secret handling, input validation i dependency review.

Największa zmiana? Review przestaje być wydarzeniem, a staje się ciągłym procesem. Nie czekasz już na audyt zewnętrzny, żeby ktoś zauważył, że endpoint ma broken object level authorization. Możesz odpalać takie sprawdzenia przy każdym PR, releasie i zmianie zależności.

Dla DevSecOps

Jeśli dependency bump z poprawką CVE nadal traktujesz jak „routine maintenance”, to w logice Glasswing jesteś spóźniony. Anthropic pisze wprost, że organizacje powinny skracać time-to-deploy dla security updates, zaostrzać enforcement patching window, włączać auto-update tam, gdzie to możliwe, i przyspieszać shipping poprawek.

DevSecOps w tym świecie to już nie tylko pipeline z semgrep i trivy. To również:

  • release engineering pod szybkie security hotfixy,
  • automatyczne reguły blokujące znane podatne wersje,
  • canary i rollback,
  • możliwość łagodnego wdrożenia poprawki bez dużego downtime,
  • dobre SBOM i szybkie zapytanie „gdzie siedzi ten komponent?”.

Dla PSIRT i procesu disclosure

Jeżeli model jest w stanie generować znacznie więcej trafnych znalezisk, to PSIRT może zostać zalany. Zgłoszenia trzeba deduplikować, grupować, walidować, routować, uzupełniać o repro i priorytet. I to już nie jest luksus. To warunek przetrwania. Anthropic wprost wskazuje przegląd polityk disclosure i skalowanie triage’u jako obszary, które trzeba przeprojektować.

Dla firm, które żyją na legacy

Najgorszą pozycję mają organizacje z systemami krytycznymi, wolnym release cycle i starym kodem, którego nikt nie chce dotykać. Anthropic zwraca uwagę, że właśnie dla takich systemów trzeba przygotować strategie awaryjne: co zrobić, gdy krytyczna luka wpada do aplikacji przejętej po akwizycji, już prawie nieutrzymywanej, ale nadal ważnej biznesowo? To jest bardzo konkretne pytanie. I bardzo niewygodne.

Co organizacja może zrobić już teraz, nawet bez dostępu do Glasswing

Najpraktyczniejszy fragment całego materiału Anthropic brzmi mniej więcej tak: nawet bez Mythos warto już teraz używać publicznie dostępnych modeli do defensywy. Firma twierdzi, że obecne frontier models, takie jak Opus 4.6 i modele innych dostawców, już dziś dobrze radzą sobie ze znajdowaniem luk wysokiej i krytycznej wagi w OSS-Fuzz, webappach, bibliotekach kryptograficznych i nawet w kernelu Linuksa. Według Anthropic organizacje, które jeszcze nie włączyły LLM-ów do bugfindingu, mogłyby znaleźć setki podatności, korzystając z obecnych modeli i budując sobie scaffolding pod przyszłe capability.

To jest bardzo trzeźwa rada. Nie chodzi o to, żeby czekać na magiczny model. Trzeba już teraz zbudować proces, w którym model pomaga, a człowiek waliduje.

Minimalny sensowny workflow

Najprostsza wersja wygląda tak:

  1. Źródło sygnału
    PR diff, wynik SAST/DAST/SCA, raport z bug bounty, wynik fuzzingu, misconfig w chmurze, nowe CVE w zależnościach.
  2. Automatyczny triage
    Model ocenia, czy zgłoszenie jest logiczne, co trzeba sprawdzić, czy są przesłanki do duplikatu, jakie są prawdopodobne warunki exploita.
  3. Walidacja przez człowieka
    Security engineer albo pentester potwierdza exploitability, wpływ i priorytet.
  4. Patch proposal
    Model przygotowuje szkic poprawki albo wskazuje miejsce, gdzie zmiana jest najbezpieczniejsza.
  5. Test i release
    Automatyczne testy regresyjne, release, telemetryczne potwierdzenie, że exposure spadł.
  6. Detection engineering
    Reguły do logów, WAF/EDR/SIEM, hunting pod exploitation attempts.

To nie jest science fiction. To jest bardzo sensowny pipeline na 2026 rok.

Praktyczny scenariusz: jak wygląda AI-assisted security workflow w realnym zespole

Poniższe przykłady nie pochodzą z Mythos. To są realistyczne wzorce wdrożenia, które możesz odpalić dziś na stagingu i w swoim SDLC.

Scenariusz 1: review pull requesta pod kątem JWT i API Security

Masz endpoint z fakturami. Ktoś zrobił szybki feature i zostawił dwa klasyczne grzechy: używa jwt.decode() zamiast pełnej weryfikacji podpisu i nie sprawdza ownership obiektu.

// zły przykład
app.get("/api/invoices/:id", async (req, res) => {
  const token = req.headers.authorization?.replace("Bearer ", "");
  const claims = jwt.decode(token); // tylko decode, brak verify  const invoice = await db.invoice.findUnique({
    where: { id: req.params.id }
  });  return res.json({
    requestedBy: claims?.sub,
    invoice
  });
});

To jest mieszanka problemów z obszaru JWT, OWASP API Security i klasycznego BOLA/IDOR. SAST może coś zauważyć, ale model z sensownym kontekstem często złapie to szybciej jako problem logiczny: „brak walidacji podpisu” plus „brak związku między sub a ownerId obiektu”.

Poprawiona wersja powinna iść mniej więcej tak:

const jwt = require("jsonwebtoken");function authRequired(req, res, next) {
  try {
    const auth = req.headers.authorization ?? "";
    const [, token] = auth.split(" ");    req.user = jwt.verify(token, process.env.JWT_PUBLIC_KEY, {
      algorithms: ["RS256"],
      issuer: "https://auth.example.com",
      audience: "api://billing"
    });    next();
  } catch {
    return res.status(401).json({ error: "unauthorized" });
  }
}app.get("/api/invoices/:id", authRequired, async (req, res) => {
  const invoice = await db.invoice.findFirst({
    where: {
      id: req.params.id,
      ownerId: req.user.sub
    }
  });  if (!invoice) {
    return res.status(404).json({ error: "not_found" });
  }  return res.json(invoice);
});

A potem bardzo prosty test ręczny:

curl -i \
  -H "Authorization: Bearer $TOKEN_USER_A" \
  https://api.example.com/api/invoices/INV-1002

Jeżeli INV-1002 należy do usera B, poprawna odpowiedź to 404 albo 403, a nie 200.
I właśnie tu widać różnicę między AI a człowiekiem: model może bardzo dobrze wskazać „tu masz błąd authz”, ale to człowiek lepiej osadzi wpływ w kontekście biznesowym. Czy to wyciek PII? Czy można zmienić status faktury? Czy da się po tym zrobić fraud? To nadal wymaga operatora.

Scenariusz 2: triage podatnej zależności i skracanie patch cycle

Gdy wpada CVE, nie potrzebujesz od razu „autonomicznego hakera”. Najpierw potrzebujesz odpowiedzi na banalne pytania:

  • gdzie mamy ten komponent,
  • w jakiej wersji,
  • czy jest reachable,
  • czy fix istnieje,
  • co blokuje rollout.

Pierwszy krok można zautomatyzować zwykłymi narzędziami:

syft dir:. -o cyclonedx-json > sbom.json
grype sbom:sbom.json --only-fixed -o json > grype.jsonjq -r '
  .matches[]
  | select(.vulnerability.severity == "High" or .vulnerability.severity == "Critical")
  | [.artifact.name, .artifact.version, .vulnerability.id, .vulnerability.fix.state]
  | @tsv
' grype.json

Na tym etapie model może zrobić trzy użyteczne rzeczy:

  • pogrupować wyniki po serwisach i ownerach,
  • wyciągnąć, które zależności są internet-facing,
  • przygotować roboczą notatkę typu: „to wygląda jak pilny hotfix, nie backlog”.

To idealnie wpisuje się w rekomendację Anthropic, żeby skracać patch cycles i traktować dependency bumps z CVE fixami jako pilne, a nie jako housekeeping.

Scenariusz 3: first-pass triage z bug bounty albo VDP

Dostajesz zgłoszenie z programu VDP:

„Endpoint /v1/export pozwala pobrać dane innego tenant’a po manipulacji tenant_id w body.”

Zanim człowiek poświęci na to godzinę, model może:

  • porównać zgłoszenie z podobnymi ticketami,
  • napisać checklistę walidacji,
  • przygotować zestaw komend curl,
  • zasugerować, jakie logi sprawdzić,
  • ocenić, czy mamy tu BOLA, mass assignment czy problem w boundary enforcement.

Przykładowy test:

curl -s -X POST https://api.example.com/v1/export \
  -H "Authorization: Bearer $TOKEN_TENANT_A" \
  -H "Content-Type: application/json" \
  -d '{"tenant_id":"tenant-b","format":"csv"}'

Jeżeli odpowiedź zwróci dane tenant B, to mamy klasyczny problem w autoryzacji poziomu obiektu lub tenant boundary.

Przykładowy log, który warto umieć wykryć:

ts=2026-04-08T10:14:11Z req_id=4f2a1a src=198.51.100.24
sub=tenant-a:user-1001 action=export tenant_requested=tenant-b
decision=ALLOW status=200 bytes=184421

To jest świetny przykład, dlaczego AI i człowiek muszą pracować razem. Model szybko zauważy niespójność. Ale to człowiek zdecyduje, czy to jest krytyczny cross-tenant data exposure, czy może tylko martwy parametr bez faktycznego wpływu.

Scenariusz 4: automatyzacja IR po disclosure

Załóżmy, że vendor publikuje advisory. W klasycznym świecie:

  • ktoś czyta CVE,
  • ktoś inny sprawdza exposure,
  • ktoś inny robi hunting,
  • ktoś inny pisze update do managementu.

To bardzo wolne.

W świecie po Glasswing warto zbudować pipeline, w którym model:

  • streszcza advisory,
  • mapuje je do serwisów i assetów,
  • proponuje wskaźniki exploita,
  • generuje pierwszą wersję notatki do incident bridge,
  • przygotowuje checklistę weryfikacji po wdrożeniu poprawki.

Przykładowy zapis z telemetrii:

2026-04-08T10:41:12Z waf event=block signature=rpc_overflow
src=185.203.119.44 uri=/rpc auth=none2026-04-08T10:41:13Z edr host=fs-07 process=/usr/sbin/nfsd
alert=stack_corruption_attempt severity=high2026-04-08T10:41:15Z ir note="Activity spike started <3h after vendor advisory"

Anthropic wprost sugeruje, że modele powinny wykonywać znaczną część technicznej pracy IR: triage alertów, streszczanie zdarzeń, priorytetyzację dla człowieka, proaktywne huntingi, zbieranie artefaktów i szkic RCA/postmortem. To nie jest już „fajnie byłoby mieć”. To jest bardzo rozsądna architektura operacyjna.

Ryzyka, ograniczenia i rzeczy, o których hype zwykle milczy

False positives nadal kosztują

Stanford mówi to wprost: AI miało przewagi, ale też wyższy poziom false positives i problemy z GUI. To oznacza, że sama liczba znalezisk nie jest metryką sukcesu. Bez dobrego walidatora organizacja może zwyczajnie utonąć w błędach, które wyglądają groźnie, ale nie prowadzą do exploita albo nie mają realnego wpływu.

To ważna przestroga również dla zespołów zachwyconych „AI do AppSec”. Jeśli wrzucisz model w pipeline bez ograniczeń, możesz dostać więcej pracy, a nie więcej bezpieczeństwa.

Responsible disclosure stanie się trudniejsze, nie łatwiejsze

Skoro Anthropic utrzymuje, że ponad 99% znalezionych luk nie było jeszcze załatanych, to skala disclosure robi się sama w sobie problemem operacyjnym. Kto powiadamia? Kto deduplikuje? Kto nadaje priorytet? Kto ściga maintainerów? Kto koordynuje terminy, gdy jedna biblioteka jest zależnością dla połowy ekosystemu? Glasswing bardzo mocno sugeruje, że disclosure przestaje być procesem dla małego PSIRT-u, a staje się elementem odporności całego łańcucha dostaw software’u.

Najwolniejsze organizacje zapłacą najwyższą cenę

Jeśli twój proces łatania wygląda tak:

  • CAB raz w tygodniu,
  • testy regresyjne blokują wszystko,
  • rollout tylko w weekend,
  • dependency bumps lądują w backlogu na „kiedyś”,

to Glasswing jest złą wiadomością. Nie dlatego, że Anthropic cię zaatakuje. Dlatego, że cały rynek capability przesuwa się w stronę szybszego exploit developmentu. A wtedy najwolniejsi obrońcy przestają być „trochę mniej dojrzali”. Stają się najbardziej opłacalnym celem.

Bezpieczeństwo modeli nie zamyka problemu. Ono tylko kupuje czas

Fakt, że Mythos jest invite-only, jest istotny. Ale to nie jest rozwiązanie na stałe. To raczej okno, w którym branża ma nadrobić zaległości w patchingu, triage’u, disclosure i secure-by-design. Anthropic samo pisze, że Glasswing ma pomóc defenderom zabezpieczyć ważne systemy zanim podobne capability staną się szerzej dostępne.

To znaczy, że najgorszą możliwą strategią jest siedzieć i czekać, aż „rynek się wyklaruje”.

Czy warto wdrażać AI do security już teraz, skoro modele nadal halucynują?

Tak, ale w układzie „model pomaga, człowiek zatwierdza”. Stanford pokazał, że agenci dają realną przewagę w enumeracji, równoległości i koszcie, ale wymagają walidacji. To argument za wdrożeniem kontrolowanym, a nie za odpuszczeniem tematu.

Krótka checklista techniczna po lekturze

  • policz medianę i p95 czasu od publikacji CVE do wdrożenia poprawki w krytycznych usługach,
  • sprawdź, czy masz SBOM dla systemów internet-facing,
  • uruchom AI-assisted review dla jednego repo z krytycznym auth/API,
  • przejrzyj kod pod wzorce typu jwt.decode, verify=False, skip_signature, auth=false,
  • włącz automatyczny triage wyników SAST/SCA/bug bounty,
  • przygotuj skrócony playbook dla „N-day weaponized quickly”,
  • sprawdź, czy dependency bumps z CVE fixami mają osobny priorytet,
  • dopisz hunting pod ruch i błędy pojawiające się kilka godzin po advisory,
  • odśwież politykę disclosure i ścieżkę eskalacji dla legacy,
  • zrób jeden test na stagingu: model + człowiek + patch + detekcja + rollback.

Największy paradoks tej zmiany: zachwycamy się AI, a firmy nadal przegrywają przez phishing

W całej dyskusji o Glasswing, frontier models i coraz krótszym czasie od ujawnienia słabości do gotowego exploita łatwo wpaść w jedną pułapkę: zacząć patrzeć na cyberbezpieczeństwo wyłącznie przez pryzmat najbardziej zaawansowanych scenariuszy. To zrozumiałe. Technicznie jest to fascynujące. Model, który potrafi analizować kod, odtwarzać N-daye, budować exploit chainy i przyspieszać vulnerability research, robi wrażenie. Problem polega na tym, że dla ogromnej liczby organizacji to nadal nie jest główna przyczyna kompromitacji. W praktyce wiele firm nie przegrywa dlatego, że ktoś zainwestował tygodnie w budowę złożonego łańcucha exploita. Przegrywa dlatego, że pracownik kliknął w link do fałszywego panelu Microsoft 365, zaakceptował podejrzane powiadomienie MFA, otworzył złośliwy załącznik, zaufał wiadomości podszywającej się pod przełożonego albo dał się wciągnąć w rozmowę, która wyglądała jak zwykły kontakt z helpdeskiem, dostawcą lub działem finansów.

To jest właśnie najbardziej niewygodny paradoks nowoczesnego security. Z jednej strony obserwujemy rosnące możliwości AI w obszarze wykrywania i eksploatacji podatności. Z drugiej strony atakujący wcale nie muszą zaczynać od najbardziej zaawansowanej drogi wejścia. W większości przypadków wybierają tę najtańszą, najszybszą i najbardziej powtarzalną. Jeżeli mogą zdobyć dostęp do konta przez phishing, przejąć sesję przez wykradzenie tokenu, wymusić zatwierdzenie logowania metodą MFA fatigue, zmanipulować pracownika finance lub HR albo uruchomić złośliwy kod przez pozornie niewinną wiadomość, to nie potrzebują od razu 0-daya ani subtelnego browser exploit chaina. I to jest myśl, która powinna wybrzmieć bardzo mocno: atakujący nie wybiera najbardziej eleganckiej ścieżki. Wybiera najtańszą ścieżkę do skutku.

W realnym środowisku firmowym kompromitacja bardzo często wygląda dużo mniej „filmowo” niż w raportach o zaawansowanych exploitach. Zaczyna się od prostego maila, wiadomości na komunikatorze, linku do współdzielonego dokumentu, fałszywej faktury, podszycia się pod rekrutera, dostawcę, bank, dział IT albo klienta. Potem wchodzi klasyczny etap kradzieży tożsamości: login, hasło, cookie sesyjne, token dostępu, zatwierdzenie MFA, czasem przejęcie skrzynki pocztowej w chmurze. Dalej napastnik bardzo często nie musi już „hakować” w klasycznym sensie tego słowa. Wystarczy, że wykorzysta zaufanie wewnątrz organizacji. Wyśle wiadomość z legalnego przejętego konta. Poprosi o zmianę numeru rachunku. Rozpocznie rozmowę z helpdeskiem. Wygeneruje reset dostępu. Otworzy drogę do kolejnych systemów dzięki temu, że tożsamość użytkownika jest w wielu miejscach traktowana jako wystarczający dowód zaufania. Dopiero później może pojawić się malware, loader, zdalne narzędzie administracyjne, kradzież danych albo ransomware. W wielu przypadkach prawdziwa „eksploatacja” zaczyna się więc nie od błędu w pamięci czy parserze, ale od błędu w zaufaniu.

Dlatego patrząc na Glasswing, nie wolno zgubić proporcji. Tak, ten projekt jest ważny, bo pokazuje, że cyber capability modeli rosną szybciej, niż większość organizacji przebudowuje swoje procesy AppSec, PSIRT, triage i patch management. Ale to nie unieważnia starej, niewygodnej prawdy: ogromna część organizacji nadal nie domknęła podstaw związanych z tożsamością, pocztą, endpointami i zachowaniami użytkowników. Jeżeli firma nie ma dobrze ustawionego MFA odpornego na phishing, nie blokuje starszych metod uwierzytelniania, nie kontroluje ryzykownych logowań, nie chroni sesji, nie egzekwuje zasad dla urządzeń końcowych, nie ogranicza uruchamiania nieautoryzowanych binarek i skryptów, nie umie szybko izolować hosta po podejrzanym kliknięciu i nie ma sensownego procesu zgłaszania podejrzanych wiadomości — to problemem nie będzie to, że za dwa lata AI przyspieszy exploit development. Problemem będzie to, że firma już dziś zostawia atakującym znacznie prostsze wejście.

To również bardzo ważna lekcja dla blue teamu i liderów bezpieczeństwa. Łatwo jest dać się porwać najbardziej zaawansowanym scenariuszom, bo są intelektualnie atrakcyjne i dobrze wyglądają w prezentacjach. Trudniej konsekwentnie inwestować w to, co mniej widowiskowe: bezpieczeństwo poczty, ochronę tożsamości, kontrolę nad sesjami, segmentację, ograniczenie uprawnień, bezpieczne workflow zatwierdzania zmian finansowych, procedury dla helpdesku, realne ćwiczenia z phishingu, sensowną telemetrię z endpointów, blokowanie makr i nieautoryzowanych narzędzi, szybkie odtwarzanie po incydencie i backupy odporne na sabotaż. A przecież to właśnie te elementy bardzo często decydują, czy phishing skończy się na jednym zgłoszeniu do SOC, czy na pełnym incydencie z szyfrowaniem zasobów i wyciekiem danych.

Warto też powiedzieć to wprost: rozwój AI może paradoksalnie jeszcze bardziej wzmocnić problem socjotechniki, a nie tylko problem exploitów. Ten sam postęp modeli, który przyspiesza analizę kodu i weaponizację podatności, może również poprawiać jakość phishingu, pretextingu i podszywania się pod wiarygodnych nadawców. Lepszy język, lepsze dopasowanie do kontekstu, większa personalizacja, automatyczne budowanie wiarygodnych wiadomości, fałszywych portali, fałszywych konwersacji i materiałów audio-wideo — to wszystko oznacza, że granica między „prymitywnym phishingiem” a dobrze przygotowaną operacją oszustwa będzie się zacierała. Innymi słowy: AI nie tylko skraca czas od luki do exploita. AI może też skracać czas od zebrania danych o ofierze do przygotowania bardzo przekonującej manipulacji.

I właśnie dlatego najdojrzalsza interpretacja Glasswing nie brzmi: „teraz wszystko będzie o 0-dayach”. Lepsza interpretacja brzmi: przyszłość przyspiesza na dwóch frontach jednocześnie. Pierwszy front to techniczne wykrywanie i eksploatacja podatności. Drugi front to industrializacja manipulacji, podszywania się i przejmowania tożsamości. Jeżeli firma skupi się wyłącznie na pierwszym, a zignoruje drugi, to może skończyć w absurdalnej sytuacji: będzie śledzić dyskusje o autonomicznych exploitach i AI-assisted vulnerability research, a jednocześnie wpuści ransomware do środka przez przejętą skrzynkę, zatwierdzone MFA albo fałszywą wiadomość od „dyrektora finansowego”.

Na poziomie strategicznym oznacza to jedną rzecz: organizacja nie może budować programu bezpieczeństwa tak, jakby wszystkie zagrożenia dojrzewały w tym samym tempie i wymagały tych samych inwestycji. Glasswing jest sygnałem dla AppSec, DevSecOps, PSIRT i product security. Phishing, kradzież tożsamości i socjotechnika pozostają natomiast sygnałem alarmowym dla IAM, email security, SOC, endpoint protection, security awareness i procesów biznesowych. Jedno nie zastępuje drugiego. Jedno nie czyni drugiego mniej pilnym. Wręcz przeciwnie — dopiero razem pokazują pełny obraz: zaawansowane capability AI będą zmieniały przyszłość ofensywy i defensywy, ale większość firm nadal może zostać złamana dużo prostszą metodą, jeśli nie uszczelni podstaw.

Najkrócej można to ująć tak: Glasswing pokazuje, jak może wyglądać jutro. Phishing i socjotechnika przypominają, że wiele organizacji nadal nie poradziło sobie z dniem dzisiejszym. I właśnie dlatego rozsądny program bezpieczeństwa musi patrzeć jednocześnie w obie strony — na frontier threats, które nadchodzą szybciej niż dawniej, i na stare, nudne, brutalnie skuteczne metody, które wciąż dają napastnikom najtańszy dostęp do środka.

Podsumowanie

Project Glasswing nie jest najważniejszy dlatego, że Anthropic ogłosiło kolejny model. Jest ważny dlatego, że pokazuje nowy rozkład sił w bezpieczeństwie oprogramowania.

Do tej pory można było mówić: „mamy za mało ludzi, żeby znaleźć wszystkie błędy”.

Coraz częściej prawdziwsze będzie: „mamy za mało dobrze poukładanych procesów, żeby obsłużyć to, co znajdą modele”.

To jest zasadnicza różnica.

Jeżeli prowadzisz AppSec, blue team albo produkt z dużą powierzchnią ataku, to Glasswing powinieneś czytać nie jak news o Anthropic, tylko jak ostrzeżenie operacyjne. Discovery przyspiesza. Weaponization przyspiesza. Patching musi przyspieszyć. Triage musi się zautomatyzować. Disclosure musi się skalować. IR musi umieć pracować z większym wolumenem i krótszym oknem reakcji.

Najbardziej praktyczny wniosek jest prosty: nie czekaj na „idealne AI do security”. Weź jeden krytyczny proces — review PR-ów, triage zgłoszeń, dependency patching albo hunting po advisory — i zrób z niego workflow, w którym model pomaga, a człowiek zatwierdza. To właśnie tam firmy wygrają albo przegrają erę po Glasswing.

Dziś jeszcze sprawdź trzy rzeczy: ile naprawdę trwa u ciebie wdrożenie poprawki po krytycznym CVE, czy potrafisz w minutach wskazać wszystkie usługi z podatną zależnością, i czy masz w logach widoczność na próby exploitacji w pierwszych 24–72 godzinach po disclosure. Jeśli na któreś z tych pytań odpowiedź brzmi „nie do końca”, to właśnie tam zaczyna się twoja praca jeszcze dużo przed Glasswing.

Bibliografia