2 436 błędów, jeden zgłaszający: przebuduj przyjmowanie zgłoszeń w VDP

Masowa kampania ujawniania podatności to jeden zgłaszający, który naraz wysyła wiele znalezisk do wielu niepowiązanych ze sobą stron. Terminy ustala sam. Publiczny Security Disclosure Ledger firmy Z.ai notuje 2 436 znalezisk w 269 projektach open source, w tym 107 krytycznych i 990 wysokich, przy średnio 26,6 roku między wprowadzeniem błędu a jego wykryciem; niezależny audyt pola statusu w tym rejestrze wykazał, że 2 239 znalezisk nadal ma status discovered, a dokładnie jedno sent to maintainer. Jedno potwierdzenie, jeden zegar SLA, jedna decyzja o poziomie ważności: przyjmowanie zgłoszeń pojedynczo rozpada się w zderzeniu z takim kształtem.

To trzeci tekst z serii, a całe sedno tkwi w różnicy: te znaleziska są w większości prawdziwe i nikt ich nie zamawiał. Tekst o śmieciach AI dotyczył nieprawidłowych zgłoszeń napływających masowo. Tekst o modelu kosztów VDP mówił o tym, że koszt znalezienia prawdziwego błędu spadł z grubsza do ceny obiadu. Tu nie chodzi ani o jedno, ani o drugie.

Tekst o wielu dostawcach opisywał jeden błąd, który spada na pięciu dostawców; tutaj jeden zgłaszający uderza naraz w 269 projektów. Ten sam problem zarządczy, wywrócony na lewą stronę, tyle że termin trzyma strona, która akurat ma premierę produktu.

2 436 znalezisk, 269 projektów i jeden zgłaszający

14 sierpnia 2026 roku Z.ai wypuściło GLM-5.3 i tego samego dnia opublikowało pod adresem cvd.z.ai swój Security Disclosure Ledger. Artefaktem wartym lektury jest tu rejestr, nie wynik benchmarku.

Wśród ujawnionych z nazwy znalezisk są: stos 6lowpan w jądrze Linuksa, WebKit, ptrace z FreeBSD, GStreamer i Suricata. Z.ai podaje, że GLM-5.3 osiąga 84,5% w CyberGym wobec 77,2% dla GLM-5.2. Wątek na Hacker News urósł do 1 170 punktów i 584 komentarzy, a najostrzejsza krytyka celowała nie w model, tylko w masowe skanowanie open source bez jakiejkolwiek polityki embarga. Zanim cokolwiek zbudujesz na tych liczbach, dwa zastrzeżenia.

To nie jest praca jednego modelu. Z.ai twierdzi, że kampania ruszyła jeszcze w czasach GLM-5.2, prowadziło ją kilka zespołów bezpieczeństwa korzystających z różnych zestawów narzędzi, a biuletyny bezpieczeństwa po stronie projektów wymieniają rozmaite wersje GLM. Pisz „kampania Z.ai”, nigdy „GLM-5.3 znalazł 2 436 błędów”.

Każda zbiorcza liczba pochodzi z publikacji samego Z.ai. Nikt spoza firmy nie zweryfikuje 2 383 nieujawnionych wpisów. To nie przytyk pod adresem Z.ai, tylko opis pozycji, w jakiej sam się znajdziesz, kiedy do twojej skrzynki wpadnie partia czterdziestu zgłoszeń: przyjmując zgłoszenie, nie sprawdzisz twierdzeń masowego zgłaszającego, a ja nie sprawdzę tych tutaj.

Ani historia o śmieciach AI, ani o tanim wykrywaniu błędów

Przy śmieciach AI problemem był stosunek sygnału do szumu, przy ekonomice triażu chodziło o koszt jednostkowy. Tutaj chodzi o kształt, a to właśnie kształt rozbija narzędzia. Zwykły program ujawniania podatności (VDP) zakłada relację wiele-do-jednego: wielu niezależnych badaczy, każdy wysyła jedno zgłoszenie i każdy, składając je, godzi się na twoją politykę. Kampania masowa odwraca ten układ. Jeden zgłaszający zwraca się naraz do 269 odbiorców, według harmonogramu, który sam ustala, i publikuje jawny rejestr, zanim większość z nich w ogóle się o czymkolwiek dowie.

