Safe harbor czy pozew? Klauzula w VDP, która Cię chroni

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. Zamienia mgliste oczekiwania wobec „odpowiedzialnego” zachowania w spisaną umowę: zostań w zakresie, nie wykradaj danych, nie zakłócaj działania usługi, zgłaszaj oficjalnym kanałem — a masz upoważnienie do testowania. Bez tego liczące dekady przepisy antyhakerskie zostawiają nawet etycznych zgłaszających bez ochrony, a badacz, który znalazł Twój błąd, ma wszelkie powody, żeby milczeć albo go sprzedać.

W maju 2026 Microsoft pokazał całej branży, co się dzieje, gdy tej klauzuli brakuje albo się ją ignoruje. Ta historia to niemal idealne studium przypadku, jak niejednoznaczna polityka plus odruchowa groźba prawna z dnia na dzień niszczą zaufanie badaczy. Dobra wiadomość dla founderów: porażka była organizacyjna, nie techniczna — co oznacza, że startup może jej uniknąć od pierwszego dnia, mając właściwą politykę i proces.

Co Microsoft właśnie zrobił (i szybko cofnął)

Microsoft zagroził badaczowi bezpieczeństwa śledztwem karnym, przez kilka dni mierzył się z publiczną falą krytyki ze strony społeczności infosec, a potem publicznie się z tego wycofał. Cały łuk rozegrał się mniej więcej w miesiąc.

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 była ruchomym celem: 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. Reakcja była natychmiastowa i bezlitosna. Około 1–2 czerwca 2026 Microsoft odkręcił sprawę, 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”.

Jeden szczegół mówi więcej niż samo wycofanie. W trakcie kryzysu Microsoft po cichu zamienił w swojej komunikacji frazę „responsible disclosure” na „Coordinated Vulnerability Disclosure”. Ta zmiana słowa — do której jeszcze wrócimy — była wymownym sygnałem.

Dlaczego to porażka zaufania numer jeden w ujawnianiu

Szkody nie wyrządził tu żaden sprytny exploit. Wyrządziła je niejednoznaczność. Kiedy polityka nie mówi na piśmie, że badacze działający w dobrej wierze są bezpieczni, każde zgłoszenie staje się hazardem, a humor dostawcy danego dnia decyduje, czy pomocny nieznajomy jest partnerem, czy oskarżonym.

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 egzekwowanie zasad niczym się nie różni od braku jakiejkolwiek polityki. Jeśli badacze nie potrafią przewidzieć Twojej reakcji, zakładają najgorsze.

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”. To jest sedno lekcji. Groźba przy ujawnieniu nie karze tylko jednego badacza. Uczy kolejnych stu, żeby siedzieli cicho.

Co tak naprawdę oznacza „safe harbor”

Safe harbor to klauzula, która usuwa ten hazard. To spisana obietnica, opublikowana w Twojej polityce, że badacze działający w dobrej wierze nie zostaną pozwani ani zgłoszeni do ścigania.

Ż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. Framework safe harbor od disclose.io, otwartoźródłowy standard, 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. Safe harbor jest dziś głównonurtowym minimum — właśnie dlatego jego brak czyta się jako czerwona flaga dla ludzi, na których zgłoszeniach najbardziej Ci zależy.

Czy prawo już chroni badaczy? Przeważnie nie

Wielu founderów 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.

Przełóżmy to na proste słowa. 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. Federalna tarcza karna jest wąska i to nie Ty ją rozciągasz. Jedynym narzędziem, które zamyka te luki dla ludzi testujących Twoje systemy, jest zapis o safe harbor w Twojej własnej polityce. Prawo wyznacza minimum; to Twoja polityka sprawia, że zaproszenie jest prawdziwe.

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

Terminologia, którą wybierasz, sygnalizuje, czy widzisz w badaczach współpracowników, czy podejrzanych — a branża celowo odeszła od obciążonego znaczeniem terminu.

„Responsible disclosure” jest nacechowane wartościująco. Po cichu sugeruje, że każdy, kto nie trzyma się preferowanego przez dostawcę harmonogramu, jest nieodpowiedzialny — co całe moralne brzemię zrzuca na zgłaszającego, a żadnego na dostawcę, który siedział na poprawce. CERT/CC i większość społeczności bezpieczeństwa używa dziś Coordinated Vulnerability Disclosure (CVD), które opisuje proces bez grożenia palcem. Ujmuje ujawnianie jako dwustronny problem koordynacji — czyli to, czym faktycznie jest.

To nie jest akademickie dzielenie włosa na czworo. Przypomnijmy, że sam Microsoft w trakcie kryzysu przerzucił się z „responsible” na „coordinated”. Moussouris wskazała pierwotne sformułowanie jako „pierwszy cios”. Kiedy firma w oku cyklonu zmienia słownictwo pod presją, to mówi Ci, którego słowa nasłuchują ludzie zgłaszający błędy. Używaj „coordinated” w swojej polityce. Nic nie kosztuje, a sygnalizuje szacunek.

Koszt braku VDP: cisza albo szary rynek

Kiedy badacze nie mogą bezpiecznie zgłosić błędu, podatność nie znika. Po prostu nie usłyszysz o niej, dopóki nie zostanie uzbrojona — bo znalazca zamilkł albo znalazł lepiej płacącego kupca.

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 ustalenie HackerOne, a nie niezależny spis, ale kierunek nie budzi kontrowersji: większość organizacji nie ma drzwi frontowych.

