MyDr i cztery inne naruszenia: czego można oczekiwać od VDP

12 sierpnia 2026 MyDr sp. z o.o., polski dostawca oprogramowania do elektronicznej dokumentacji medycznej, potwierdził na własnej stronie o incydencie, że „stał się celem zewnętrznego, celowego działania przestępczego”, które objęło „część danych”. Osobno napastnicy przekazali Zaufanej Trzeciej Stronie, że mają 18 814 422 unikalne numery PESEL. MyDr nie potwierdza ani tej liczby, ani żadnej innej.

Porównanie z czterema innymi naruszeniami pokazuje różne problemy z wykrywaniem incydentów, przechowywaniem danych i komunikacją. Dostępny kanał zgłoszeń może pomóc, ale nie wyjaśnia przyczyn tych pięciu zdarzeń.

Na podstawie publicznych informacji nie można stwierdzić, czy VDP zapobiegłby któremukolwiek z tych naruszeń. Warto natomiast sprawdzić, jak osoba z zewnątrz mogła przekazać informację o problemie.

Co się stało w MyDr i trzy liczby, które się nie zgadzają

MyDr dostarcza polskim przychodniom oprogramowanie do prowadzenia dokumentacji i do zarządzania placówką; grupa Docplanner (ZnanyLekarz) ogłosiła jego przejęcie 9 stycznia 2023. Według stanu na 12 sierpnia 2026 źródła różniły się w ocenie skali incydentu.

• Twierdzą napastnicy: 18 814 422 unikalne numery PESEL i około 2,5 TB. Zaufana Trzecia Strona zaznacza, że nie zdołała zweryfikować ani jednego, ani drugiego.
• Mówi rząd: wicepremier Krzysztof Gawkowski powiedział 12 sierpnia, że skradziono blisko 19 milionów rekordów, „co potwierdza sama firma” (Bankier, 2026).
• Stanowisko MyDr: firma potwierdziła incydent, ale nie jego skalę. Strona firmy, zaktualizowana tego samego dnia o 18:35, mówi, że spółka nie jest w stanie potwierdzić liczby ani rodzaju ujawnionych danych, a same dane opisuje jako „najprawdopodobniej archiwalne, z roku 2024 i lat wcześniejszych”.

Dwa z tych źródeł są pierwotne, opublikowane w odstępie kilku godzin i sprzeczne w najważniejszym punkcie. Na dzień opisywanego przeglądu nie było potwierdzonej liczby rekordów. Zaufana Trzecia Strona zweryfikowała wprawdzie część próbki od napastników, w tym rekord polityka wysokiego szczebla i trzy trafienia w teście na pięciu numerach PESEL. To potwierdza, że napastnicy mają prawdziwe dane wyglądające na pochodzące z MyDr. Liczby 18,8 miliona nie potwierdza.

Opis przyczyny pochodzi wyłącznie od napastników i nie został niezależnie potwierdzony. Podatność XXE w obsłudze certyfikatów prowadząca do wykonania kodu, skradziony klucz API do GitHuba, potem AWS. MyDr nie opublikował szczegółów technicznych. Publiczne informacje nie pozwalają przypisać ataku konkretnej grupie ani państwu. Dat wykrycia nie znamy, bo firma informuje, że nie może ich podać w trakcie postępowania; nie da się więc wyliczyć, jak długo napastnicy mieli dostęp.

Liczy się kolejność zdarzeń. 5 sierpnia napastnicy pokazali dziennikarzom zrzut ekranu wiadomości, którą mieli wysłać prezesowi właściciela platformy. Był w niej link do PDF-a zabezpieczonego hasłem, a hasłem był PESEL samego prezesa. 8 sierpnia odezwali się do mediów. Pierwsze oświadczenie MyDr padło 10 sierpnia, tego samego dnia, w którym dziennikarze opublikowali tekst.