Strona odbierająca niczego nie akceptowała, na żaden harmonogram się nie umawiała, a w większości przypadków nikt jej nawet nie powiadomił. To nie jest zgłoszenie do programu bug bounty. Bliżej temu do masowej kampanii powiadomień o podatnościach, którą badania nad bezpieczeństwem opisują od dekady i o której wiadomo jedno: odsetek odpowiedzi jest żałośnie niski.

Wąskim gardłem jest powiadomienie, nie łatanie

Najcenniejsza informacja w rejestrze to nie liczba 2 436, tylko to, gdzie te znaleziska utknęły. Audyt pola statusu, wykonany 14 sierpnia, zanotował: 2 239 discovered, 84 reported, 53 revealed, 29 acknowledged, 30 patched i 1 sent to maintainer. Blisko 92% znalezisk nadal leży po stronie zgłaszającego.

Anthropic rozegrał to samo dwa miesiące wcześniej i doczekał się audytu. Analiza rejestru Mythos, którą VulnCheck opublikował 9 czerwca 2026 roku, wykazała 23 019 kandydatów na podatności, z czego 467 zweryfikowano i zgłoszono, a 1 129 zgłoszono bez weryfikacji. Do opiekunów projektów dotarło więc w 60 dni 1 596 znalezisk, czyli 6,9%, w tempie, przy którym rozładowanie zaległości zajęłoby według VulnCheck jakieś 2,4 roku.

Do tego dziesięć znalezisk przekroczyło już 90-dniowy termin wyznaczony przez samo Anthropic i wciąż nie zostało opublikowanych, a kolejnych 168 ma termin w ciągu 30 dni.

Dwóch dostawców, dwa rejestry, jeden strukturalny wniosek: wykrywanie skaluje się, powiadamianie nie. Model znajdzie przepełnienie sterty w kodzie z 1994 roku w kilka minut. Odnalezienie opiekuna, napisanie zgłoszenia, na które człowiek umie zareagować, i doprowadzenie sprawy do łatki to wciąż ta sama ludzka robota co zawsze.

Dla strony odbierającej to dobra wiadomość z terminem ważności. Fala jeszcze cię nie zalała, a kiedy nadejdzie, przyjdzie partią, bo zgłaszający nie zgłasza pojedynczego błędu, tylko rozładowuje kolejkę.

Co się psuje, gdy od jednego nadawcy przychodzi 40 zgłoszeń

Trzy awarie czysto mechaniczne, żadna nie wymaga oceny sytuacji. We wszystkich trzech twoja automatyka działa dokładnie tak, jak ją zaprojektowano.

Lawina potwierdzeń. Automatyczna odpowiedź na każde zgłoszenie jest poprawna przy jednym i staje się nękaniem przy czterdziestu. Nadawca dostaje czterdzieści maili, których nikt nie chciał, twoja domena wysyła czterdzieści niemal identycznych wiadomości pod jeden adres, a po tym wszystkim nadawca i tak nie wie, kto odpowiada za partię ani kiedy spojrzy na nią człowiek.

Sumowanie SLA. Czterdzieści zegarów potwierdzenia rusza równocześnie. Każdy z osobna da się obsłużyć w 72 godziny, razem dają obciążenie triażem, pod które nikt nie układał grafiku dyżurów. W rozbiciu na pojedyncze zgłoszenia kolejka świeci na zielono, jako całość jest beznadziejna. Dokładnie ten tryb awarii opisywał tekst o wielu dostawcach, tylko odwrócony: tam jedna sprawa miała wiele zegarów, tu wiele spraw dzieli jeden pułap mocy przerobowych.

Poziom ważności przed przyczyną źródłową. Triaż zgłoszenie po zgłoszeniu pyta najpierw „jak groźne jest to jedno?”. Przy kampanii to pytanie drugie; pierwsze brzmi: czy metoda tego zgłaszającego się broni i czy te znaleziska mają wspólną przyczynę źródłową?

Czterdzieści znalezisk z jednego zestawu narzędzi wycelowanego w jeden parser to bardzo często jedna klasa błędu w czterdziestu miejscach w kodzie. Triażowanie ich osobno kosztuje czterdzieści razy więcej i daje gorszą odpowiedź, bo wzorzec widać wyłącznie w całości.

