Gdy badacze idą do opinii publicznej: ile kosztuje spartaczone ujawnienie

Badacze bezpieczeństwa wybierają pełne ujawnienie zamiast odpowiedzialnego nie dlatego, że chcą zrobić komuś krzywdę, lecz dlatego, że tracą zaufanie do procesu po stronie dostawcy. Zapalnik jest niemal zawsze operacyjny: zgłoszenie, które tygodniami leżało bez odpowiedzi, łatka wypuszczona po cichu, bez wzmianki o autorze, albo waga błędu po cichu obniżona do „brak wpływu”. Kiedy badacz dochodzi do wniosku, że współpraca z Tobą to strata czasu, publikuje. Problemem nigdy nie był sam błąd. Problemem był Twój proces ujawniania.

To jest ten „drugi dzień”, który większość zespołów pomija. Uruchomienie programu ujawniania podatności (VDP) to łatwa część: plik security.txt, opis zakresu, skrzynka odbiorcza. Prowadzenie go tak, żeby prawdziwi badacze zgłaszali błędy do Ciebie, a nie o Tobie — to część trudna. A w 2026 roku cena pomyłki była wystawiona na pełen widok publiczny.

Ujawnienie github.dev, które ominęło Microsoft szerokim łukiem

2 czerwca 2026 roku badacz bezpieczeństwa Ammar Askar opublikował kompletny proof-of-concept kradzieży tokena GitHub OAuth jednym kliknięciem w github.dev, przeglądarkowej wersji edytora VS Code. Exploit łączył w łańcuch propagację zdarzeń keydown w webview VS Code, by po cichu zainstalować lokalne rozszerzenie i wyprowadzić token użytkownika. Skradziony token nie był ograniczony do jednego repozytorium — dawał dostęp do każdego repo, do którego ofiara miała wgląd, w tym tych prywatnych (źródła: BleepingComputer, CSO Online).

Pod względem technicznym waga była wysoka. Ale to, co powinien przestudiować każdy właściciel programu, to samo ujawnienie.

Askar dał GitHubowi zaledwie godzinę uprzedzenia przed pójściem do opinii publicznej i świadomie pominął całkowicie Microsoft Security Response Center (MSRC). Jego deklarowany powód: wcześniejszy błąd w VS Code, który zgłosił, został po cichu naprawiony bez wzmianki o autorze i oznaczony jako pozbawiony wpływu na bezpieczeństwo. Doszedł do wniosku, że proces nie potraktuje jego pracy uczciwie, więc przestał w nim uczestniczyć. Współpracujący badacz zmienił się w kogoś, kto zrzuca zero-daya, z powodu tego, jak potraktowano jego poprzednie zgłoszenie.

Cała lekcja zamyka się w jednym zdaniu. Porażka w ujawnianiu zamieniła sojusznika w przeciwnika i żadna doza technicznej doskonałości po stronie Microsoftu nie była w stanie tego potem cofnąć. Microsoft wypuścił prowizoryczną łatkę (okno potwierdzenia dla notatników webowych i blokadę pomijania zaufania do wydawcy), ale zaufanie już przepadło, a niezałatany exploit był już publiczny.

Odpowiedzialne ujawnienie kontra pełne ujawnienie — i dlaczego granica się przesuwa

Odpowiedzialne ujawnienie (zwane też skoordynowanym ujawnianiem podatności) ma miejsce, gdy badacz zgłasza problem prywatnie i daje dostawcy czas na naprawę, zanim pojawią się jakiekolwiek publiczne szczegóły. Pełne ujawnienie to sytuacja, gdy badacz publikuje podatność, często wraz z działającym exploitem, zanim powstanie łatka. Granica między nimi nie jest kwestią charakteru. Zależy od tego, czy badacz wierzy, że dostawca wywiąże się ze swojej części umowy.

W branży funkcjonują dobrze znane punkty odniesienia dla tego, co znaczy „uczciwy czas na naprawę”:

• Google Project Zero stosuje 90-dniowy termin ujawnienia, skracany do 7 dni dla błędów aktywnie wykorzystywanych w atakach.
• CERT/CC ujawnia po 45 dniach od pierwotnego zgłoszenia, niezależnie od tego, czy łatka jest gotowa.

(Źródła: CERT/CC Guide to Coordinated Vulnerability Disclosure, Wikipedia: Coordinated vulnerability disclosure.)

Te terminy istnieją, bo badacze potrzebowali neutralnego punktu odniesienia, do którego mogli się odwołać, gdy dostawcy zwlekali w nieskończoność. To miara, według której rozczarowany badacz Cię ocenia.

Czego odpowiedzialne ujawnienie naprawdę wymaga od dostawcy