Pacjenci wciąż nie mają jak sprawdzić, czy ich to dotyczy. MyDr jest podmiotem przetwarzającym w rozumieniu RODO, więc komunikat UODO z 12 sierpnia nakłada obowiązek zawiadomienia osób na administratorów, czyli na tysiące przychodni, które korzystały z oprogramowania. Rządowy serwis do sprawdzania wycieków informuje, że danych z MyDr do niego nie wgrano.

Dostępność kanałów zgłaszania błędów sprawdziliśmy 12 sierpnia 2026. Adres mydr.pl/.well-known/security.txt przekierowuje na stronę zbiorczą, a pro.mydr.pl zwraca 404. Jedyny w całej grupie plik security.txt (RFC 9116) leży pod konsumencką marką znanylekarz.pl i ma 44 bajty: jedną linię Contact:, bez pola Expires, którego RFC wymaga.

Ten przegląd dotyczy dostępności kanału. Nie znaleźliśmy publicznej informacji o wcześniejszej próbie zgłoszenia podatności.

Skąd firmy dowiadują się, że ktoś się do nich włamał?

W 2025 roku tylko 52% organizacji samodzielnie wykryło złośliwą aktywność jako pierwsze. 34% dowiedziało się od podmiotu z zewnątrz, na przykład od organów ścigania albo CERT-u, a 14% od samego napastnika, zwykle z żądania okupu (Mandiant M-Trends 2026, 2026).

Mediana czasu, przez jaki napastnik pozostawał niezauważony, wyniosła 14 dni wobec 11 rok wcześniej: 9 dni przy wykryciu wewnętrznym i 25 dni, gdy pierwszy zauważył ktoś inny. Ta różnica nie dowodzi wpływu VDP. Badanie porównuje sposoby wykrycia w analizowanych incydentach, a nie obecność kanału zgłoszeń.

Change Healthcare: 190 milionów osób i jedna niedokończona migracja

Raport 10-K UnitedHealth za rok obrotowy 2024 mówi o „około 190 milionach” osób. Wyższa liczba, 192,7 miliona, pochodzi z portalu naruszeń HHS OCR i z prasy branżowej, a nie z jakiegokolwiek dokumentu złożonego do SEC; liczba zgłoszona do OCR rosła zresztą od zastępczej wartości 500 osób przez blisko półtora roku.

Przyczynę źródłową znamy z zeznań prezesa Andrew Witty’ego złożonych pod przysięgą. 12 lutego 2024 przestępcy wykorzystali przejęte dane logowania, żeby dostać się do portalu Citrix, który „nie miał uwierzytelniania wieloskładnikowego”, przeszli dalej w głąb sieci i wynieśli dane między 17 a 20 lutego. Atak ransomware rozpoczął się 21 lutego, dziewięć dni po wejściu do sieci. Kilka serwisów obwiniło CitrixBleed; żadne źródło pierwotne tego nie potwierdza.

Na pytanie Senatu, dlaczego serwer wystawiony do internetu nie miał MFA, UnitedHealth odpowiedział, że „chodzi o odziedziczony serwer Change Healthcare, a nasz zespół pracował nad doprowadzeniem go do standardów UHG”. Przejęcie zamknięto szesnaście miesięcy wcześniej. Formularz 8-K z ujawnieniem na podstawie Item 1.05 złożono dzień po wykryciu, ale wysyłka listów do poszkodowanych zaczęła się dopiero pod koniec lipca 2024, jakieś pięć miesięcy po tym, jak dane zostały wykradzione.

Kanał istniał, ale jego polityka ograniczała dozwolone testy. Polityka zgłaszania podatności UnitedHealth, dostępna co najmniej od 2019 roku, nie oferowała nagród, safe harbor ani żadnego SLA na odpowiedź. Zakazywała „aktywnego skanowania lub testowania podatności”, wykluczała „naruszenie »dobrych praktyk«” i zapowiadała, że firma „nie będzie ujawniać, omawiać ani potwierdzać problemów bezpieczeństwa”. Takie ograniczenia mogły zniechęcać do badania publicznie dostępnej bramy. Nie dowodzą jednak, że zgłoszenie braku MFA zostało złożone lub odrzucone.

