Jeden błąd, pięciu dostawców: ujawnianie podatności z udziałem wielu stron

Podatność, która jednocześnie uderza w kilku niezależnych dostawców, zwykle przez wspólny silnik, bibliotekę albo protokół, nie przejdzie przez zwykły program ujawniania podatności (VDP). Skoordynowane ujawnianie z udziałem wielu stron wymaga wynegocjowanej daty embarga, uzgodnionej struktury CVE, a często i neutralnego koordynatora, bo żaden pojedynczy dostawca nie panuje nad harmonogramem. Tymczasem niemal każdy VDP działający dziś w praktyce zakłada dokładną odwrotność: jedna firma, jedno zgłoszenie, jeden zegar.

Zobaczmy, co się dzieje, gdy to założenie pada, który zegar naprawdę rządzi i dlaczego twój dashboard SLA potrafi świecić na zielono tego samego ranka, kiedy wspólna luka trafia do publicznej wiadomości.

Jeden błąd w silniku WebKit, wszystkie przeglądarki proxy na iOS

4 sierpnia 2026 roku badacze z Mysk opisali trzy zachowania silnika WebKit, które omijają skonfigurowane w przeglądarce proxy i wypuszczają na zewnątrz prawdziwy adres IP urządzenia albo jego resolwery DNS. Mechanizmy to zwyczajne funkcje platformy webowej: podpowiedzi <link rel="dns-prefetch">, w których „strona może umieścić w tych tagach unikalne dla każdego odwiedzającego nazwy hostów, a potem obserwować, jak zapytania docierają do jej własnego autorytatywnego serwera DNS z prawdziwej sieci odwiedzającego, a nie z sieci proxy”; WebAuthn Related Origin Requests, gdzie systemowa usługa poświadczeń pobiera https://<rpId>/.well-known/webauthn z pominięciem proxy; i WebTransport, który otwiera połączenia HTTP/3 QUIC prosto z urządzenia.

Przełomowy nie jest tu jednak szczegół techniczny, tylko polityka platformy. Jak ujmuje to sam opis: „Ponieważ zasady App Store firmy Apple wymagają, by każda przeglądarka na iOS korzystała z WebKit, podatna jest każda przeglądarka iOS używająca tego API do obsługi proxy, w tym wszystkie przeglądarki Tor na iOS oraz Psylo.”

Jedna przyczyna źródłowa w jednym API do konfiguracji proxy uderza naraz w iCloud Private Relay samego Apple i w każdą niepowiązaną z nim przeglądarkę nastawioną na prywatność, która trafia na iOS. Apple jest tu dostawcą silnika z góry łańcucha i właścicielem produktu na jego końcu, więc nawet odruchowe „eskalujemy wyżej i wracamy do pracy” nie rozstrzyga, kto prowadzi sprawę.

Warto też zobaczyć, czego w tym ujawnieniu nie ma. Brak CVE. Brak wspólnej daty embarga. Kontakt z dwiema dotkniętymi stronami: „Skontaktowaliśmy się z Tor Project i twórcami Onion Browser na iOS w sprawie tych problemów”.

To nie zarzut wobec badaczy, tylko obraz tego, co dzieje się domyślnie, gdy nikt nie prowadzi koordynacji. Każdy dotknięty dostawca dowiaduje się w innym momencie i z innego źródła, a część dowiaduje się z wpisu na blogu. Ta ostatnia pozycja kosztuje najwięcej.

Czym jest skoordynowane ujawnianie podatności z udziałem wielu stron?

Skoordynowane ujawnianie podatności z udziałem wielu stron (MPCVD) to proces dla podatności, która dotyka naraz kilku niezależnych dostawców, zwykle przez wspólny komponent, silnik albo protokół. W odróżnieniu od VDP jednego dostawcy wymaga wynegocjowanej daty embarga, uzgodnionej struktury CVE i koordynatora, bo żadna pojedyncza strona nie panuje nad harmonogramem.

