VDP vs bug bounty — jak bezpiecznie przyjmować zgłoszenia

Vulnerability Disclosure Program (VDP) i bug bounty rozwiązują podobny problem — pozwalają badaczowi bezpiecznie zgłosić lukę — ale nie są tym samym. VDP definiuje kanał, zasady i ochronę działania w dobrej wierze. Bug bounty dodaje zaproszenie do aktywnych testów oraz nagrody za wyniki spełniające kryteria.

CISA BOD 20-01 wprost rozróżnia politykę ujawniania od programu nagród. Organizacja może potrzebować VDP, zanim będzie gotowa finansowo i operacyjnie na bug bounty.

Co powinien zawierać VDP

Polityka publikuje:

• systemy objęte oraz wyłączone;
• dozwolone techniki i limity testów;
• zakaz dostępu do danych innych osób i utrzymywania dostępu;
• adres raportowania oraz wymagane informacje;
• bezpieczny sposób przesłania wrażliwych dowodów;
• oczekiwany czas potwierdzenia i aktualizacji;
• zasady coordinated disclosure;
• safe harbor dla badań prowadzonych zgodnie z polityką.

Plik security.txt w /.well-known/security.txt ułatwia znalezienie kontaktu, ale nie zastępuje pełnej polityki i zespołu triage.

Co dodaje bug bounty

Program nagród określa wysokość wypłat, kwalifikujące klasy błędów, duplikaty, priorytet pierwszego poprawnego zgłoszenia i warunki podatkowe. Może być prywatny — dla zaproszonych badaczy — albo publiczny.

Nagroda powinna wynikać z realnego wpływu i jakości dowodu, nie wyłącznie z CVSS. Błąd między tenantami, trwałe przejęcie konta i RCE wymagają innych progów niż brak nagłówka lub self-XSS.

Najpierw przygotuj triage

Nie uruchamiaj publicznego programu, jeśli raporty trafiają do nieobsługiwanej skrzynki. Potrzebujesz:

1. właściciela programu i zastępstwa;
2. SLA potwierdzenia, weryfikacji i aktualizacji;
3. bezpiecznego środowiska reprodukcji;
4. ścieżki do właściciela produktu;
5. sposobu oznaczania duplikatów oraz znanych problemów;
6. budżetu napraw i nagród;
7. procesu CVE i komunikacji z klientami, gdy jest potrzebny.

Safe harbor ma być konkretny

Badacz musi wiedzieć, które działania w dobrej wierze organizacja uzna za autoryzowane i kiedy nie będzie inicjować działań prawnych. Nie obiecuj ochrony za systemy należące do dostawcy, którego nie kontrolujesz.

Zabroń DoS, socjotechniki, fizycznego dostępu, masowego skanowania i pobierania danych ponad minimum potrzebne do dowodu, jeśli program nie jest przygotowany na te techniki. Jednocześnie nie używaj niejasnego „nie zakłócaj działania” jako pretekstu do odrzucenia każdego wartościowego raportu.

Jak oceniać raport

Raport powinien zawierać aktywo, warunki wstępne, kroki, dowód, wpływ i propozycję naprawy. Triage weryfikuje odtwarzalność, zakres kont, dane, możliwość automatyzacji i istniejące kontrolki.

Komunikuj status nawet wtedy, gdy naprawa trwa. Cisza skłania badacza do eskalacji publicznej. Po poprawce wykonaj retest i uzgodnij treść publikacji.

VDP czy bug bounty?

Zacznij od VDP, jeśli organizacja dopiero buduje kanał, ma ograniczony zespół albo nie wie, jak szybko naprawiać. Przejdź do prywatnego bounty po ustabilizowaniu triage. Publiczny program ma sens, gdy scope, budżet i naprawy skalują się wraz z liczbą raportów.

VDP nie zastępuje pentestu, a bug bounty nie gwarantuje systematycznego pokrycia. Najlepszy program łączy bezpieczny kanał, regularne testy i wewnętrzny proces naprawczy.

---

Safe harbor i obsługa zgłoszenia

Polityka powinna jasno określić dozwolone systemy i techniki, zakazane działania, sposób ochrony danych oraz zobowiązanie do działania w dobrej wierze wobec badań zgodnych z zasadami. Nie obiecuj ochrony, której prawnie nie możesz zapewnić. Zespół przyjmujący zgłoszenia potrzebuje klucza szyfrowania, potwierdzenia odbioru, priorytetyzacji i kanału do aktualizacji badacza.

security.txt ułatwia znalezienie kontaktu, ale nie zastępuje procesu. Testuj skrzynkę i terminy z zewnętrznej perspektywy. Mierz czas do potwierdzenia, triage, poprawki i informacji zwrotnej, a duplikaty analizuj jako sygnał powtarzalnej klasy błędu. Nagroda w bug bounty jest dodatkiem do VDP, nie warunkiem przyjmowania zgłoszeń.

Źródła: CISA BOD 20-01, CISA CVD, RFC 9116.