Salesloft Drift: ograniczona widoczność z zewnątrz

Ten przypadek pokazuje ograniczenia zewnętrznego badania produktu. Od marca do czerwca 2025 napastnik śledzony jako UNC6395 miał dostęp do konta GitHub Salesloftu, potem przeszedł do środowiska AWS należącego do Drifta, gdzie trzymano tokeny OAuth klientów, i tymi ważnymi, skradzionymi tokenami sięgnął do instancji Salesforce tych klientów. Google Threat Intelligence Group stwierdza, że problem „nie wynika z podatności w samej platformie Salesforce”. Salesloft do dziś nie ujawnił, jak stracił konto na GitHubie.

Ważne tokeny pozwalały wywoływać API bez ponownego interaktywnego logowania. Nie oznacza to, że monitoring nie mógł wykryć nietypowej aktywności. Napastnikowi chodziło o dane uwierzytelniające wklejane do zgłoszeń do pomocy technicznej. Cloudflare znalazł w treści własnych wykradzionych zgłoszeń 104 działające tokeny API i wymienił wszystkie, a cały ten zbiór został wykradziony w 3 minuty i 22 sekundy.

Od pierwszego dostępu do GitHuba do ujawnienia incydentu 20 sierpnia 2025 minęło blisko pięć miesięcy, a od końca zaobserwowanego wycieku do unieważnienia tokenów tylko dwa dni.

Publiczny VDP ma tu ograniczone możliwości. Przejęcie konta na GitHubie i scentralizowany magazyn tokenów we własnym AWS dostawcy nie są widoczne z zewnątrz, więc sam zewnętrzny kanał zgłoszeń nie zapewnia wykrycia takiego ataku.

Przykładem podatności możliwej do zgłoszenia z zewnątrz jest inny błąd, w tym samym ekosystemie i tym samym kwartale. Noma Security znalazło w Salesforce Agentforce podatność ForcedLeak (CVSS 9,4), czyli wygasłą domenę, która nadal znajdowała się na liście dozwolonych w CSP i którą dało się kupić za jakieś 5 dolarów. Zgłoszenie 28 lipca 2025, potwierdzenie 31 lipca, poprawka 8 września, publikacja 25 września. Znalezione z zewnątrz, zgłoszone, naprawione, opisane.

Free Mobile: 42 mln euro kar i zbyt długie przechowywanie danych

Decyzje CNIL ze stycznia 2026 ustalają potwierdzoną skalę na 24 633 469 umów: 19 460 891 mobilnych i 5 172 577 stacjonarnych, a w przypadku klientów korzystających z obu usług także imiona i nazwiska, adresy, daty urodzenia oraz numery IBAN (CNIL, 2026).

Napastnik dotarł do narzędzia do zarządzania abonentami przez VPN Free Mobile, którego uwierzytelnianie CNIL uznała za „niewystarczająco odporne”, wytykając brak uwierzytelniania urządzenia i brak MFA dla użytkowników. Drugi zarzut: firma nie wdrożyła wystarczających środków wykrywania podejrzanej aktywności ani na tym VPN-ie, ani w sieci wewnętrznej, ani w samym narzędziu. Trzymanie logów to jeszcze nie zabezpieczenie.

Osobnym problemem był okres przechowywania danych. Ujawniono 19,46 miliona umów mobilnych, a aktywnych abonentów mobilnych było na 31 grudnia 2024 około 15,51 miliona. Te wielkości różnią się o blisko cztery miliony, ale dotyczą różnych jednostek i dat. Nie pozwalają policzyć byłych klientów objętych wyciekiem.

