Safe harbor w VDP: jakie zobowiązanie składasz badaczom

Safe harbor w polityce ujawniania podatności to wyraźny zapis obiecujący, że twoja organizacja nie wystąpi na drogę prawną przeciwko badaczom bezpieczeństwa, którzy zgłaszają podatności w dobrej wierze. Określa warunki upoważnienia do testów: badacz ma przestrzegać zakresu, nie wykradać danych, nie zakłócać działania usługi i zgłaszać podatności oficjalnym kanałem. Taka deklaracja ogranicza niepewność co do reakcji firmy. Nie wiąże jednak niezależnych organów ścigania ani innych podmiotów.

Spór z Microsoftem w maju 2026 pokazał, jak niejasna komunikacja o działaniach prawnych może podważyć zaufanie do programu. Sama klauzula nie wystarczy, jeśli firma nie stosuje jej konsekwentnie.

Groźba Microsoftu i późniejsza zmiana stanowiska

Microsoft zagroził badaczowi bezpieczeństwa śledztwem karnym, przez kilka dni mierzył się z publiczną falą krytyki ze strony społeczności specjalistów od bezpieczeństwa, a potem publicznie się z tego wycofał. Spór trwał około miesiąca.

Na początku kwietnia 2026 pseudonimowy badacz znany jako „Nightmare-Eclipse” upublicznił kod proof-of-concept do serii zero-dayów w Windowsie, nie koordynując tego wcześniej z Microsoftem. Liczba opublikowanych błędów rosła: około sześciu błędów do końca maja (o nazwach takich jak BlueHammer, RedSun, UnDefend i YellowKey, krytyczne obejście BitLockera oznaczone jako CVE-2026-45585), a w miarę jak spór ciągnął się do czerwca, było ich coraz więcej. Microsoft opublikował wpis na blogu, nazywając nieskoordynowane ujawnienie „nigdy nieusprawiedliwionym”. Jego Digital Crimes Unit oświadczył, że będzie „nadal prowadzić sprawy przeciwko takim podmiotom oraz tym, którzy umożliwiają ich przestępczą działalność, koordynując w razie potrzeby działania z organami ścigania na całym świecie”.

Społeczność odczytała to jako groźbę postępowania karnego wymierzoną w badacza. Badacze publicznie skrytykowali tę komunikację. Około 1–2 czerwca 2026 Microsoft doprecyzował stanowisko, oświadczając, że „nie ma zamiaru podejmować działań przeciwko osobom prowadzącym lub publikującym badania nad bezpieczeństwem”, z zastrzeżeniem, że będzie współpracować z organami ścigania, gdy ktoś „łamie prawo i podejmuje złośliwe działania wyrządzające realną szkodę naszym klientom”.

Zmieniło się również używane określenie. W trakcie kryzysu Microsoft po cichu zamienił w swojej komunikacji frazę „responsible disclosure” na „Coordinated Vulnerability Disclosure”. Różnicę między tymi terminami opisujemy niżej.

Dlaczego przewidywalna reakcja ma znaczenie

Badacz powinien móc ustalić, jakie testy są dozwolone i jak firma zareaguje na zgłoszenie. Sprzeczne komunikaty utrudniają taką ocenę.

Sprzeczność pogorszyła sprawę. Kevin Beaumont, badacz bezpieczeństwa i były pracownik Microsoftu, nazwał ten epizod „pożarem śmietnika, który sami wzniecili”, wskazując, że Microsoft wcześniej zatrudnił SandboxEscaper, badaczkę, która opublikowała kod proof-of-concept do zero-daya w Windowsie, czyli dokładnie to zachowanie, które wpis na blogu firmy przedstawiał teraz jako przestępcze. Niekonsekwentne stosowanie zasad utrudnia przewidzenie reakcji firmy.

Katie Moussouris, która zaprojektowała pierwotny program bug bounty Microsoftu, a dziś prowadzi Luta Security, ostrzegła przed „efektem mrożącym, gdy mniej ludzi zgłasza się z błędami, przez co wszystkim nam jest mniej bezpiecznie”. Groźba wobec jednego badacza może więc zniechęcić również innych do kontaktu.

Co tak naprawdę oznacza „safe harbor”

Safe harbor to opublikowane zobowiązanie organizacji, że nie podejmie określonych działań prawnych wobec badaczy spełniających warunki polityki. Nie jest ogólnym immunitetem od odpowiedzialności.