Odpowiedzialne ujawnienie to umowa dwustronna. Badacz zgadza się poczekać i zachować milczenie. W zamian dostawca zobowiązuje się szybko potwierdzić zgłoszenie, uczciwie komunikować się w sprawie wagi i terminów, naprawić problem i przyznać autorstwo. Większość opublikowanych polityk ujawniania ujmuje to dokładnie tak: współpraca w zamian za rzetelne potraktowanie w dobrej wierze. Gdy jedna strona dotrzymuje słowa, a druga nie, umowa się rozpada.

Gdy badacze uznają, że gra nie jest warta świeczki

Badaczom nikt nie płaci za czekanie. Wielu z nich robi to po godzinach, a ich reputacja opiera się na publicznym przypisaniu autorstwa. Kiedy dostawca traktuje zgłoszenie jak zbędny obowiązek, ignoruje je albo pozbawia badacza uznania, które usprawiedliwia nieodpłatny wysiłek, racjonalnym ruchem jest zaprzestanie współpracy. Pójście do opinii publicznej przywraca jedną rzecz, którą zepsuty proces odebrał: widoczny dowód wykonanej pracy.

Dlaczego badacze idą do opinii publicznej: pięć zabójców zaufania

W przypadku github.dev i w szerszych badaniach nad programami ujawniania raz po raz wraca tych samych pięć operacyjnych porażek. Żadna z nich nie jest natury technicznej. Każda to decyzja proceduralna, którą kontrolujesz.

1. Wolne lub milczące potwierdzenie. Zgłoszenie, które wisi bez odpowiedzi, mówi badaczowi, że jego czas się nie liczy.
2. Nieuzasadnione zaniżanie wagi. Oznaczenie prawdziwego błędu jako „brak wpływu” lub „niska waga” czyta się jak zła wola, zwłaszcza gdy badacz nie widzi uzasadnienia.
3. Ciche łatki bez wzmianki o autorze. Wypuszczenie poprawki przy jednoczesnym wymazaniu nazwiska badacza odbiera mu całą motywację do prywatnego zgłaszania.
4. Spóźniona lub brakująca wypłata. Gdy nagroda jest obiecana, opóźnienia i spory niszczą zaufanie tak samo szybko jak zaniżenie wagi.
5. Cisza komunikacyjna. Zniknięcie z radaru na czas naprawy zostawia badacza zgadującego, czy w ogóle cokolwiek się dzieje.

(Źródła: OWASP Vulnerability Disclosure Cheat Sheet, wywiad HelpNetSecurity z Royem Davisem z Zoom.)

Wolne lub milczące potwierdzenie

Potwierdzenie to najtańszy sygnał zaufania, jakim dysponujesz, i najłatwiejszy do zawalenia. Badacz, który napisał na Twoją skrzynkę i przez dwa tygodnie nie usłyszał nic, nie ma jak ocenić, czy pracujesz nad sprawą, czy ją ignorujesz. Uczciwym ruchem jest szybkie potwierdzenie, że żywy człowiek otrzymał zgłoszenie i wziął je na siebie. Programy rządowe traktują to jako absolutne minimum: zarówno Departament Handlu USA, jak i Departament Spraw Wewnętrznych zobowiązują się potwierdzać zgłoszenia w ciągu 3 dni roboczych, a Silicon Labs deklaruje to samo. Skoro agencje federalne dają radę zmieścić się w 3 dniach, startup też da.

Nieuzasadnione zaniżanie wagi

Spory o wagę błędu to drugi najczęstszy punkt zapalny — i da się go uniknąć. Problemem nie jest sama ocena, lecz to, że trafia ona do badacza jak werdykt z czarnej skrzynki, którego nie może ani sprawdzić, ani zakwestionować. Obniżenie wagi, które wygląda na sposób na uniknięcie wypłaty albo zminimalizowanie zażenowania, czyta się jak zła wola, nawet jeśli nią nie jest. Lekarstwem jest oparcie wagi na przejrzystym, standardowym frameworku (CVSS) i pokazanie, jak doszedłeś do wyniku, żeby badacz widział te same dane, na których pracowałeś.

Ciche łatki bez wzmianki o autorze

To właśnie ta porażka uruchomiła ujawnienie github.dev. Badacz zgłosił błąd, dostawca po cichu go załatał, a nazwisko badacza nie pojawiło się nigdzie. Dla kogoś, kto buduje karierę na publicznym przypisaniu autorstwa, cicha łatka jest gorsza od odrzucenia. Zabiera pracę i uznanie. Przyznanie autorstwa — czy to wzmianka w CVE, czy wpis w Hall of Fame — nic Cię nie kosztuje, a jest najpewniejszym sposobem, by badacz następnym razem znów zgłosił błąd właśnie Tobie.

Spóźniona lub brakująca wypłata

Jeśli prowadzisz program płatny, nagroda jest obietnicą. Badacze regularnie wskazują niespójne lub opóźnione wypłaty jako powód porzucania programów. Przewidywalny, możliwy do prześledzenia proces wypłat liczy się bardziej niż wysoka, efektowna kwota. Niepewność co do tego, kiedy i czy w ogóle dostaną pieniądze, robi większą szkodę niż skromna, ale niezawodna nagroda.