Free Mobile naruszyło osobno art. 5 ust. 1 lit. e, trzymając ponad piętnaście milionów zakończonych umów dłużej niż pięć lat, a trzy miliony dłużej niż dziesięć. Zbyt długie przechowywanie danych zwiększyło liczbę rekordów narażonych na ujawnienie.

Dostęp trwał od 28 września do 22 października 2024, a CNIL odnotowuje, że firmę zaalarmował 21 października napastnik, który był już w jej systemach. Free zgłosiło naruszenie do CNIL w wymaganych 72 godzinach, ale CNIL stwierdziła też naruszenie art. 34, bo zdaniem organu treść e-maila nie pozwoliła milionom poszkodowanych rozwiać wątpliwości co do własnej sytuacji. Kary: 27 mln euro dla FREE MOBILE, 15 mln euro dla FREE.

free.fr wystawia dziś security.txt podpisany PGP, sprawdzony 12 sierpnia 2026: kanoniczny URL, dwa kontakty, data Expires, odcisk klucza OpenPGP. Brakuje linii Policy:, więc sam plik nie wskazuje zakresu ani klauzuli safe harbor. Nie dowodzi to, że firma nie opublikowała ich w innym miejscu. Sam adres skrzynki nie wyjaśnia zasad testów ani obsługi raportów.

Tea: znalazcą był 4chan, a poprawka przyszła po publikacji

Tea Dating Advice potwierdziło dostęp do 72 000 zdjęć, w tym 13 000 selfie weryfikacyjnych i skanów dokumentów tożsamości (NBC News, 2025); reszta pochodziła z postów, komentarzy i wiadomości, a ucierpiały wyłącznie użytkowniczki zarejestrowane przed lutym 2024 (TechCrunch, 2025).

Zawiadomienie złożone prokuratorowi generalnemu Kalifornii jest węższe. Mowa w nim o nieuprawnionym dostępie 24 lipca 2025 lub w okolicach tej daty do zasobu z rekordami weryfikacyjnymi, z przesłankami wskazującymi na dostęp do „większości lub prawdopodobnie wszystkich”, co ujawniło imiona i nazwiska, daty urodzenia oraz numery prawa jazdy i paszportów.

Przyczyna źródłowa mieści się w jednym zdaniu, które 404 Media zacytowało z wpisu na 4chanie: „Żadnego uwierzytelniania, w ogóle nic. To publiczny bucket”. Żadnych danych logowania, żadnego łańcucha exploitów, sam adres URL. Potem druga luka, baza Firestore z wiadomościami prywatnymi, którą mógł odczytać dowolny zalogowany użytkownik Tea. 404 Media pisało o ponad 1,1 miliona wiadomości, zweryfikowanych na próbce; Tea nigdy nie potwierdziło liczby, mówiąc tylko, że sięgnięto po część wiadomości.

Informacje o obu lukach dotarły do opinii publicznej różnymi kanałami. Pierwsza trafiła na 4chana w czwartkowy wieczór, a zawiadomienie użytkowniczek wysłano 28 sierpnia 2025, czyli 35 dni później według kalifornijskiego rejestru.

Druga trafiła do dziennikarza. Niezależny badacz Kasra Rahjerdi znalazł bazę wiadomości, zrezygnował z publikacji i przekazał ustalenia za pośrednictwem 404 Media oraz samemu Tea, bo to był kanał, który działał. Tea wyłączyło wiadomości prywatne dwa dni później, już po publikacji. Nie opublikowano informacji o działaniach organu nadzorczego. Nie wiadomo więc, czy prowadzi postępowanie.

Pięć przypadków obok siebie

Co łączy tę piątkę