Żeby zakwalifikować się do tej ochrony, badacze zwykle muszą spełnić krótką listę warunków:

1. Działać w dobrej wierze, z zamiarem poprawy bezpieczeństwa, nie żeby szantażować lub wyrządzać szkodę.
2. Pozostać w zdefiniowanym zakresie zasobów, do których testowania udzieliłeś upoważnienia.
3. Unikać naruszeń prywatności i wykradania danych, uzyskując dostęp tylko do minimum potrzebnego, żeby udowodnić błąd.
4. Unikać zakłócania usługi, bez ataków typu denial-of-service i testów destrukcyjnych.
5. Zgłaszać oficjalnym kanałem i dać rozsądny czas na poprawkę przed publicznym ujawnieniem.

To nie jest niszowa teoria prawna. Otwarty wzorzec safe harbor opracowany przez disclose.io został w 2020 przyjęty przez CISA, producentów maszyn do głosowania i kilka stanów USA, a domyślnie wchodzi w skład programów Bugcrowd. HackerOne utrzymuje „Gold Standard Safe Harbor”. Dropbox, Mozilla i programy z czasów GitHuba korzystają z jego wersji. Takie klauzule są szeroko stosowane w programach ujawniania podatności.

Co zmieniła polityka DOJ z 2022 roku

Wielu założycieli zakłada, że skoro amerykański Departament Sprawiedliwości złagodził stanowisko wobec Computer Fraud and Abuse Act, badacze są teraz bezpieczni, a własna klauzula jest zbędna. To założenie jest błędne na dwa istotne sposoby.

19 maja 2022 DOJ zmienił swoją politykę ścigania na gruncie CFAA, oświadczając, że nie będzie ścigać badań nad bezpieczeństwem prowadzonych w dobrej wierze. To był realny postęp. Ale sam DOJ jasno zaznaczył, że ta zmiana nie wpływa na odpowiedzialność cywilną i nie wiąże stanowych przepisów o przestępstwach komputerowych. Jak zauważyła w swojej analizie kancelaria Wilson Sonsini, w przypadku badaczy pozostają wątpliwości i możliwa odpowiedzialność cywilna.

Firma wciąż może pozwać badacza w sądzie cywilnym. Stanowy prokurator działający na podstawie stanowej ustawy antyhakerskiej wciąż może postawić zarzuty. Polityka DOJ dotyczy federalnego ścigania na gruncie CFAA. Klauzula twojej firmy może ograniczyć działania samej firmy i wyjaśnić zakres upoważnienia, ale nie usuwa ryzyka wynikającego z działań innych podmiotów lub organów.

„Responsible” kontra „coordinated” disclosure: słowa mają znaczenie

Terminologia, którą wybierasz, sygnalizuje, czy widzisz w badaczach współpracowników. Warto używać określenia opisującego wspólny proces.

„Responsible disclosure” jest nacechowane wartościująco. Po cichu sugeruje, że każdy, kto nie trzyma się preferowanego przez dostawcę harmonogramu, jest nieodpowiedzialny, nawet gdy dostawca długo nie przygotowuje poprawki. CERT/CC i większość społeczności bezpieczeństwa używa dziś Coordinated Vulnerability Disclosure (CVD), które podkreśla współpracę przy ocenie, naprawie i publikacji informacji.

Przykład Microsoftu pokazuje praktyczne znaczenie tego wyboru. Przypomnijmy, że sam Microsoft w trakcie kryzysu przerzucił się z „responsible” na „coordinated”. Moussouris wskazała pierwotne sformułowanie jako „pierwszy cios”. W swojej polityce używaj określenia „skoordynowane ujawnianie” i opisz obowiązki obu stron.

Brak kanału zgłoszeń utrudnia kontakt

Brak jasnych zasad i kanału kontaktowego może opóźnić przekazanie informacji o podatności. Nie pozwala jednak przewidzieć, czy znalazca zamilknie, opublikuje błąd, czy wybierze inny sposób działania.

Skala luki jest duża. Według własnych wyliczeń HackerOne 93% firm z Forbes Global 2000 nie ma opublikowanego sposobu, żeby badacz mógł zgłosić problem z bezpieczeństwem. To wynik własnej analizy dostawcy, a nie niezależnego spisu.

