Jak uruchomić program zgłaszania podatności (VDP) w 2026 roku

Program ujawniania podatności (VDP) to proces, który wskazuje zewnętrznym badaczom bezpieczeństwa kanał i zasady zgłaszania błędów w twoim produkcie. W odróżnieniu od bug bounty, gdzie wypłacasz nagrody za zgłoszenia spełniające zasady programu, VDP po prostu ustanawia mechanizm przyjmowania zgłoszeń. Warto go przygotować, jeśli udostępniasz produkt przez internet. Amerykańska agencja CISA uczyniła VDP obowiązkowymi dla agencji federalnych w 2020 roku przez Binding Operational Directive 20-01, a sektor prywatny szybko podążył tym śladem.

Po co startupowi VDP

Ktoś może znaleźć podatność w twoim produkcie, nawet jeśli nie zaprosisz go do testów. VDP wyjaśnia, jak ją zgłosić i czego oczekiwać po wysłaniu raportu.

Wyobraź sobie konkretny scenariusz. Badacz odkrywa SQL injection w twoim API. Bez jasnych zasad może próbować dotrzeć do zespołu technicznego przez ogólny adres pomocy. To może opóźnić ocenę problemu. Z VDP badacz ma jasną ścieżkę do zgłoszenia problemu, a ty masz ustrukturyzowany proces, żeby go ocenić i zaplanować naprawę.

Raport IBM 2024 Cost of a Data Breach wycenia średni koszt wycieku danych na 4,88 miliona dolarów globalnie. To średnia dla badanych organizacji, nie prognoza straty twojego startupu. VDP wymaga czasu na ocenę zgłoszeń, komunikację i poprawki. Nie zastępuje zaplanowanych testów penetracyjnych.

NIS2 obejmuje zarządzanie podatnościami i skoordynowane ujawnianie; konkretne obowiązki firmy zależą od jej zakresu działalności i przepisów krajowych. Amerykańskie przepisy SEC z 2023 roku wymagają od spółek giełdowych raportowania istotnych incydentów cyberbezpieczeństwa co do zasady w ciągu czterech dni roboczych od ustalenia ich istotności. Audytorzy SOC 2 coraz częściej pytają o dowody na zewnętrzny kanał przyjmowania zgłoszeń o podatnościach, a obsługa zgłoszeń może dostarczać dowodów działania kontroli bezpieczeństwa. Jeśli planujesz sprzedawać klientom korporacyjnym, opublikowany VDP pojawia się w kwestionariuszach bezpieczeństwa. Pytania o zarządzanie podatnościami są teraz standardem w ocenach bezpieczeństwa dostawców, a opublikowany VDP pozwala wskazać działowi zakupów konkretny proces.

VDP vs. bug bounty: co najpierw?

VDP określa zasady przyjmowania zgłoszeń. Bug bounty dodaje nagrody finansowe. Uruchomienie bug bounty, zanim jesteś w stanie obsłużyć wolumen zgłoszeń, to częsty i kosztowny błąd.

Raport HackerOne 2024 Hacker-Powered Security wykazał, że 77% organizacji prowadzących bug bounty zaczęło od VDP. Najpierw sprawdź, czy potrafisz terminowo obsługiwać zgłoszenia. Dopiero potem dodaj nagrody.

Cztery fazy wdrożenia VDP

Przygotowanie VDP obejmuje cztery zadania. Czas wdrożenia zależy między innymi od zakresu testów, przeglądu prawnego i dostępności osób oceniających zgłoszenia.

Faza 1: Definiowanie zakresu

Określ dokładnie, które zasoby badacze mogą testować. Bądź precyzyjny co do domen, API i aplikacji mobilnych. Niejednoznaczność tutaj tworzy problemy w obie strony: badacze tracą czas na zasoby poza zakresem, a ty dostajesz zgłoszenia, na które nie możesz zareagować.

Przykładowy zakres: produkcyjne aplikacje webowe, publiczne API, aplikacje mobilne, konkretne subdomeny pod twoją kontrolą. Poza zakresem: wewnętrzna infrastruktura firmowa, konta pracowników, narzędzia SaaS stron trzecich (Stripe, Intercom) i bezpieczeństwo fizyczne.

