2 436 błędów, jeden zgłaszający: przygotuj VDP na masowe zgłoszenia

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. Przy takiej liczbie znalezisk osobne potwierdzenia, terminy SLA i oceny ważności utrudniają obsługę całej kampanii.

To trzeci tekst z serii, tym razem o obsłudze masowych kampanii badawczych. Tekst o śmieciach AI dotyczył nieprawidłowych zgłoszeń napływających masowo. Tekst o modelu kosztów VDP omawiał spadek kosztu znalezienia prawdziwego błędu. Tutaj przyglądamy się temu, jak przekazać znaleziska opiekunom projektów i obsłużyć je w partiach.

Tekst o wielu dostawcach opisywał jeden błąd dotyczący pięciu dostawców; tutaj jeden zgłaszający zajmuje się naraz 269 projektami. Termin publikacji zależy od dostawcy modelu, który właśnie wprowadza produkt na rynek.

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. Rejestr pokazuje, na jakim etapie są poszczególne znaleziska.

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. Przy interpretacji tych liczb uwzględnij pochodzenie danych i udział różnych zespołów.

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. Liczba 2 436 dotyczy więc całej kampanii Z.ai, a nie wyłącznie pracy GLM-5.3.

Każda zbiorcza liczba pochodzi z publikacji samego Z.ai. Bez dostępu do 2 383 nieujawnionych wpisów nie możemy niezależnie sprawdzić tych wyników. Podobnie przy przyjęciu partii czterdziestu zgłoszeń nie znasz jeszcze ich jakości. Weryfikacja wymaga osobnej pracy.

Jeden zgłaszający, wielu odbiorców

Przy śmieciach AI problemem był stosunek sygnału do szumu, przy ekonomice triażu chodziło o koszt jednostkowy. Tutaj problemem jest liczba i organizacja zgłoszeń. 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 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.

Oba rejestry pokazują zaległość między wykryciem problemu a powiadomieniem opiekuna projektu. 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.

Odbiorcy mogą więc spodziewać się zgłoszeń w partiach, gdy zgłaszający zacznie opróżniać swoją kolejkę.

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

Obsługa pojedynczych zgłoszeń może wtedy powodować trzy problemy.

Lawina potwierdzeń. Automatyczna odpowiedź na każde zgłoszenie przy czterdziestu znaleziskach oznacza czterdzieści podobnych wiadomości. 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. Poszczególne zgłoszenia są jeszcze w terminie, ale zespół może nie zdążyć obsłużyć ich wszystkich. 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 ograniczony czas jednego zespołu.

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 powiela pracę i utrudnia zauważenie wspólnego wzorca.

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ń

Proponujemy grupowanie zgłoszeń w partie. Każda partia powinna mieć pięć elementów.

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ć? Ocenę całej partii odnosisz do poszczególnych zgłoszeń i korygujesz 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.

Powyższe pięć elementów opisuje proponowane rozszerzenie Kit.

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

Termin trzeba uzgodnić ze zgłaszającym i zapisać przy sprawie.

Ż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. Rejestr podaje status, poziom ważności i identyfikatory, lecz nie termin publikacji.

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.

Co ograniczył limit Apple’a

Pierwszym odruchem po lekturze tego wszystkiego jest nałożenie na nadawcę limitu. Apple przeprowadziło ten eksperyment publicznie i można prześledzić jego skutki. 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 i wyznaczyła urzędom federalnym 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.

Ta sekwencja zdarzeń nie dowodzi, że limit spowodował powstanie zero-daya. Pokazuje natomiast, że 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ń. Sam limit nie zwiększył czasu, jaki zespół mógł poświęcić na triaż.

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

GitHub połączył limity z podziałem badaczy 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. Warunki przejścia do wyższego poziomu są jawne: 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.

Warto uwzględnić tę różnicę przy projektowaniu programu: 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.

Piąte pole pozwala zapisać, czy zgłaszający deklaruje weryfikację przez człowieka. Taka deklaracja pomaga w triażu, ale nie zastępuje odtworzenia problemu przez odbiorcę. 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

Brak łatwo dostępnego kontaktu może skłonić zgłaszającego do publicznego opisania problemu.

Plik security.txt ułatwia znalezienie kontaktu ds. bezpieczeństwa, lecz wiele witryn go nie publikuje. 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% zbadanych domen nie miało czytelnego maszynowo adresu kontaktowego ds. bezpieczeństwa, a w ponad połowie witryn, które go opublikowały, plik zawierał błędy.

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

Kit obsługuje pojedyncze zgłoszenia. Przy kampanii możesz skorzystać z poniższych funkcji, ale grupowanie w partie wymagałoby rozszerzenia produktu.

Dostępne funkcje:

• 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, choć proponowane wyżej zasady wymagają podania kroków odtworzenia. Wymaganie jej uzupełnienia wymagałoby zmiany aplikacji; obecnie nie jest opcją w ustawieniach programu.
• Analiza oznak śmieci AI. 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 analiza treści zgłoszenia. Nie uruchamia proof of concept i nie potwierdza odtwarzalności podatności.
• Wskazywanie podobnych zgłoszeń. Zgłoszenia mają wektor o 3 072 wymiarach, a wykrywanie duplikatów szuka najbliższych sąsiadów wg podobieństwa kosinusowego w obrębie programu. Mechanizm wskazuje podobne zgłoszenia i możliwe duplikaty. Nie ustala wspólnej przyczyny błędu ani nie scala automatycznie czterdziestu zgłoszeń w jedno.
• Reputacja badacza, opisana przez karma_tier. Jak zaznaczono wyżej, nie znosi ona domyślnych limitów zgłoszeń.
• 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.

Proponowane rozszerzenia:

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”. Analiza oznak śmieci AI odbywa się po przyjęciu zgłoszenia, 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.

Z publicznego rejestru wynika, że większości znalezisk jeszcze nie przekazano opiekunom. Ich poprawność i skutki trzeba będzie ocenić po otrzymaniu pełnych zgłoszeń.

Przygotuj sposób przyjmowania całej kampanii: wspólne potwierdzenie, osobę odpowiedzialną i termin pierwszej odpowiedzi. Zachowaj osobne terminy naprawy poszczególnych podatności i zapisz datę ujawnienia uzgodnioną ze zgłaszającym.