badacz bezpieczeństwa

Badacz bezpieczeństwa to specjalista, który wyszukuje i opisuje podatności oraz techniki ataku, a wyniki publikuje po to, by dało się je naprawić. Zwykle najpierw zgłasza błąd producentowi i czeka na poprawkę, a dopiero potem ujawnia szczegóły. CERT Polska oczekuje od zgłaszającego, że przed zgłoszeniem podatności do zespołu i przed jej upublicznieniem skontaktuje się bezpośrednio z właścicielem podatnego systemu ^[1]. Badacz jest więc hakerem działającym po jasnej stronie, w odróżnieniu od sprawcy, dla którego wiedza o błędzie jest narzędziem ataku.

Na czym polega praca

Praca badacza zaczyna się od analizy oprogramowania, urządzenia albo kampanii przestępczej. Może to być przegląd kodu wtyczki, testowanie aplikacji internetowej albo rozbiór złośliwego oprogramowania w odizolowanym środowisku. Wynikiem jest opis błędu, często z dowodem wykonalności, czyli PoC (proof of concept), który pokazuje producentowi, że problem istnieje, bez gotowego narzędzia do masowego ataku.

Kluczowa jest kolejność działań po znalezieniu błędu. Przyjętą praktyką jest skoordynowane ujawnianie podatności (coordinated vulnerability disclosure). CERT Polska prosi, by nie publikować informacji o podatności przed zakończeniem procesu jej obsługi ^[1]. Zespół może pośredniczyć w komunikacji między zgłaszającym a właścicielem systemu jako zaufana strona ^[1]. Wpisy CVE publikuje po 90 dniach od przesłania producentowi szczegółów, a wcześniej, jeśli poprawka już się ukazała albo producent nie współpracuje mimo wielokrotnych prób kontaktu ^[1]. Przebieg pokazuje schemat poniżej.

RYS. 1Skoordynowane ujawnienie podatności

Organizacje ułatwiają badaczom kontakt przez plik security.txt. RFC 9116 opisuje go jako maszynowo czytelny format, w którym organizacja opisuje swoje zasady ujawniania podatności ^[4]. Plik umieszcza się pod adresem /.well-known/security.txt, a wymagane pole Contact wskazuje, jak badacze mają zgłaszać podatności ^[4]:

Contact: mailto:security@example.com
Expires: 2027-09-01T00:00:00.000Z
Policy: https://example.com/polityka-zglaszania

Formy działalności

Badacz może pracować na kilka sposobów, a od formy zależy, czy ma zgodę właściciela systemu i kto mu płaci.

Platformy bug bounty coraz dokładniej sprawdzają uczestników. HackerOne 3 sierpnia 2026 roku ogłosiła obowiązkową weryfikację tożsamości dla uczestników programów z nagrodami pieniężnymi; jako powód podała przepisy o przeciwdziałaniu praniu pieniędzy ^[8]. Weryfikacja wymaga dokumentu tożsamości i zdjęcia na żywo, jest ważna 12 miesięcy, a programy ujawniania bez nagród jej nie wymagają ^[8]. Osobę, która zarabia głównie na takich nagrodach, nazywa się bug bounty hunter.

Granica między badaczem a grey hatem przebiega przy zgodzie. Polskie prawo przewiduje wyjątek z art. 269c Kodeksu karnego: nie podlega karze za przestępstwo z art. 267 § 2 lub art. 269a, kto działa wyłącznie w celu zabezpieczenia systemu, niezwłocznie powiadomił jego dysponenta o zagrożeniach, a jego działanie nie naruszyło interesu publicznego ani prywatnego i nie wyrządziło szkody ^[5]. Przepis nie obejmuje art. 267 § 1, czyli uzyskania informacji przez przełamanie zabezpieczenia ^[5], dlatego bezpieczniejsza jest zgoda właściciela albo udział w programie ujawniania.

W WordPressie

WordPress korzysta z pracy badaczy na kilku poziomach. W zespole bezpieczeństwa projektu działa ponad 50 zaufanych ekspertów, w tym główni deweloperzy i badacze bezpieczeństwa ^[2]. Projekt prosi, by podatność w rdzeniu zachować w poufności i zgłosić zespołowi bezpieczeństwa; podatność we wtyczce zgłasza się autorowi wtyczki i zespołowi wtyczek, a podatność w motywie autorowi motywu i zespołowi przeglądu motywów ^[2].

Dla wtyczek z katalogu wordpress.org podręcznik wskazuje adres plugins@wordpress.org. Zgłoszenie powinno zawierać zwięzły opis problemu, link do wtyczki i informację, czy zgłaszający sam potwierdził podatność ^[3]. Podręcznik wyraźnie prosi, by nie pisać o błędzie publicznie, bo to zwiększa liczbę włamań i nie przyspiesza poprawki ^[3]. Większość wtyczek jest na ten czas zamykana, żeby nie można ich było pobrać do czasu naprawy ^[3]. Zanim badacz napisze do zespołu, powinien spróbować skontaktować się z autorem bezpośrednio ^[3].

Dla właściciela strony praca badaczy ma konkretny skutek: po publikacji poprawki opis błędu staje się publiczny, a zautomatyzowane ataki zaczynają szukać stron, które jej nie wgrały. Dlatego ważna jest szybka aktualizacja oprogramowania.

Znaczenie

Badacze skracają czas, w którym podatność jest znana wyłącznie przestępcom. Błąd zgłoszony producentowi trafia do łatki, zanim ktoś wykorzysta go jako zero-day. Badacze analizują też kampanie przestępcze i infrastrukturę black hatów, dostarczając informacji, z których korzystają zespoły obrony.

Ta sama wiedza bywa jednak niebezpieczna. Opublikowany zbyt wcześnie opis albo gotowy exploit daje atakującym przewagę nad administratorami, którzy nie zdążyli wgrać poprawki. Stąd nacisk na koordynację i okres karencji przed publikacją.

Historia i przykłady

• KmdsBot, 2022. W listopadzie 2022 roku badacze z zespołu SIRT firmy Akamai analizowali złośliwe oprogramowanie KmdsBot ^[6]. Podczas testów w kontrolowanym środowisku polecenie z błędem składni spowodowało awarię serwera C2; boty, które nie miały mechanizmu utrwalenia i zależały od stałej łączności z serwerem, przestały działać ^[6]. Tak przypadkiem unieszkodliwiono botnet używany do ataków DDoS i kopania kryptowalut ^[6].
• Porzucone domeny w webshellach, 2025. Sekurak 20 stycznia 2025 roku opisał badanie zespołu watchTowr ^[7]. Badacze przeanalizowali publicznie dostępne narzędzia typu webshell i ustalili, że wiele z nich zawiera tylną furtkę raportującą autorom, gdzie narzędzie zostało użyte ^[7]. Część domen, do których furtki wysyłały dane, wygasła; po ich przejęciu badacze zidentyfikowali niemal 4000 wcześniej przejętych systemów, w tym systemy rządowe ^[7]. Rejestrowali tylko przychodzące połączenia, a domeny przekazali fundacji Shadowserver ^[7].