Dlaczego badacze publikują podatności przed wydaniem poprawki

Niektórzy badacze publikują podatność przed wydaniem poprawki, gdy tracą zaufanie do procesu zgłoszeń. Powodem może być brak odpowiedzi, spór o ocenę lub niewywiązanie się z uzgodnień. Nie da się jednak wyjaśnić każdej publikacji tym samym motywem. Dla zespołu bezpieczeństwa istotne jest to, na co ma wpływ: rzetelna ocena zgłoszenia, komunikacja i dotrzymywanie własnych zobowiązań.

Uruchomienie programu ujawniania podatności (VDP) obejmuje m.in. plik security.txt, zakres testów i kanał zgłoszeń. Później trzeba zapewnić obsługę: wyznaczyć osoby odpowiedzialne, śledzić terminy i informować badacza o postępach. Poniższe przypadki pokazują, co może utrudnić tę współpracę.

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

2 czerwca 2026 roku badacz bezpieczeństwa Ammar Askar opublikował działający przykład kradzieży tokena GitHub OAuth jednym kliknięciem w github.dev, przeglądarkowej wersji edytora VS Code. Exploit wykorzystywał propagację zdarzeń keydown w webview VS Code, by bez wiedzy użytkownika zainstalować lokalne rozszerzenie i wyprowadzić token użytkownika. Skradziony token nie był ograniczony do jednego repozytorium i 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).

Dla właściciela programu oprócz szczegółów technicznych istotny jest przebieg ujawnienia.

Askar dał GitHubowi zaledwie godzinę uprzedzenia przed publikacją 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ć. To uzasadnienie przedstawione przez badacza; nie przesądza o ocenie wszystkich działań stron.

Microsoft wydał doraźne zabezpieczenia, m.in. okno potwierdzenia dla notatników webowych i blokadę pomijania zaufania do wydawcy. Z perspektywy programu zgłoszeń warto przeanalizować również wcześniejszy spór: czy badacz otrzymał uzasadnienie oceny i informację o poprawce.

Koordynacja publikacji i terminy

Skoordynowane ujawnianie 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. Na termin publikacji wpływają m.in. ryzyko dla użytkowników, aktywne ataki i ustalenia stron.

Przykłady polityk publikacji:

• Google Project Zero stosuje politykę 90+30: co do zasady 90 dni na poprawkę, a przy terminowej naprawie kolejne 30 dni do publikacji szczegółów. Dla podatności aktywnie wykorzystywanych przewiduje krótszy termin. Polityka opisuje również wyjątki.
• CERT/CC przyjmuje zwykle 45 dni od pierwszego zgłoszenia, z możliwością dostosowania terminu do okoliczności. To zasada konkretnego koordynatora, nie powszechny termin prawny.

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

Takie polityki pomagają określić oczekiwania. Własny program powinien jasno opisywać sposób uzgadniania publikacji i reagowania na opóźnienia, zamiast traktować cudzy termin jako automatycznie wiążący wszystkich.

Czego odpowiedzialne ujawnienie naprawdę wymaga od dostawcy

Koordynacja wymaga uzgodnienia kontaktu, oceny, naprawy i publikacji. Potwierdź zgłoszenie, wyjaśnij rozbieżności i ustal termin kolejnej informacji. Zakres zobowiązań wynika z polityki programu oraz ustaleń stron; nie każde zgłoszenie oznacza obietnicę nagrody lub publikacji CVE.

Uznanie autorstwa i oczekiwania

Publiczne przypisanie autorstwa bywa ważną częścią pracy badacza. Brak odpowiedzi lub pominięcie uzgodnionego podziękowania może zniechęcić do kolejnego zgłoszenia. Ustal, czy badacz chce występować pod nazwiskiem, pseudonimem, czy pozostać anonimowy. Publikacja przed poprawką może zarazem zwiększyć ryzyko dla użytkowników. To ryzyko trzeba uwzględnić przy ustalaniu dalszego postępowania.

Pięć problemów w obsłudze zgłoszeń

W opisanym sporze i poradnikach prowadzenia programów powtarzają się problemy, które warto uwzględnić w przeglądzie własnego procesu:

1. Opóźnione potwierdzenie lub jego brak. 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” może budzić wątpliwości, zwłaszcza gdy badacz nie widzi uzasadnienia.
3. Ciche łatki bez wzmianki o autorze. Wypuszczenie poprawki przy jednoczesnym wymazaniu nazwiska badacza może zniechęcić do kolejnego prywatnego zgłoszenia.
4. Spóźniona lub brakująca wypłata. Jeśli program obiecał nagrodę, opóźnienia i spory mogą podważyć zaufanie do jego zasad.
5. Cisza komunikacyjna. Brak aktualizacji podczas naprawy sprawia, że badacz nie wie, czy w ogóle cokolwiek się dzieje.

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