Dokumentem referencyjnym są wytyczne FIRST, czyli Multi-Party Vulnerability Coordination and Disclosure guidelines (v1.1). Opierają się na czterech filarach (mocne procesy i relacje, jasna komunikacja, budowanie zaufania, ograniczanie ekspozycji) i definiują pięć ról: znalazca, dostawca, koordynator, obrońca oraz użytkownicy/wdrażający. Słownik większości programów VDP kończy się na dwóch pierwszych.

Dlaczego to dziś przypadek typowy, a nie egzotyczny

Większość podatności we współczesnym produkcie siedzi w kodzie, którego dostawca nie napisał i którego nie naprawi na własną rękę. Raport OSSRA 2026 firmy Black Duck, oparty na „analizie 947 komercyjnych baz kodu z 17 branż”, pokazuje:

• 87% audytowanych baz kodu zawierało co najmniej jedną podatność
• 78% zawierało podatności wysokiego ryzyka, w tym 44% z problemami o ryzyku krytycznym
• średnia liczba podatności w open source na jedną bazę kodu „więcej niż podwoiła się, rosnąc o 107% do średnio 581 podatności”
• 93% zawiera komponenty, w których od dwóch lat nie było żadnych prac rozwojowych

CERT Guide to Coordinated Vulnerability Disclosure nazywa przyczynę bez ceregieli: „Wiele dzisiejszych produktów nie powstaje w jednej organizacji. Są składane z komponentów pochodzących od innych organizacji.”

Przełóż te liczby na praktykę. Jeśli większość powierzchni ataku masz poskładaną, a nie napisaną, to większość twoich podatności ma z definicji wiele stron. Zgłoszenie dotyczące jednego dostawcy jest przypadkiem szczególnym, a twoje narzędzia powstały właśnie pod niego.

Cztery wyjścia z kolejki triażu i dlaczego trzy z nich są błędne

Otwórz dowolną kolejkę napływających zgłoszeń w VDP i spójrz na powody odrzucenia. Moduł CSIRT w Kit ma standardowy zestaw: out_of_scope, duplicate, informational, not_reproducible, spam, other i ai_slop. Każdy VDP ma jakąś wersję tej listy. Przy zgłoszeniu dotyczącym wspólnej zależności dwa najbardziej kuszące wyjścia są jednak błędne.

out_of_scope pasuje do sytuacji „to nie nasz zasób”. Nie pasuje do „to nasz produkt, tyle że przez cudzy kod”. Użytkownicy są narażeni tak czy inaczej, a zamknięcie zgłoszenia kasuje twój obowiązek, nie ruszając samego zagrożenia. Bywa też odbierane jako wrogi gest: filar zaufania u FIRST ostrzega, że eskalacja prawna wywołuje „efekt mrożący wobec pożądanych badań nad bezpieczeństwem”, a ciche zamknięcie zgłoszenia o wspólnej zależności leży na tej samej skali. Więcej o tej dynamice w tekście o safe harbor i groźbach prawnych.

duplicate działa dokładnie na odwrót, niż powinien. Dziś oznacza „ten sam błąd, już nam zgłoszony” i zamyka zgłoszenie. Przypadek wspólnej zależności mówi co innego: ta sama przyczyna źródłowa, ale w cudzym produkcie. To musi zostawić zgłoszenie otwarte, z drugim właścicielem i drugim harmonogramem.

informational po prostu je zakopuje. A not_reproducible to pułapka, w którą wpada się w najlepszej wierze, bo dostawca z końca łańcucha często naprawdę nie odtworzy w izolacji luki siedzącej wyżej.

Piątego wyjścia nie ma w żadnej popularnej taksonomii zgłoszeń: powiązane. Ta sama przyczyna źródłowa, inny dostawca, wspólny harmonogram, a odpowiedzialność nadal po twojej stronie. Znaczenie tej luki rośnie, bo badania wspierane przez AI wpychają do kolejek coraz więcej znalezisk z poziomu zależności. O tej zmianie piszemy w tekście o AI i opłacalności triażu w VDP.

Kto ustala datę embarga? Nikt, więc poznaj górne limity