Jeden dostawca, tysiące firm ponoszących skutki (3 z 5). MyDr przetwarza dane dla tysięcy przychodni, Change Healthcare obsługuje dużą część amerykańskich rozliczeń medycznych, Drift działa jako aplikacja w środowiskach Salesforce setek innych firm. We wszystkich trzech przypadkach zaatakowano jeden podmiot, a ucierpieli klienci zupełnie innych. Przychodnie będące administratorami muszą ustalić, czy naruszenie podlega zgłoszeniu i kiedy uzyskały o nim wiedzę. Termin z art. 33 RODO wynosi co do zasady 72 godziny od tego momentu; nie zaczyna się automatycznie w dniu publikacji prasowej.

Okres przechowywania danych wymaga osobnej oceny. Free to przypadek udowodniony przez regulatora. Tea to rozjazd między obietnicą a praktyką: polityka prywatności mówiła, że selfie weryfikacyjne są kasowane zaraz po użyciu, a 13 000 z nich leżało w publicznym buckecie. W MyDr określenie danych jako archiwalnych nie wyjaśnia ani podstawy dalszego przechowywania, ani miejsca, z którego je pozyskano. Sam wiek dokumentacji medycznej nie dowodzi, że należało ją już usunąć.

Powiadomienie przyszło, ale nie od życzliwego znalazcy (4 z 5). MyDr: napastnicy napisali do prezesa. Free: włamywacz przerwał dwadzieścia trzy dni ciszy. Tea: 4chan, potem dziennikarz. Change Healthcare: samo zaszyfrowanie danych. Salesloft: nie wiadomo. Dane Mandianta pokazują, że informacje od podmiotów zewnętrznych są częstym sposobem wykrycia incydentu.

Dane, których zmiana jest trudna lub niemożliwa. Hasło, klucz API czy token OAuth wymienisz; Cloudflare wymienił 104 w tydzień. Daty urodzenia nie zmienisz, a zmiana numeru PESEL jest możliwa tylko w określonych sytuacjach. Numer rachunku lub dokumentu może się zmienić, ale wymaga innych działań niż rotacja hasła. Oficjalne zalecenia dla obywateli sprowadzają się dziś do zastrzeżenia numeru PESEL w mObywatelu i czekania, aż napisze do ciebie przychodnia. Ograniczaj przechowywanie do potrzebnego i wymaganego okresu oraz zabezpieczaj archiwalne rekordy.

Odziedziczony zasób (2 z 5). UnitedHealth domknął przejęcie Change Healthcare w październiku 2022, a niezabezpieczona brama w lutym 2024 wciąż figurowała na liście do migracji. MyDr przejęto w styczniu 2023, a jedyny w grupie plik security.txt (RFC 9116) leży pod inną marką i z innym adresem kontaktowym. Po przejęciu trzeba osobno sprawdzić konta, infrastrukturę i publiczne kanały kontaktowe.

Dostępność i zakres kanałów zgłoszeń były różne. Change Healthcare miało politykę ograniczającą testy, Free publikowało adres kontaktowy, a w pozostałych przypadkach przegląd nie wykazał pełnego publicznego programu. Nie można z tego wyciągnąć wniosku, że we wszystkich pięciu firmach ktoś bezskutecznie próbował zgłosić lukę.

Co kanał realnie daje, najlepiej ujął Verizon, pisząc o odsłoniętych zasobach danych: „najczęściej odkrywają je badacze bezpieczeństwa, którzy potem próbują kogoś powiadomić, o ile zdołają ustalić, czyje to dane. Nie wiemy natomiast, jak często te same dane napotykają inni, mniej obywatelsko nastawieni ludzie, kopiują je i po cichu znikają” (Verizon 2026 DBIR, 2026). Bucket Tea to ten akapit z dopisaną nazwą.

Bez kanału opcje, jakie zostają znalazcy, niosą dla niego realne ryzyko. Studenci i wykładowca z Malty w październiku 2022 napisali do firmy o podatnościach. Trzy tygodnie później do ich mieszkań weszła uzbrojona policja, a ułaskawienie dostali dopiero w lipcu 2025.