Dopasuj zakres do systemów, za które odpowiadasz, i możliwości obsługi zgłoszeń. Jeśli obejmuje środowisko testowe, zespół musi być gotowy ocenić również jego podatności. Sprawdź, czy pominięcie API lub aplikacji mobilnej nie pozostawia istotnej części produktu bez opisanych zasad zgłaszania.

Jako punkt wyjścia obejmij zakresem wszystko, czego dotykają twoi klienci. To znaczy produkcyjne aplikacje webowe, publiczne API i wszystkie aplikacje mobilne, które dostarczasz. Wyklucz systemy dostawców, na których testowanie nie masz zgody. Błędy we własnej integracji mogą nadal należeć do twojego zakresu.

Faza 2: Kanały zgłoszeń i security.txt

Badacze potrzebują bezpiecznego, niezawodnego kanału do przesyłania znalezisk. Minimalne podejście to dedykowany adres [email protected] z szyfrowaniem PGP. Dla startupów otrzymujących więcej niż kilka zgłoszeń miesięcznie, ustrukturyzowany formularz webowy lub platforma zarządzana (HackerOne Response, Bugcrowd VDP, Intigriti) znacząco oszczędza czas triażu.

Niezależnie od wybranego kanału, sposób publikowania danych kontaktowych jest ustandaryzowany: security.txt. Zdefiniowany w RFC 9116, to maszynowo czytelny plik tekstowy pod /.well-known/security.txt, który mówi badaczom dokładnie, gdzie i jak zgłaszać podatności.

Kompletny security.txt wygląda tak:

Contact: mailto:[email protected]
Contact: https://yourcompany.com/security/report
Expires: 2027-03-15T00:00:00.000Z
Encryption: https://yourcompany.com/.well-known/pgp-key.txt
Policy: https://yourcompany.com/security/policy
Preferred-Languages: en
Canonical: https://yourcompany.com/.well-known/security.txt

Pole Expires jest obowiązkowe. Ustaw je maksymalnie na rok do przodu i dodaj cykliczne przypomnienie o aktualizacji. Po wygaśnięciu pliku badacz nie powinien zakładać, że jego dane nadal są aktualne. Według danych z securitytxt.org tylko około 1,25% spośród miliona największych stron publikuje plik security.txt w 2025 roku, w porównaniu z około 0,5% w 2022. Opublikuj plik i sprawdzaj, czy wskazane kanały działają.

Faza 3: Polityka safe harbor

To najbardziej wrażliwy prawnie element twojego VDP. Brak jasnej klauzuli safe harbor może zniechęcać badaczy do zgłaszania problemów. Będą się obawiać ścigania na podstawie Computer Fraud and Abuse Act (CFAA) w USA lub analogicznych przepisów w innych krajach.

Wytyczne Departamentu Sprawiedliwości USA z 2022 dotyczące CFAA wyraźnie stwierdzają, że „badania bezpieczeństwa prowadzone w dobrej wierze nie powinny być przedmiotem zarzutów”. Rozważ w klauzuli cztery zobowiązania, dostosowane do właściwego prawa: obietnicę niepodejmowania kroków prawnych wobec badaczy przestrzegających polityki, zobowiązanie do niewnoszenia roszczeń CFAA lub DMCA za badania prowadzone w dobrej wierze, deklarację współpracy z badaczami w przypadku działań prawnych ze strony podmiotów trzecich oraz uznanie badań prowadzonych zgodnie z polityką za autoryzowane.

Źle sformułowany safe harbor może albo narazić firmę na odpowiedzialność, albo nie zapewniać badaczom oczekiwanej ochrony. Zacznij od szablonów społeczności disclose.io, które przeszły przegląd prawny zespołów EFF, Dropbox i Bugcrowd. Potem poproś swojego prawnika o przegląd. Ustal z prawnikiem termin i zakres przeglądu.