Nie ma instytucji, która ustala daty embarga. FIRST celowo niczego nie narzuca: „Wobec braku wyraźnych dowodów na wcześniejsze publiczne ujawnienie (w tym aktywną eksploatację) uczestnicy powinni zapewnić dostawcom rozsądny okres embarga na zbadanie sprawy i przygotowanie poprawek”. Gdy w grę wchodzi kilku koordynatorów, „jeden z nich powinien zostać wybrany na prowadzącego”.

Datę więc się negocjuje. Negocjacja staje się wykonalna wtedy, gdy znasz twarde limity, którymi pozostali uczestnicy są już związani.

Z tej tabeli wynika jedna reguła i to ona rządzi ujawnianiem z udziałem wielu stron:

Obowiązuje embargo wyznaczone przez najkrótszy zegar, którym związany jest którykolwiek z uczestników. Jeśli ktoś w sprawie poszedł na distros, masz najwyżej 14 dni, cokolwiek mówi twoja własna polityka. Twoje ulubione 90 dni przestaje mieć znaczenie w chwili, gdy komuś innemu tyka 14-dniowy limit.

CERT Guide tłumaczy, skąd te limity w ogóle: „Im więcej stron bierze udział w sprawie i im dłużej trwa embargo, tym bardziej prawdopodobny staje się przeciek.” Dłuższe embargo nie jest bezpieczniejsze. Jest po prostu dłuższe.

Jedno CVE czy pięć? Decyzja o identyfikatorach, której nikt nie tłumaczy

Obie konwencje funkcjonują, wybór zapada osobno w każdej sprawie i jest decyzją koordynacyjną, a nie kancelaryjną. To najsłabiej udokumentowany fragment całego procesu, a pomyłka tutaj generuje pracę wszystkim, którzy są za tobą w łańcuchu.

Jedno CVE na lukę w protokole, wielu dostawców pod nim. Autorzy ataku KRACK ujęli tę logikę wprost: „Każdy identyfikator CVE odpowiada konkretnej realizacji ataku key reinstallation. Oznacza to, że każdy identyfikator CVE opisuje konkretną podatność protokołu, a więc każde pojedyncze CVE dotyczy wielu dostawców”. Dziesięć identyfikatorów opisywało lukę, nie produkty.

Jedno CVE na dotknięty produkt i bałagan z duplikatami, który potem następuje. W sprawie libwebp nadano drugi identyfikator dla samej biblioteki, choć istniał już jeden, opisujący błąd w przeglądarce z końca łańcucha. CVE-2023-5129 jest dziś formalnie martwe: „Ten identyfikator CVE został odrzucony lub wycofany przez swoją CVE Numbering Authority. Duplikat CVE-2023-4863.” W samej podatności nic się nie zmieniło. Zmienił się identyfikator, a przepiąć trzeba było każdy biuletyn bezpieczeństwa, każdą regułę skanera, każdy wpis w SBOM i każde odwołanie w ticketach.

Wariant mieszany, gdy wadliwy jest i protokół, i konkretne implementacje. Terrapin dostał CVE-2023-48795 na ogólną lukę protokołu, obok CVE-2023-46445 i CVE-2023-46446 na ataki dotyczące konkretnie AsyncSSH, plus CVE-2024-41909 dla Apache MINA SSHD.

Gdy nie widać oczywistego właściciela przydziału, polityka CERT/CC przewiduje, że w sprawach z wieloma dostawcami i niejasnymi kompetencjami organizacja nadaje CVE samodzielnie. Koordynacja ma pierwszeństwo przed czekaniem, aż CNA się dogadają.

Dla dostawcy z końca łańcucha wniosek jest drobny i bardzo konkretny: twój rejestr musi trzymać odwołanie do identyfikatora z góry łańcucha, które da się później podmienić, a nie ciąg znaków wklejony na sztywno w pole opisu.

Jak znaleźć pozostałych czterech dostawców

Trzy mechanizmy, od najmniej do najbardziej pracochłonnego.