Jeśli raporty trafiają przez ogólną pomoc techniczną, ustal, kto i w jakim czasie przekazuje je zespołowi bezpieczeństwa. Więcej w tekście o safe harbor i groźbach prawnych wobec badaczy bezpieczeństwa.

Gdzie prawo wymaga VDP

Zakres i terminy różnią się między przepisami.

Unijny Cyber Resilience Act (rozporządzenie 2024/2847). Załącznik I część II pkt 5 wymaga od producentów produktów z elementami cyfrowymi, by „wprowadzili i egzekwowali politykę skoordynowanego ujawniania podatności”. Zwróć uwagę na czasownik: sama opublikowana strona tego nie spełnia. Zegar z art. 14 (24 godziny na wczesne ostrzeżenie, 72 na powiadomienie, 14 dni od udostępnienia środka naprawczego na raport końcowy przy aktywnie wykorzystywanych podatnościach) obowiązuje od 11 września 2026, a główne obowiązki rozporządzenia od 11 grudnia 2027. Wiąże producentów wprowadzających produkty na rynek unijny, więc firma działająca wyłącznie w modelu SaaS zwykle jest poza zakresem. Szczegóły w naszym omówieniu obowiązków ujawniania z CRA.

NIS2 (dyrektywa 2022/2555). Art. 12 wiąże państwa członkowskie i ENISA, a nie pojedyncze firmy. Wdrażająca ją nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (KSC) weszła w życie 3 kwietnia 2026, jakieś siedemnaście miesięcy po unijnym terminie, a rejestracja podmiotów ma nastąpić do 3 października 2026. Incydent MyDr wypada dokładnie w tym czasie, zanim zaczną obowiązywać terminy zgodności i zanim ruszą kary.

Brytyjska PSTI (SI 2023/1007). Egzekwowana od 29 kwietnia 2024 dla produktów z łącznością. Załącznik 1 wymaga opublikowanego kontaktu oraz informacji, kiedy zgłaszający dostanie potwierdzenie i aktualizacje statusu, dostępnej bez wcześniejszej prośby, bezpłatnie i bez pytania go o dane osobowe. Ten ostatni warunek wyklucza formularze wymagające podania danych i strony kontaktowe schowane za logowaniem.

CISA BOD 20-01. Od 2020 obowiązkowa dla amerykańskich federalnych agencji cywilnych: polityka pod sztywną ścieżką /vulnerability-disclosure-policy, z podanym zakresem, dozwolonymi testami i jasnym zapisem, że zgłoszenia mogą być anonimowe. Platforma VDP prowadzona przez CISA odnotowała ponad 12 000 zgłoszeń w 51 programach agencyjnych łącznie do 2023 roku, z czego ponad 2400 uznano za zasadne.

Czego nikt nie wymaga. NIS2 nie każe firmom prowadzić VDP, PCI DSS 4.0 też nie; wytyczne PCI SSC mówią tylko, że programy ujawniania „mogą pomóc” przy wymaganiach 6.3.3 i 12.10.1. W amerykańskich zamówieniach federalnych nie ma obowiązku wynikającego z FAR. Miałby go wprowadzić projekt ustawy H.R. 872, przyjęty przez Izbę Reprezentantów 3 marca 2025 i na 12 sierpnia 2026 wciąż nieuchwalony.

Rachunek nie czeka na przepisy. IBM wyliczył, że w 2026 średni globalny koszt naruszenia sięgnął rekordowych 4,99 mln dolarów, o 12% więcej niż rok wcześniej (IBM Cost of a Data Breach 2026). HackerOne wypłacił 81 mln dolarów nagród w 1950 programach w roku zakończonym 30 czerwca 2025, ale 51 mln z tego zgarnęła setka największych programów, co daje średnio około 16 000 dolarów wypłat dla pozostałych programów. Ta średnia nie opisuje typowego budżetu ani kosztów pracy zespołu; program bez nagród nadal wymaga obsługi.