Nie pisz klauzuli safe harbor od zera. Szablon disclose.io może być punktem wyjścia, ale trzeba dostosować go do zakresu programu i prawa. Zobowiązanie firmy nie wiąże niezależnych organów ani osób trzecich.

Faza 4: Wewnętrzne SLA i proces triażu

Terminowa odpowiedź pomaga utrzymać kontakt z badaczem. Success Index HackerOne konsekwentnie pokazuje, że programy z szybkim czasem odpowiedzi przyciągają znacząco więcej zgłoszeń i wyższej jakości. Badacze rozmawiają ze sobą. Brak odpowiedzi może zniechęcić do kolejnych zgłoszeń.

Poniższe terminy są przykładem. Przed publikacją dostosuj je do dyżurów i możliwości zespołu:

Używaj CVSS 4.0 (specyfikacja FIRST.org, opublikowana w listopadzie 2023) do oceny ważności. Nie wymyślaj własnej skali. CVSS to niedoskonały standard, ale jest wspólnym językiem między twoim zespołem a społecznością badaczy.

Ułóż proces oceny zgłoszeń obejmujący pięć etapów: odbiór (zgłoszenia trafiają na dedykowany kanał), triaż (inżynier ocenia ważność za pomocą CVSS), śledzenie (utwórz poufne zadanie wewnętrzne, bez publikowania nieusuniętej podatności na GitHubie), naprawa (przypisz do odpowiedniego zespołu) i odpowiedź (informuj badacza na każdym etapie). Gdy poprawka zostanie wdrożona, powiadom badacza i zaproponuj wpis na publicznej liście podziękowań dla badaczy.

Jak VDP wspiera wymagania bezpieczeństwa

VDP może wspierać zarządzanie podatnościami. Samo uruchomienie programu nie potwierdza zgodności z żadnym standardem.

SOC 2 Type II nie wymaga VDP z nazwy, ale Common Criteria dotyczące oceny ryzyka (CC3.2) i komunikacji (CC2.3) są znacznie łatwiejsze do spełnienia z udokumentowanym zewnętrznym kanałem przyjmowania zgłoszeń. Audytorzy coraz częściej tego oczekują.

ISO 27001:2022. Kontrola A.8.8 dotyczy zarządzania podatnościami technicznymi. Kanał zgłoszeń może dostarczać informacji do tego procesu; sam VDP nie wystarcza do oceny zgodności.

PCI DSS 4.0 Wymaganie 6.3.1 nakazuje identyfikację i zarządzanie podatnościami bezpieczeństwa ze źródeł zewnętrznych. VDP może być jednym ze źródeł takich informacji.

NIST Cybersecurity Framework 2.0 opisuje oczekiwany wynik, w którym podatności w zasobach były „identyfikowane, walidowane i rejestrowane” (ID.RA-01), wyraźnie włączając odkrycia zewnętrzne. Nowa funkcja Govern (GV.SC-05) dodaje zarządzanie ryzykiem łańcucha dostaw, w którym VDP odgrywają coraz ważniejszą rolę.

Dyrektywa NIS2 (UE) Artykuł 12 zobowiązuje państwa członkowskie do ustanowienia polityk skoordynowanego ujawniania podatności. Obowiązki podmiotów kluczowych i ważnych trzeba ustalić na podstawie właściwych przepisów.

Działający VDP dostarcza historii zgłoszeń i podjętych działań. Tę dokumentację możesz wykorzystać podczas audytu lub oceny bezpieczeństwa przez klienta.

Od VDP do bug bounty: kiedy dodać nagrody finansowe

Gdy twój VDP działa przez trzy do sześciu miesięcy ze sprawnym procesem oceny zgłoszeń, możesz rozważyć dodanie bounty. Jesteś gotowy, gdy twój średni czas do pierwszej odpowiedzi jest poniżej 24 godzin, naprawiłeś co najmniej 80% zgłoszonych podatności w ramach opublikowanych SLA, a twój zespół inżynierski ma proces priorytetyzacji poprawek bezpieczeństwa obok pracy nad funkcjonalnościami.