1. security.txt (RFC 9116). Zwykły plik tekstowy pod https://example.com/.well-known/security.txt, z wymaganymi polami Contact i Expires oraz opcjonalnymi Acknowledgments, Canonical, Encryption, Hiring, Policy i Preferred-Languages. Opublikowany jako informacyjny RFC w kwietniu 2022 roku po to, żeby znalazca trafił do twojego kanału zgłoszeń bez zgadywania. To zarazem najtańszy sposób, żeby koordynator z góry łańcucha mógł znaleźć ciebie, a o tym kierunku zwykle się zapomina. Resztę tych podstaw opisuje tekst jak uruchomić VDP.
2. Koordynator. CERT/CC prowadzi VINCE (Vulnerability Information and Coordination Environment), obsługiwany przez Software Engineering Institute na CMU i finansowany przez CISA, gdzie dostawcy rejestrują kontakty i koordynują sprawy. To usankcjonowana odpowiedź na „nie wiem, kto jeszcze to u siebie dostarcza”.
3. Ręczny kontakt, partiami. Czyli to, co dzieje się najczęściej. Autorzy Terrapina odezwali się do blisko 29 implementacji SSH w dwóch turach i powiadomili CERT-Bund.

Ustaw oczekiwania na realnej liczbie. Notatka CERT o KRACK, VU#228519, ma tabelę dostawców, pod którą widnieje „View all 183 vendors”, z podziałem na podatnych, niepodatnych i sporą grupę o nieznanym statusie, od której nigdy nie przyszło żadne oświadczenie. W prawdziwej sprawie z wieloma stronami znaczna część dotkniętych dostawców nie odzywa się w ogóle.

Terrapin: jak wygląda dobrze poprowadzone ujawnianie z wieloma stronami

Ten sam kształt co sprawa WebKit, przeciwne wykonanie. Luka w protokole uderzająca w blisko 29 niezależnych implementacji SSH, koordynowana z rozmysłem:

• 2023-10-17 pierwszy kontakt z OpenSSH i autorem AsyncSSH
• 2023-11-17 pierwsza tura powiadomień, 17 implementacji, plus CERT-Bund
• 2023-11-21 druga tura, kolejnych 12
• 2023-12-11 powiadomienie listy distros
• 2023-12-18 publiczne ujawnienie

62 dni, cztery CVE, jedna data. Zwróć uwagę na dwa ostatnie punkty: na distros weszli dokładnie 7 dni przed publikacją, czyli w preferowanym przedziale tej listy, a nie na styk jej 14-dniowego limitu. Tak wygląda robienie tej arytmetyki na serio.

Rozpiętość realnych embarg jest duża. Cloudflare, Google i AWS przeprowadziły sprawę HTTP/2 Rapid Reset w około 46 dni, przy trwającej eksploatacji: od wykrycia 25 sierpnia 2023 roku do wpisu Google z 10 października 2023 roku. KRACK zajął rzędu 94 dni. Meltdown i Spectre zajęły 216 dni: Project Zero zgłosił sprawę Intelowi, AMD i ARM 1 czerwca 2017 roku, a opublikował 3 stycznia 2018 roku.

Od 46 do 216 dni. Żadne SLA nie obejmuje takiej rozpiętości i o to właśnie chodzi. W sprawie z wieloma stronami data jest danymi wejściowymi, a nie wynikiem twojej polityki.

Problem z zegarem: dlaczego SLA świeci na zielono, choć jesteś spóźniony

Ten scenariusz awarii nie został dotąd nigdzie spisany, a wynika z arytmetyki, nie z zaniedbania.

Zegary SLA dla jednej strony liczą się od momentu, w którym zgłoszenie dotarło do ciebie. Csirt::Report::SlaTrackable w Kit wylicza każdy termin od submitted_at i jest to rozwiązanie poprawne oraz standardowe. Domyślne wartości są równie standardowe: 72 godziny na potwierdzenie, a potem cele rozwiązania: 24 godziny dla super critical, 72 dla critical, 168 dla high, 336 dla medium i 720 dla low lub informational.

Zestaw te wartości z limitami embarga.