Wszystkie trzy awarie biorą się z jednej decyzji projektowej: jednostką pracy jest zgłoszenie. Przy kampanii już nią nie jest.

Kampania to nie zgłoszenie: co musi obejmować przyjmowanie zgłoszeń

Lekarstwem jest obiekt partii stojący ponad zgłoszeniem. Pięć pól robi tu większość roboty.

1. Jedna partia, jedno potwierdzenie. Jedna odpowiedź, która nazywa partię, podaje liczbę znalezisk i zobowiązuje do daty pierwszej merytorycznej odpowiedzi. Kiedy w zgłoszeniu jest identyfikator partii, wyłącz pojedyncze maile.
2. Jeden właściciel. Konkretna osoba odpowiedzialna za partię, a nie czterdzieści przypisań rozdzielanych po kolei między dyżurnych.
3. Jeden wspólny zegar dla partii, a pod spodem zegary poszczególnych znalezisk. Potwierdzenie jest zobowiązaniem wobec całej partii, naprawa dotyczy pojedynczego znaleziska.
4. Ocena metody zapisana raz. Czy zestaw narzędzi się broni? Czy dołączone PoC dają się uruchomić? Odpowiadasz dla całej partii, dziedziczysz odpowiedź w dół i korygujesz tylko tam, gdzie konkretne znalezisko jej przeczy.
5. Grupowanie po przyczynie źródłowej przed oceną ważności. Najpierw klastry, potem punktacja klastrów, a nie pojedynczych wierszy.

Kit jeszcze tego nie ma. Moduł Csirt:: traktuje Csirt::Report jako rekord najwyższego poziomu: żadnego obiektu kampanii, żadnej partii zgłoszeń. Czterdzieści zgłoszeń to czterdzieści wierszy, czterdzieści maili z potwierdzeniem, czterdzieści zegarów SLA i czterdzieści powiadomień na dyżur.

To główna teza tego tekstu i zarazem luka w naszym własnym produkcie, a nie jego funkcja. Pięć pól powyżej to kształt, jaki naszym zdaniem powinien mieć taki obiekt.

Czyj jest zegar ujawnienia, kiedy zgłasza dostawca modelu?

Niczyj, dopóki go sobie nie zapiszesz.

Żadne prawo nie ustala skoordynowanego ujawnienia na 90 dni. Jest konwencja, choćby 90+30 z Project Zero i 90+14 z ZDI dla współpracujących dostawców, a poza tym liczy się to, kto opublikuje pierwszy. Kiedy zgłaszającym jest dostawca modelu, termin splata się z marketingiem premiery, bo rejestr jest w równym stopniu pokazem możliwości, co artefaktem ujawnienia.

Z.ai nie opublikowało przy rejestrze żadnej polityki embarga: ani strony z zasadami, ani terminu przy pojedynczym znalezisku, ani odliczania. Tylko status, poziom ważności i identyfikatory. To i tak przejrzystsze niż ciche skanowanie, a mimo to zostajesz bez żadnej daty.

Anthropic 90-dniowy termin ogłosił, a VulnCheck znalazł dziesięć znalezisk, które go przekroczyły i nadal nie zostały opublikowane. Wybór nie jest więc między dostawcą z polityką a dostawcą bez niej, tylko między datą w twoim rejestrze a datą w cudzym kalendarzu publikacji.

Tę lukę zamykają trzy pola: requested_embargo_at (o co poprosił zgłaszający), agreed_embargo_at (co wynegocjowaliście) i published_at (co się faktycznie stało). Kit ich nie ma i mówi to wprost na własnej stronie porównania: „Kit nie modeluje żadnych terminów ujawnienia ani dat embarga. Pole z datą embarga to uczciwa prośba; dziś Kit śledzi potwierdzenie odbioru, a nie ujawnienie.” Jedyna 90-dniowa stała w kodzie to wygaśnięcie tokenu potwierdzającego odbiór, a nie zegar ujawnienia.

Limity to zła obrona: co naprawdę dał limit Apple’a

Pierwszym odruchem po lekturze tego wszystkiego jest nałożenie na nadawcę limitu. Apple przeprowadziło ten eksperyment publicznie, a wynik jest ciekawszy niż nagłówek. W czerwcu 2026 roku firma dołożyła w swoim portalu dla badaczy limit zgłoszeń i 30-dniową karencję, a zgłoszenia ponad limit wymagają osobnej prośby. Wysokości limitu nie podano.