Kwoty bounty powinny odzwierciedlać rzeczywisty wpływ. Dane HackerOne z 2024 opisują poziomy wypłat; orientacyjne przedziały wynoszą: Krytyczna (zdalne wykonanie kodu, obejście uwierzytelniania): 3 000 do 15 000 $. Wysoka (stored XSS, IDOR z ekspozycją PII): 1 000 do 5 000 $. Średnia (reflected XSS, ujawnienie informacji): 250 do 1 000 $. Niska (open redirect, szczegółowe komunikaty o błędach): 50 do 250 $.

Dla startupów zaczynanie od dolnego końca jest w porządku. Obok stawek podaj terminy odpowiedzi i warunki wypłaty. Nie zakładaj, że szybka odpowiedź zawsze zrekompensuje niższą nagrodę.

Jak Kit obsługuje ujawnianie podatności

Kit zawiera wbudowany moduł CSIRT (Computer Security Incident Response Team), który traktuje ujawnianie podatności jako proces od przyjęcia zgłoszenia do rozwiązania.

Moduł zawiera konfigurowalny portal bezpieczeństwa na twojej domenie, przez który badacze wysyłają ustrukturyzowane zgłoszenia: typ podatności, zasoby, których dotyczy problem, kroki reprodukcji i ocena wpływu. Formularz zbiera te informacje w jednym zgłoszeniu. Każde zgłoszenie przechodzi przez zdefiniowany proces oceny zgłoszeń z konfigurowalnymi SLA. Kit automatycznie śledzi czas do pierwszej odpowiedzi, czas do triażu i czas do rozwiązania. Gdy zbliża się termin, przypisany członek zespołu dostaje powiadomienie. Po przekroczeniu terminu działają skonfigurowane reguły eskalacji.

Kit automatycznie generuje i utrzymuje twój plik security.txt, w tym obowiązkowe pole Expires wyliczane z ustawionego okresu ważności. Portal bezpieczeństwa obsługuje własne domeny, więc badacze komunikują się przez security.twojafirma.pl zamiast przez URL platformy zewnętrznej.

Moduł zawiera również publiczną listę podziękowań dla badaczy, integrację ze Slackiem do powiadomień o zgłoszeniach w czasie rzeczywistym i komunikację z badaczami bezpośrednio przez portal. Wypłaty nagród bug bounty są śledzone z pełnym rejestrem, co pozwala odtworzyć historię wypłat podczas przeglądu lub audytu.

Jeśli korzystasz również z modułu rekrutacji, oba obszary obsługujesz w ramach jednego konta Kit. Uprawnienia i konfigurację ustalasz osobno dla każdego modułu.

Przykładowy plan uruchomienia VDP

Poniższy plan rozkłada prace na pięć dni. Uwzględnij dodatkowy czas na przegląd prawny i uzgodnienia, jeśli będą potrzebne.

Dzień 1-2: Napisz politykę. Zacznij od szablonów disclose.io. Zdefiniuj zakres. Poproś prawnika o przegląd klauzuli safe harbor.

Dzień 3: Skonfiguruj kanał odbioru. Ustaw e-mail security@ z PGP albo formularz webowy. Opublikuj security.txt pod /.well-known/security.txt.

Dzień 4: Ułóż proces oceny zgłoszeń. Określ, kto odbiera zgłoszenia, jak oceniana jest ważność i jak śledzone są poprawki wewnętrznie.

Dzień 5: Przetestuj, składając zgłoszenie przez własny proces. Sprawdź, czy e-maile z potwierdzeniem się wysyłają, proces oceny zgłoszeń poprawnie kieruje zgłoszenia i szablony odpowiedzi są zrozumiałe. Potem ogłoś program: dodaj link w stopce strony, opublikuj wpis na blogu technicznym i powiadom odpowiednie społeczności bezpieczeństwa.

Po uruchomieniu VDP regularnie sprawdzaj kanał kontaktowy, terminy odpowiedzi i zaległe poprawki. Aktualizuj zakres oraz politykę, gdy zmienia się produkt.