336 godzin to dokładnie 14 dni, czyli maksymalne embargo akceptowane przez listę distros. 720 godzin to 30 dni, ponad dwa razy więcej niż jakiekolwiek embargo, które uszanują dystrybucje Linuksa.

Błąd we wspólnej zależności, któremu w triażu nadano poziom medium lub niższy, domyślnie mieści się jeszcze spokojnie w swoim SLA tego ranka, kiedy embargo wygasa i luka trafia do publicznej wiadomości. Dashboard świeci na zielono. Zgłoszenie jest w terminie. A poprawki nie ma, biuletynu nikt nie napisał, i użytkownicy dowiadują się z cudzego wpisu na blogu.

Zepsute są naraz dwie rzeczy. Zły jest punkt odniesienia, bo obowiązujący zegar ruszył wcześniej, w chwili gdy znalazca zgłosił sprawę innemu dostawcy. Zła jest też data końcowa, bo ustalono ją w negocjacjach między stronami, których być może nawet nie poznałeś.

To inna awaria niż problemy ze sprawiedliwością SLA, które pojawiają się w programach dwustronnych. Tam sporne jest to, czy zegar został dotrzymany. Tutaj zegar dotrzymano wzorowo, a i tak wyszło po czasie.

Czego naprawdę potrzebuje twój rejestr: wpis o powiązanym ujawnieniu

Naprawa sprowadza się do jednego wpisu, a większość narzędzi do VDP ma już wszystkie klocki, żeby go zbudować.

Powiązane ujawnienie to pełnoprawne połączenie między zgłoszeniem w twoim rejestrze a ujawnieniem prowadzonym gdzie indziej. Niesie ze sobą:

• Rolę. upstream, downstream albo peer. To pole zamienia „zgłoszenie nie do zaklasyfikowania” w „sprawę, w której mam określoną pozycję”.
• Zewnętrzne odwołanie. Identyfikator CVE albo adres biuletynu z góry łańcucha oraz sygnaturę sprawy u koordynatora, na przykład numer VU w CERT/CC lub wątek na distros.
• Dwie daty, nie jedną. upstream_reported_at, czyli faktyczny start zegara, oraz embargo_at, czyli uzgodnioną datę publikacji.
• Jedną regułę. Rządzi ta z dat, która wygasa pierwsza. Ta jedna linijka to cała naprawa.

Reszta to ponowne użycie tego, co już masz. Poziomy SLA w Kit mówią właściwym językiem (breached, at_risk, on_track, no_sla), brakuje im tylko drugiego warunku do sprawdzania, żeby zgłoszenie pokazywało „potwierdzenie: w terminie, embargo: 3 dni” zamiast samotnego zielonego ptaszka. Csirt::TrackerIssue już teraz utrzymuje zarządzane, zsynchronizowane statusem powiązania z systemami zewnętrznymi, a dokładnie tego wymaga biuletyn z góry łańcucha, który może później zostać odrzucony, jak stało się z CVE-2023-5129. A Csirt::Report::Shareable już generuje wygasające i chronione adresem e-mail udostępnienia z zamaskowanymi danymi. Komentarz w kodzie zdradza całą rzecz: „odrzucenie (»poza zakresem, to błąd dostawcy z góry łańcucha«) to dokładnie ten moment, w którym zespół przesyła zamaskowaną kopię temu dostawcy”. Kanał do partnerskiego dostawcy jest więc już zbudowany. Po prostu nie jest modelowany jako koordynacja, więc lista odbiorców zostaje nieśledzonym przekazaniem maila zamiast częścią akt sprawy.

Naturalnym miejscem na to jest etap triażu z AI. Gdy narzędzie pierwszego rzutu oznacza zgłoszenie jako „to wygląda na błąd zależności, nie nasz”, właściwym wynikiem jest skierowanie sprawy dalej, a nie jej zamknięcie.

To rozwinięcie tezy z tekstu o cichych łatkach: ujawnienie jest śledzonym etapem, a nie stanem końcowym. Przypadek wielu stron dokłada jedną rzecz. Ten etap ma czasem czterech innych uczestników, a twój rejestr musi znać ich nazwy.