Bynario, który przez cały 2025 rok i początek 2026 złożył 13 zgłoszeń, zbudował własne narzędzia oparte na AI i w trzy tygodnie złożył ponad 50 zgłoszeń dotyczących macOS. Przebił limit i został odcięty od portalu dokładnie w chwili, gdy miał w ręku krytyczne znalezisko.

Limit nie zatrzymał znaleziska i właśnie to zwykle się pomija. Apple dostało szczegóły inną drogą i 27 lipca załatało CVE-2026-43760, błąd typu confused deputy w starej ścieżce VNC, który pozwalał uwierzytelnionemu klientowi VNC czytać i tworzyć pliki jako root. Bynario opublikował analizę dwa dni później, już po wydaniu łatki: to normalna publikacja badawcza po załataniu, a nie sfrustrowane wyrzucenie zero-daya do sieci.

Potem przyszło to, na co limit nie miał żadnego wpływu. Opis Bynario skierował uwagę badaczy na starą ścieżkę kodu Screen Sharing. W ciągu 48 godzin ujawniono w tym samym demonie osobny błąd typu pre-auth, czyli możliwy do wykorzystania bez uwierzytelnienia, razem z proof of concept. Cztery dni później powstał działający exploit, a potem ruszyły realne ataki: kopanie kryptowalut na wystawionym do internetu porcie 5900.

Apple wydało awaryjną łatkę 6 sierpnia. CISA 14 sierpnia podniosła ocenę z 7,1 do 9,8, a 18 sierpnia dopisała podatność do katalogu Known Exploited Vulnerabilities, a urzędom federalnym wyznaczyła termin naprawy na 21 sierpnia 2026 roku.

Dziesięć dni od błędu podniesienia uprawnień, który wymagał uwierzytelnienia, do zdalnego wykonania kodu bez uwierzytelnienia w tym samym komponencie, z wpisem w KEV włącznie.

Morał nie brzmi „limity rodzą zero-daye”; to nadinterpretacja materiału. Jest węższy i bardziej użyteczny: limit zgłoszeń decyduje o tym, jak szybko zgłoszenia trafiają do twojej kolejki, i o niczym więcej, a na pewno nie o tym, jak szybko dowiaduje się świat. Na tej osi czasu kontrolujesz realnie jedno: własne moce przerobowe w przyjmowaniu zgłoszeń. Limit nie dołożył ich ani grama.

Lepsza odpowiedź GitHuba: cztery zgłoszenia i wyjście z limitu

GitHub uderzył w tę samą ścianę i zamiast dławienia wybrał podział na poziomy. Dla zgłoszeń złożonych 27 lipca 2026 roku i później prowadzi publiczny poziom ze stałymi stawkami 250 $ / 2 000 $ / 5 000 $ / 10 000 $ od niskich po krytyczne oraz poziom VIP wyłącznie na zaproszenie: 1 000 $ / 7 500 $ / 20 000 $ / 30 000 $ i więcej. Najciekawsze jest to, jak się tam wchodzi: badacz poniżej progu reputacji platformy dostaje do czterech zgłoszeń na start, żeby się pokazać, a drzwi do VIP otwiera jedno prawidłowe krytyczne zgłoszenie, dwa wysokie, cztery średnie albo siedem niskich.

To limit, z którego jest wyjście. Narzędzia Bynario spaliłyby cztery zgłoszenia, a potem na dowolnym z krytycznych błędów, które i tak zgłoszono później, otworzyłyby sobie szybką ścieżkę. Limit Apple’a nie ma żadnych drzwi: liczy zgłoszenia, przestaje liczyć, a jedyne przejście dalej prowadzi przez kalendarz.

Nazwijmy tę różnicę projektową wprost: ograniczenie przepustowości da się obronić tylko wtedy, gdy o jego zniesieniu przesądza to, czy masz rację, a nie odczekanie 30 dni. Podsumowanie GitHuba jest zdaniem wartym skopiowania: „nie zarabiasz więcej, zgłaszając więcej. Zarabiasz więcej, zgłaszając lepiej.”