Opóźnione potwierdzenie lub jego brak

Potwierdzenie odbioru nie zastępuje oceny technicznej, ale pozwala ustalić, że zgłoszenie dotarło. Podaj osobę odpowiedzialną lub termin pierwszej odpowiedzi. Przykładowo 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. Dobierz własny termin do obsady zespołu i sposobu liczenia dni roboczych.

Nieuzasadnione zaniżanie wagi

Spór o ocenę może dotyczyć założeń: wymaganych uprawnień, sposobu ataku albo skutków w danym środowisku. Pokaż wektor CVSS i uzasadnienie. Wyjaśnij także, jak ocena techniczna łączy się z priorytetem naprawy i tabelą nagród. To powiązane, ale różne decyzje.

Ciche łatki bez wzmianki o autorze

Askar wskazał brak uznania wcześniejszej pracy jako jeden z powodów swojej decyzji. Ustal zasady podziękowań i stosuj je konsekwentnie. Wpis w Hall of Fame lub wzmianka w komunikacie powinny odpowiadać preferencjom badacza. Nie każda poprawka wymaga CVE, a publikacja danych autora nie powinna być automatyczna.

Spóźniona lub brakująca wypłata

W płatnym programie podaj warunki przyznania nagrody, sposób ustalenia kwoty i termin wypłaty po spełnieniu wymaganych warunków. Jeśli wystąpi opóźnienie, wyjaśnij je i podaj nowy termin. Wysoka maksymalna nagroda nie zastępuje przewidywalnej obsługi zwykłych zgłoszeń.

Cisza komunikacyjna

Przekazuj aktualizacje w uzgodnionym rytmie. Gdy nie ma postępu, powiedz, co blokuje pracę i kiedy wrócisz z informacją. Samo powtarzanie „pracujemy nad tym” bez dalszego planu może nie wystarczyć.

Inne publiczne spory w 2026 roku

Sprawa github.dev nie była odosobnionym przypadkiem. W okresie od kwietnia do czerwca 2026 badacz znany jako „Chaotic Eclipse” opublikował sześć niezałatanych zero-dayów w Windows, z czego trzy były już wykorzystywane w atakach. Badacz wymieniał ignorowane zgłoszenia, usunięte konto zgłaszającego, zerowe wynagrodzenie i poczucie, że został zniesławiony przez sposób, w jaki opis w biuletynie CVE przedstawiał jego pracę (źródła: SecurityAffairs, The Hacker News).

Microsoft skrytykował „nieskoordynowane” ujawnienia jako narażające klientów na ryzyko, a następnie wyciągnął rękę na zgodę. Spór warto analizować z uwzględnieniem relacji obu stron. Samo przypisanie winy nie rozstrzyga, jak bezpiecznie skoordynować kolejne zgłoszenie.

Co godny zaufania VDP robi inaczej

Przełóż zasady programu na działania, których wykonanie można sprawdzić:

Dobra obsługa zwiększa szansę na współpracę, ale nie daje kontroli nad decyzją badacza o publikacji. Ustal terminy i reaguj, gdy nie możesz ich dotrzymać.

Jak Kit wspiera obsługę zgłoszeń

Moduł CSIRT przechowuje zgłoszenia, ich statusy i cele czasowe. Domyślne SLA potwierdzenia wynosi 72 godziny. Automatyczna wiadomość o przyjęciu zgłoszenia nie oznacza, że zespół już je ocenił, a 72 godziny nie są tym samym co trzy dni robocze.

Ocena CVSS pomaga ustalić poziom ważności. Trzeba jednak sprawdzić dane wejściowe i wyjaśnić rozbieżności. Cele rozwiązania, m.in. 24 godziny dla poziomu superkrytycznego i 72 dla krytycznego, są ustawieniami procesu, nie gwarantowanym czasem wydania poprawki.

Hall of Fame i reputacja pomagają wyróżniać badaczy zgodnie z zasadami programu. Rejestr nagród oraz wypłat pokazuje ich obsługę. Dyżury, w tym integracja z PagerDuty, pomagają kierować pracę do odpowiednich osób. Żadna z tych funkcji nie zapewnia, że badacz powstrzyma się od publikacji.

Sprawdź ostatnie zgłoszenia

Wybierz kilka spraw i sprawdź: czas pierwszej odpowiedzi, uzasadnienie oceny, regularność aktualizacji oraz wykonanie ustaleń o nagrodzie i podziękowaniu. Popraw powtarzające się braki i wyznacz osoby odpowiedzialne za ich usunięcie.

Jeśli dopiero uruchamiasz program, zacznij od poradnika konfiguracji. Możesz też rozpocząć bezpłatny okres próbny, żeby sprawdzić obsługę zgłoszeń w Kit.