Publikowanie pliku security.txt nadal nie jest powszechne. Opublikowane w recenzowanym czasopiśmie badanie listy Tranco znalazło security.txt w 34,0% stu największych domen, ale tylko w 1,0% pierwszego miliona (styczeń 2023, Hilbig i in., ACM DTRAP). Do stycznia 2025 udział w pierwszym milionie urósł do zaledwie 1,25%, a zgodnych z RFC było 44% istniejących plików (URIports, 2025).

Co opublikować w tym tygodniu

Nic z tego nie wymaga budżetu na nagrody ani umowy z platformą. Przygotuj co najmniej:

1. Plik security.txt zgodny z RFC 9116 z działającym Contact:, datą Expires: i linią Policy:. Expires jest obowiązkowe i to na takich detalach wykłada się większość opublikowanych plików.
2. Stronę z polityką, która prostym językiem opisuje zakres, dozwolone testy i safe harbor. Spółka matka Change Healthcare zakazała akurat tego skanowania, którego znalazca by potrzebował; plik Free wskazuje skrzynkę, lecz nie odsyła do polityki.
3. Zobowiązanie do potwierdzenia zgłoszenia. Napisz, jak szybko potwierdzisz odbiór, uwzględniając przepisy właściwe dla twojego programu, i dotrzymuj tego terminu.
4. Konkretną osobę odpowiedzialną i kolejkę. Przypisz odpowiedzialność również za zgłoszenia trafiające do wspólnej skrzynki.
5. Oś czasu, którą da się wyeksportować. Kiedy regulator albo dziennikarz zapyta, co i kiedy wiedziałeś, „podeszliśmy do sprawy odpowiedzialnie” nie jest dowodem. Chronologia każdego zgłoszenia jest.

Wersja krok po kroku: jak uruchomić program ujawniania podatności.

Obsługa zgłoszeń bez budowania jej od zera

Oprócz publikacji kontaktu zaplanuj przegląd kolejki, zastępstwa i przypomnienia o terminach.

Moduł CSIRT w Kit pomaga prowadzić tę obsługę. Generuje security.txt i prowadzi publiczny portal zgłoszeń, obok którego widnieje twój zakres, więc cele w zakresie i poza zakresem są wypisane wprost, a nie pozostawione domysłom. Nowe zgłoszenia są sprawdzane względem tego zakresu, duplikaty odsiewane, a dalszą obsługę obejmują SLA z celami na potwierdzenie i na rozwiązanie według poziomu ważności. Dochodzi do tego śledzenie zagrożonych terminów, żeby zespół widział opóźnienia i mógł na nie reagować.

Badacze mają trwałe profile i karmę, co pozwala sprawdzić historię wcześniejszych zgłoszeń. Nagrody są opcjonalne: matryca poziomów ważności, głosowanie nad propozycjami, księga finansowa i przekazanie wypłaty są dostępne, jeśli prowadzisz program z nagrodami. Każde zgłoszenie ma oś czasu do eksportu.

Ograniczenia są tu tak samo istotne jak funkcje. Kit obsługuje zgłoszenia podatności. Ochrona urządzeń, segmentacja sieci, MFA i wykrywanie przejętych kont wymagają osobnych zabezpieczeń. Zespół musi też samodzielnie przygotować wymagane zgłoszenia do ENISA i zawiadomienia z art. 33 i 34 RODO. Na podstawie opisanych przypadków nie można ustalić, czy kanał w Kit pomógłby wykryć te ataki.

Te pięć przypadków nie ma jednej przyczyny. Pokazują jednak, dlaczego kanał zgłoszeń, kontrolę dostępu, monitoring i okres przechowywania danych trzeba traktować jako osobne zadania. VDP może wspierać komunikację, ale nie zastępuje pozostałych zabezpieczeń.