Kit wdrożył połowę tego pomysłu, tę o zaufaniu, i musi naprawić drugą, tę o limitach. Csirt::Researcher#karma_tier dzieli badaczy według zgromadzonej karmy i przy 200 punktach nadaje status trusted, a zasilają ją wartości Csirt::KarmaEvent ze znakiem: report_validated +5, bounty_awarded +10, po drugiej stronie spam_dismissed -10, ai_slop_confirmed -15, policy_violation -25. Karma jest z założenia liczona osobno dla każdego konta, więc ocena wystawiona w jednym programie nie ciągnie się za badaczem po całym internecie.

Domyślne ustawienia Kit i tak odcięłyby kogoś takiego jak Bynario. SpamConfig blokuje po 5 zgłoszeniach w 300 sekund, a limiter zapytań ogranicza zgłoszenia CSIRT do 10 na godzinę z jednego IP. Zgłaszający z czterdziestoma zweryfikowanymi znaleziskami przekracza oba progi.

To ten sam tryb awarii co u Apple’a, tyle że w naszych własnych domyślnych ustawieniach, a lekarstwem nie jest większa liczba. Trzeba liczyć partie zamiast żądań i pozwolić, żeby karma_tier podnosił pułap temu, kto sobie na to zapracował.

Najpierw odtworzenie, potem triaż: pięć pól, których musi wymagać twoja polityka

Ross McKerchar, CISO w Sophosie, i Ryan Westman ujmują standard zwięźle: programy potrzebują „jasnych PoC, logów, śladów wykonania, wersji, których dotyczy problem, i powtarzalnych kroków. Jeśli twierdzenia nie da się odtworzyć, nie ma dla niego miejsca w kolejce.”

Zamień to na wymagane pola formularza, a nie na akapit polityki. Wymagaj:

1. Działającego proof of concept. Skryptu, żądania albo śladu wykonania. Opis exploita prozą to nie exploit.
2. Dokładnych wersji, których dotyczy problem. SHA commita albo tag wydania. Nigdy „najnowsza”.
3. Kroków odtworzenia, które wykona ktoś zupełnie obcy, od czystego stanu po zaobserwowany skutek.
4. Czy jakakolwiek część tego znaleziska powstała z pomocą modelu? Tak albo nie, plus jaki system. Nie po to, żeby karać, tylko żeby wiedzieć, gdzie to skierować.
5. Czy człowiek zweryfikował to znalezisko od początku do końca? Tak albo nie, plus kto.

Całą robotę wykonuje piąte pole. To ono odróżnia przypadek Bynario, gdzie wynik pracy AI sprawdził człowiek i wyszło z tego krytyczne znalezisko, od zwykłych śmieci AI. Dziś prawie nikt o to nie pyta, a kosztuje to dwa pola tak/nie i jedno tekstowe. W chwili, w której zaczniesz przyjmować kampanie, dołóż jeszcze dwa: identyfikator partii albo nazwę kampanii oraz oczekiwaną datę ujawnienia. Niech zgłaszający zapisze swój zegar w twoim rejestrze, a nie na swoim blogu.

Zegar regulatora rusza 11 września 2026

Jeśli sprzedajesz do UE produkty z elementami cyfrowymi, jedno zgłoszenie z zewnątrz potrafi uruchomić termin prawny, który z twoją kolejką nie ma nic wspólnego. Od 11 września 2026 roku Cyber Resilience Act wymaga wczesnego ostrzeżenia w ciągu 24 godzin, pełnego powiadomienia w ciągu 72 godzin i raportu końcowego w ciągu 14 dni od zastosowania środka naprawczego, składanych do krajowego CSIRT przez CRA Single Reporting Platform i przekazywanych równocześnie do ENISA.

Ten zegar rusza w chwili, w której dowiadujesz się o aktywnym wykorzystywaniu podatności. Nie obchodzi go, że zgłoszenie przyszło jako pozycja 23 z 40, że nikt jeszcze go nie przeczytał ani że napisał je model. Partia leżąca cztery dni bez odczytu to już ryzyko niezgodności z przepisami, nie tylko zaległość. Cały obowiązek opisuje nasz przewodnik po unijnym Cyber Resilience Act.

Bez przyjmowania zgłoszeń kanałem ujawnienia staje się cudzy rejestr

Kiedy zgłaszający nie znajdzie sposobu, żeby się z tobą skontaktować, nie przestaje zgłaszać. Publikuje.