Regulator nie czeka na embargo

Zgodnie z unijnym Cyber Resilience Act od 11 września 2026 roku producenci muszą zgłaszać aktywnie wykorzystywane podatności przez wspólną platformę zgłoszeniową ENISA: wczesne ostrzeżenie w ciągu 24 godzin, pełne powiadomienie w ciągu 72 godzin i raport końcowy w ciągu 14 dni od zastosowania środka naprawczego.

Ten zegar jest przypięty do twojej wiedzy, a nie do embarga uzgodnionego w branży. Jeśli trzeciego dnia 90-dniowego embarga dowiesz się, że wspólna luka jest wykorzystywana, twój 24-godzinny obowiązek startuje natychmiast. Żaden zapis w porozumieniu o embargu tego nie usprawiedliwi i żaden inny uczestnik nie zrzeknie się go w twoim imieniu. Cały obowiązek opisuje nasz przewodnik po unijnym Cyber Resilience Act, tutaj chodzi wyłącznie o nazwanie kolizji. Wpis koordynacyjny z obiema datami jest przy okazji dowodem na to, że dotrzymałeś terminu regulatora, kiedy branżowe embargo jeszcze trwało.

Runbook na zgłoszenie, które nie jest tylko twoje

Jeśli ze zgłoszenia wynika, że luka jest wspólna, przejdź tę listę, zanim tkniesz powód odrzucenia.

1. Nie zamykaj go. Ani przez out_of_scope, ani przez duplicate. Oznacz je jako powiązane i zostaw otwarte.
2. Zadaj znalazcy trzy pytania. Komu jeszcze o tym powiedział, kiedy to zrobił i czy sprawa trafiła na jakąkolwiek listę mailingową albo do koordynatora?
3. Ustal najkrótszy zegar, który już tyka. Jeśli w odpowiedziach padło distros, twój limit to 14 dni. Jeśli CERT/CC, to 45. Zapisz tę datę.
4. Zdecyduj, czy prowadzisz sprawę, czy idziesz za kimś. Jeśli koordynuje ją dostawca z góry łańcucha, jesteś na końcu łańcucha i przyjmujesz jego datę. Jeśli nie koordynuje jej nikt, zgłoś ją koordynatorowi, zamiast wcielać się w tę rolę samemu.
5. Uzgodnij strukturę identyfikatorów wcześnie. Jedno CVE na lukę czy po jednym na produkt? Zapytaj, zanim ktoś zacznie pisać biuletyny, nie po fakcie.
6. Opublikuj security.txt. Żeby następny koordynator znalazł cię bez przeszukiwania LinkedIna.
7. Zapisz na zgłoszeniu obie daty. Datę przyjęcia dla twojego SLA i datę embarga dla rzeczywistości. Pokazuj obie.
8. Przyjmij, że zegar CRA jest niezależny. Jeśli eksploatacja jest potwierdzona, 24-godzinny obowiązek biegnie bez względu na embargo.
9. Śledź udostępnienia dla innych dostawców. Jeśli przesyłasz komuś kopię z zamaskowanymi danymi, ten odbiorca jest częścią sprawy, a nie przypisem w czyimś folderze „wysłane”.
10. Licz się z ciszą. Duża część dostawców, do których napiszesz, nigdy nie odpowie. CERT Guide radzi zakładać dobrą wolę i wciąż próbować odnowić kontakt. Bycie tym dostawcą, który milknie, kończy się wymienieniem z nazwy w cudzym wpisie o ujawnieniu.

Nic z tego nie wymaga dwunastoosobowego zespołu PSIRT. Wymaga rejestru, który potrafi wyrazić jedno zdanie, a tego twoje obecne narzędzia najpewniej nie umieją: to zgłoszenie jest jednym z pięciu. Dodaj powiązanie, dodaj zegar embarga, zastosuj regułę najkrótszego zegara, a zgłoszenie przestanie być błędem nie do zaklasyfikowania i stanie się sprawą, którą da się poprowadzić.