Alternatywny rynek to brutalna ekonomia. Ceny exploitów na szarym rynku przyćmiewają każdą nagrodę od dostawcy. 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. Nie konkurujesz z tymi cenami i nie musisz. Musisz tylko sprawić, żeby skoordynowane zgłaszanie było na tyle bezpieczne i bezproblemowe, by badacz wybrał legalną ścieżkę. List z groźbą popycha go w drugą stronę.

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, a badacz powinien przeczytać ją w dwie minuty i dokładnie wiedzieć, co jest dozwolone.

W kwestii czasu zakotwicz się w utrwalonych normach, ż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 najtańszy sygnał zaufania, jaki możesz zaoferować. Główną pretensją badacza Nightmare-Eclipse było złe traktowanie — odebrane konto, wstrzymana nagroda i odebrana atrybucja — a nie brak wypłaty. Zadbaj o sygnały zaufania, a większość sporów w ogóle się nie zacznie.

Jak postawić to od pierwszego dnia, bez korporacyjnego narzutu

Powód, dla którego większość startupów pomija VDP, to nie spór z czymkolwiek powyżej. To że istniejące wytyczne są albo abstrakcyjnym standardem, albo prawnym szablonem — bez działającego programu w komplecie. OWASP daje Ci teorię. disclose.io daje Ci klauzulę. Żadne z nich nie daje triażu, SLA ani miejsca, gdzie badacz mógłby faktycznie złożyć zgłoszenie i śledzić jego postęp.

To dokładnie tę lukę zamyka moduł bezpieczeństwa Kit. Zamiast zszywać razem dokument polityki, formularz kontaktowy i arkusz kalkulacyjny, konfigurujesz jeden program, który mapuje się wprost na pięć składników powyżej:

• Safe harbor i zakres są częścią konfiguracji programu, więc zapisy o upoważnieniu i lista zasobów w zakresie żyją w polityce, którą czyta badacz, a nie w pamięci foundera.
• Prowadzony proces konfiguracji przeprowadza nowe konto od zera do działającego programu, więc „od czego ja mam właściwie zacząć” nigdy nie staje się ślepym zaułkiem.
• Ustandaryzowany przepływ coordinated disclosure obsługuje triaż, ocenę poziomu ważności i sprawdzanie duplikatów tak samo dla każdego zgłaszającego — czyli daje tę konsekwencję, której Microsoftowi zabrakło.
• Sygnały zaufania skierowane do badaczy są wbudowane: komunikacja w programie, przejrzysty status triażu, karma badacza oraz czysta ścieżka nagród i księgi finansowej, żeby nikt nie czuł się zignorowany ani oszukany.
• Zobowiązane SLA i widoczne osie czasu utrzymują szybką i audytowalną reakcję, eliminując wzorzec powolny-i-cichy, który popycha badaczy ku publicznemu ujawnieniu.

Jedno uczciwe zastrzeżenie, bo całym sensem tego artykułu nie jest obiecywanie za dużo. Kit daje Ci operacyjne rusztowanie i właściwe miejsce na zapisy o safe harbor. Nie jest poradą prawną. Niech prawnik przejrzy ostateczny tekst Twojej polityki przed publikacją, zwłaszcza sformułowania o upoważnieniu i zakresie. Powiedzenie tego wprost samo w sobie jest sygnałem zaufania i pasuje do tezy: jasność za każdym razem bije niejednoznaczność.

Jeśli chcesz głębszej mechaniki, nasz przewodnik jak skonfigurować program ujawniania podatności omawia kuchnię przyjmowania zgłoszeń, a kiedy badacze idą do opinii publicznej zgłębia, dlaczego to powolna obsługa, a nie wrogość, produkuje publiczne zrzuty zero-dayów. 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 foundera na pierwszy dzień

Nie potrzebujesz do tego zespołu bezpieczeństwa. Potrzebujesz popołudnia. Oto minimum:

1. Opublikuj klauzulę safe harbor stwierdzającą, że nie wystąpisz na drogę prawną przeciwko działającym w dobrej wierze badaczom, którzy zostają w zakresie. Zapożycz z disclose.io i daj prawnikowi do przejrzenia.
2. Zdefiniuj zakres wprost: które domeny i zasoby są w grze, a co jest poza granicami (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 obiecaj atrybucję każdemu, kto jej chce.

Błędem Microsoftu było sięgnięcie po groźbę prawną tam, gdzie powinien sięgnąć po jasną politykę. Startup ma przewagę: może zbudować politykę najpierw — zanim pojawi się pierwszy wkurzony badacz, zanim trafi pierwsze niewygodne zgłoszenie w support@, zanim liczba niezałatanych błędów zacznie rosnąć na oczach wszystkich. Zakoduj safe harbor, zakres, SLA i sygnały zaufania w swoim programie ujawniania już teraz, a nigdy nie będziesz musiał pisać blogowego wpisu z przeprosinami później.

Postaw bezpieczny dla badaczy VDP jeszcze dziś po południu, nie za kwartał. Zacznij za darmo z Kit i skonfiguruj swój program ujawniania w jednym miejscu.