security.txt to najtańsza naprawa w bezpieczeństwie i zarazem najrzadziej stosowana. Przegląd miliona najpopularniejszych domen z 2025 roku wykazał, że plik publikuje 1,25% (12 510 witryn), wobec 0,7% w kwietniu 2024, a zgodnych z RFC 9116 jest wśród nich zaledwie 44%. Około 99% sieci nie ma czytelnego maszynowo adresu kontaktowego ds. bezpieczeństwa, a ponad połowa tych nielicznych ma go wadliwy.

Kit generuje zgodny plik na podstawie Csirt::SecurityTxtConfig, z polami Contact, Policy, Acknowledgments, Encryption oraz kroczącą datą Expires, ustawianą zawsze 365 dni naprzód. Jeśli nie masz jeszcze żadnego programu, zacznij od naszego przewodnika po uruchomieniu programu ujawniania podatności, zanim zaczniesz myśleć o partiach.

Jak CSIRT w Kit radzi sobie z kampanią i czego mu jeszcze brakuje

Część tego, czego wymaga ta chwila, w Kit już działa. Część nie, a ten podział mówi więcej niż lista funkcji.

Co się broni dzisiaj:

• Ustrukturyzowane przyjmowanie zgłoszeń zamiast pola na prozę. Csirt::Report wymaga title, description, vulnerability_type z zamkniętej listy oraz affected_endpoint, a do tego ma osobną kolumnę reproduction_steps. Ta kolumna dopuszcza wartość NULL, co według checklisty powyżej jest błędem. Ustawienie jej jako wymaganej to dokładnie ta zmiana konfiguracji, po którą trzeba dziś sięgnąć.
• Wykrywanie pochodzenia z AI jako pełnoprawny rekord. Csirt::AiScreening ocenia każde nowe zgłoszenie i zwraca ai_confidence_score wraz z sygnałami z zamkniętej listy (hallucinated_functions, fabricated_cves, no_specific_poc, vague_reproduction_steps i kolejne) oraz rekomendacją pass / review / flag. To test odtwarzalności wg Sophosa wdrożony jako kolumna, a nie jako akapit polityki.
• Grupowanie po przyczynie źródłowej istnieje już jako prymityw. Zgłoszenia niosą ze sobą wektor o 3 072 wymiarach, a wykrywanie duplikatów szuka najbliższych sąsiadów wg podobieństwa kosinusowego w obrębie programu. Tam, gdzie czterdzieści znalezisk to jedna klasa błędu, właśnie ten mechanizm zwija czterdzieści zgłoszeń w jedno.
• Reputacja zamiast limitów, przez karma_tier.
• SLA rozdzielone na potwierdzenie i rozwiązanie. Csirt::SlaConfig domyślnie daje 72 godziny na potwierdzenie i terminy rozwiązania zależne od poziomu ważności: od 24 godzin przy super_critical po 720 przy niskim, plus powtarzane alerty o naruszeniu i eskalację na dyżur przy krytycznych.

Czego brakuje, ujęte jako plan, a nie jako lista funkcji:

1. Brak obiektu kampanii. Czterdzieści zgłoszeń to wciąż czterdzieści wierszy z czterdziestoma zegarami.
2. Brak pól osi czasu ujawnienia. Cykl życia biegnie od submitted przez resolved do paid i nie ma w nim żadnego pojęcia opisującego zegar zgłaszającego.
3. Brak deklarowanych flag „wygenerowane przez model” i „zweryfikowane przez człowieka”. Wykrywanie pochodzenia z AI działa po fakcie, a samego zgłaszającego nikt o to nie pyta.
4. Domyślne limity, które odcięłyby zgłaszającego masowo w dobrej wierze, dokładnie tak jak limit Apple’a.

Każdy inny tekst o tym rejestrze traktuje go jako historię o modelu. To historia o skrzynce odbiorczej: znaleziska są w większości prawdziwe, w większości niezgłoszone i nadchodzą.

Zmiana, która cię na to przygotuje, jest niewielka: to kampania, a nie zgłoszenie, ma być tym, co twój program potwierdza, za co odpowiada i co odlicza. A potem wpisz datę zgłaszającego do swojego rejestru, zanim on wpisze ją na swoim blogu.