Niektóre oferty zakupu exploitów opiewają na bardzo wysokie kwoty. Brokerzy tacy jak Crowdfense reklamowali nawet około 9 milionów dolarów za pełny łańcuch zero-click exploitów na telefony; exploity przeglądarkowe sięgają 3–3,5 miliona dolarów; Zerodium reklamował nawet 2 miliony dolarów za łańcuch zdalnego wykonania kodu na Androida. To oferty dotyczące konkretnych, zaawansowanych łańcuchów ataku, a nie wycena dowolnego błędu. Własny program oprzyj na jasnym zakresie, przewidywalnej komunikacji i zasadach wypłat.

Pięć składników polityki, która chroni obie strony

Polityka ujawniania, która działa, jest krótka i konkretna. Ma pięć części, żeby badacz mógł szybko ustalić, co jest dozwolone.

Ustalając terminy, odwołaj się do przyjętych praktyk, żeby żadna ze stron nie musiała negocjować od zera. Faktycznym standardem branżowym dla okna ujawnienia jest około 90 dni; CERT/CC domyślnie daje około 45 dni; Google Project Zero stosuje 7-dniowy termin dla błędów aktywnie wykorzystywanych. SLA na potwierdzenie w ciągu 24–48 godzin to powszechna praktyka i zobowiązanie, które warto dopasować do dyżurów zespołu. Główną pretensją badacza Nightmare-Eclipse było traktowanie przez firmę, w tym odebrane konto, wstrzymana nagroda i brak uznania autorstwa. Wyjaśniaj takie decyzje i zapewnij drogę odwołania.

Jak skonfigurować program w Kit

W Kit skonfigurujesz program zgłaszania podatności w jednym miejscu:

• Polityka i zakres. Opublikuj zasady testowania, zasoby objęte programem i treść safe harbor.
• Konfiguracja programu. Ustaw kanał kontaktowy oraz wymagane informacje w zgłoszeniu.
• Ocena zgłoszeń. Zespół sprawdza ważność i duplikaty oraz zapisuje decyzje.
• Kontakt z badaczem. Wiadomości, status zgłoszenia i historia nagród pozwalają śledzić dalsze działania.
• Terminy. Ustaw SLA odpowiadające możliwościom zespołu i pilnuj zaległych odpowiedzi.

Kit udostępnia miejsce na politykę i obsługę zgłoszeń. Treść zobowiązań oraz zakres upoważnienia trzeba dostosować do prawa i możliwości firmy, a następnie konsekwentnie stosować.

Nasz przewodnik jak skonfigurować program ujawniania podatności opisuje organizację przyjmowania zgłoszeń, a gdy badacze ujawniają sprawę publicznie opisuje spory o komunikację i terminy publikacji. Jeśli wypuszczasz produkt na rynek UE, termin ujawnienia z Cyber Resilience Act czyni politykę CVD wymogiem prawnym, a nie tylko dobrą praktyką.

Lista kontrolna założyciela na pierwszy dzień

Przed uruchomieniem przypisz osoby odpowiedzialne za ocenę zgłoszeń i przegląd polityki. Następnie:

1. Opublikuj klauzulę safe harbor stwierdzającą, że nie wystąpisz na drogę prawną przeciwko działającym w dobrej wierze badaczom, którzy przestrzegają zakresu. Skorzystaj ze wzorca disclose.io i przekaż treść prawnikowi do przeglądu.
2. Zdefiniuj zakres wprost: które domeny i zasoby obejmuje upoważnienie oraz jakie działania są niedozwolone (bez wykradania danych, bez DoS, bez socjotechniki, bez usług firm trzecich).
3. Otwórz jeden kanał zgłaszania i ogłoś go plikiem security.txt pod /.well-known/security.txt.
4. Zobowiąż się do SLA na odpowiedź: potwierdź w ciągu 48 godzin, podaj realistyczny harmonogram poprawki i ujawnienia.
5. Używaj „coordinated”, nie „responsible” disclosure w całej polityce i zobowiąż się do podania autorstwa na życzenie badacza.

Przygotuj zasady przed pierwszym sporem. Ustal również, kto podejmuje decyzję o eskalacji prawnej i jak zespół sprawdza, czy badacz działał w granicach upoważnienia.

Rozpocznij bezpłatny okres próbny Kit i skonfiguruj kanał zgłoszeń, politykę oraz terminy odpowiedzi.