Cisza komunikacyjna

Nawet gdy faktycznie pracujesz nad sprawą, milczenie czyta się jak zaniedbanie. Wytyczne OWASP nie pozostawiają wątpliwości: wysyłaj okresowe aktualizacje statusu nawet wtedy, gdy nie ma żadnego postępu do zaraportowania, bo sama aktualizacja jest sygnałem, że zgłoszenie nie poszło w zapomnienie. Jednolinijkowe „wciąż nad tym pracujemy, oto na jakim jesteśmy etapie” co kilka tygodni często decyduje o tym, czy badacz poczeka, czy opublikuje.

To nie jest rzadkość: fala publicznych zrzutów zero-dayów w 2026

Sprawa github.dev nie była odosobnionym przypadkiem. W tym samym oknie kwiecień–czerwiec 2026 badacz znany jako „Chaotic Eclipse” publicznie zrzucił sześć niezałatanych zero-dayów w Windows, z czego trzy były już wykorzystywane w atakach. Podane powody to znajoma lista: ignorowane zgłoszenia, usunięte konto zgłaszającego, zerowe wynagrodzenie i poczucie, że został zniesławiony przez sposób, w jaki opis w advisory CVE przedstawiał jego pracę (źródła: SecurityAffairs, The Hacker News).

Microsoft publicznie potępił „nieskoordynowane” ujawnienia jako narażające klientów na zbędne ryzyko, a potem — po fali krytyki — wyciągnął rękę na zgodę. Cała sekwencja jest pouczająca: zrzucenie winy na badacza nie naprawiło procesu i nie powstrzymało kolejnego ujawnienia. Gdy ten sam schemat porażki rodzi wiele publicznych zrzutów w ciągu jednego kwartału, wymierzonych w jedną z najlepiej zaopatrzonych organizacji bezpieczeństwa na świecie, przestaje być problemem badaczy, a staje się problemem konstrukcji programu.

Co godny zaufania VDP robi inaczej

Godny zaufania program zamienia każdego z pięciu zabójców zaufania w zobowiązanie, na którym badacz może polegać. Mechanika nie jest egzotyczna — to dyscyplina operacyjna stosowana konsekwentnie.

Wspólnym mianownikiem tego wszystkiego jest szacunek dla czasu i pracy badacza. Zrób to dobrze, a zegar ujawnienia pozostanie prywatny. Zrób to źle, a badacz sięgnie po 90 dni Project Zero albo 45 dni CERT/CC jako standard, którego nie spełniłeś.

Jak Kit operacjonalizuje zaufanie badaczy

Moduł bezpieczeństwa Kit (Csirt) został zbudowany dokładnie wokół tych trybów porażki. Zrozumienie modelu działania znaczy więcej niż jakiekolwiek narzędzie, ale wartość narzędzia polega na tym, że czyni właściwe zachowanie domyślnym, zamiast czymś, co musisz pamiętać pod presją. Oto jak każdy zabójca zaufania przekłada się na konkretne ustawienie.

Żeby było jasne, czego Kit może, a czego nie może obiecać: Kit nie ma nic wspólnego z błędem w github.dev i żadne narzędzie by mu nie zapobiegło. To był produkt Microsoftu. Kit naprawia porażkę procesu ujawniania, która popchnęła badacza ku pełnemu ujawnieniu. Jeśli Twoja firma dostałaby zgłoszenie takie jak tamto, to właśnie SLA potwierdzenia w Kit, przejrzysta waga według CVSS, domyślne przyznanie autorstwa i przewidywalna wypłata sprawiają, że badacz nadal z Tobą współpracuje, zamiast publikować niezałatany exploit.

Twój proces ujawniania to Twoja postawa bezpieczeństwa

Wniosek z publicznych zrzutów zero-dayów z 2026 roku jest niewygodny, ale prosty: badacze nie idą do opinii publicznej z wrogości. Idą, bo proces zlekceważył ich czas i ich pracę. Wolne potwierdzanie, nieprzejrzyste zaniżanie wagi, ciche łatki, spóźnione wypłaty i cisza komunikacyjna nie są drobnymi potknięciami administracyjnymi. To bezpośrednia przyczyna niezałatanych exploitów lądujących na Hacker News, podpisanych Twoim nazwiskiem.

Każda z tych porażek to decyzja, którą kontrolujesz, i każda przekłada się na ustawienie, które możesz naprawić już dziś. Jeśli masz już VDP, kolejnym krokiem nie jest więcej polityki — to operacje „drugiego dnia”, które trzymają badaczy po Twojej stronie. Zacznij od poradnika konfiguracji, jeśli jeszcze tam nie jesteś, a następnie zamień odbiór zgłoszeń w przepływ pracy podparty SLA, z przyznawaniem autorstwa i wypłatami. Gdy będziesz gotów prowadzić to porządnie, możesz rozpocząć darmowy okres próbny i mieć całość gotową do działania w jedno popołudnie.