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ół, wymaga koordynacji wykraczającej poza procedury programu ujawniania podatności (VDP) jednej firmy. Skoordynowane ujawnianie z udziałem wielu stron wymaga uzgodnionego terminu publikacji i sposobu nadawania identyfikatorów CVE, a często i neutralnego koordynatora, bo żaden pojedynczy dostawca nie panuje nad harmonogramem. Procedury VDP często skupiają się jednak na jednej firmie i terminach liczonych od przyjęcia zgłoszenia.

W takim przypadku termin wspólnego ujawnienia może upłynąć, zanim minie twoje SLA. Poniżej wyjaśniamy, jak uzgodnić i śledzić oba terminy.

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.

Na liczbę dotkniętych produktów wpływa 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.”

Błąd w jednym API do konfiguracji proxy dotyczy zarówno iCloud Private Relay samego Apple jak i niezależnych przeglądarek na iOS nastawionych na ochronę prywatności. Apple jest tu dostawcą wspólnego silnika i właścicielem korzystającego z niego produktu, 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. Dowiedzenie się o luce z publicznego wpisu może zaszkodzić relacjom z badaczami.

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 uzgodnionego terminu publikacji i sposobu nadawania identyfikatorów 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). Obejmują cztery obszary (procesy i relacje, jasną komunikację, budowanie zaufania, ograniczanie narażenia na zagrożenia) i definiują pięć ról: znalazca, dostawca, koordynator, obrońca oraz użytkownicy/wdrażający.

Podatności we wspólnych komponentach

Produkty korzystają z kodu innych dostawców, więc naprawa podatności może wymagać współpracy z jego autorami. 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 opisuje przyczynę: „Wiele dzisiejszych produktów nie powstaje w jednej organizacji. Są składane z komponentów pochodzących od innych organizacji.”

Wyniki tego audytu pokazują, jak często firmy korzystają z podatnych komponentów. Zgłoszenie dotyczące takiej zależności może wymagać kontaktu z jej autorami i innymi dostawcami, którzy jej używają.

Dlaczego wspólnej zależności nie należy odrzucać bez sprawdzenia

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. Przy zgłoszeniu dotyczącym wspólnej zależności te powody wymagają uważnego sprawdzenia.

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 usuwa wpis z kolejki, ale nie usuwa zagrożenia ani odpowiedzialności za produkt. FIRST przestrzega też przed eskalacją prawną, która wywołuje „efekt mrożący wobec pożądanych badań nad bezpieczeństwem”. Więcej o tej dynamice w tekście o safe harbor i groźbach prawnych.

duplicate 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. Taka sprawa wymaga ustalenia, kto odpowiada za poprawkę i w jakim terminie. Samo powiązanie z innym zgłoszeniem nie wystarcza do jej zamknięcia.

informational może zaniżyć znaczenie zgłoszenia wymagającego naprawy. A not_reproducible to pułapka, w którą wpada się w najlepszej wierze, bo dostawca produktu korzystającego z podatnego komponentu może nie odtworzyć błędu poza tym komponentem.

Przydałaby się osobna relacja: powiązane zgłoszenie. 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 zwiększają liczbę zgłoszeń dotyczących zależności. O tej zmianie piszemy w tekście o AI i opłacalności triażu w VDP.

Jak uzgodnić datę embarga

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”.

Termin trzeba uzgodnić z uczestnikami, uwzględniając zasady ich programów.

Przy negocjacjach uwzględnij najkrótszy termin, który już obowiązuje uczestników:

Uwzględnij najwcześniejszy termin publikacji wynikający z zasad uczestników. Jeśli ktoś powiadomił listę distros, masz najwyżej 14 dni, cokolwiek mówi twoja własna polityka. Własna polityka 90 dni nie wydłuża 14-dniowego limitu innego uczestnika.

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 daje więcej czasu na poprawki, ale zwiększa też ryzyko przecieku.

Jedno CVE czy pięć? Uzgodnij sposób nadawania identyfikatorów

Obie konwencje funkcjonują, wybór zapada osobno w każdej sprawie i jest decyzją koordynacyjną, a nie kancelaryjną. Pomyłka wymusza później aktualizacje dokumentacji u dostawców korzystających z danego komponentu.

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 został odrzucony: „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 zgłoszeniach.

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 wiadomo, kto ma nadać identyfikator, 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ą.

Jeśli twój produkt korzysta z podatnego komponentu, twój rejestr musi przechowywać odwołanie do identyfikatora podatności w komponencie, 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 odpowiedzialny za wspólny komponent 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. VINCE pomaga znaleźć innych dostawców korzystających z podatnego komponentu.
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.

Skala może być znacznie większa. 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

Terrapin również dotyczył wielu produktów. Ujawnienie luki w protokole używanym przez blisko 29 niezależnych implementacji SSH przebiegało następująco:

• 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: powiadomienie listy distros wysłano dokładnie 7 dni przed publikacją, czyli w preferowanym przedziale tej listy, a nie na styk jej 14-dniowego limitu. Harmonogram uwzględniał więc zasady listy.

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.

Opisane embarga trwały od 46 do 216 dni. Wewnętrzne SLA nie zastępuje uzgodnienia daty wspólnego ujawnienia. W sprawie z wieloma stronami termin uzgadniacie wspólnie. Nie wynika on wyłącznie z twojej polityki.

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

Wewnętrzne SLA i wspólne embargo mogą wskazywać różne terminy.

Terminy wewnętrznego SLA liczone są od momentu, w którym zgłoszenie dotarło do ciebie. Csirt::Report::SlaTrackable w Kit wylicza każdy termin od submitted_at. Domyślne wartości to: 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. Panel może pokazywać zgłoszenie jako obsługiwane w terminie, choć brakuje poprawki i biuletynu, a użytkownicy dowiadują się o luce z cudzego wpisu.

SLA nie uwzględnia dwóch informacji: wcześniejszego zgłoszenia innemu dostawcy oraz daty publikacji wynegocjowanej przez uczestników sprawy.

To inna awaria niż spory o terminy i nagrody, które pojawiają się w programach dwustronnych. Tam spór dotyczy dotrzymania SLA. Tutaj nawet zgłoszenie obsłużone w ramach SLA może zostać naprawione po wspólnej publikacji.

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

Proponujemy osobny wpis łączący lokalne zgłoszenie z koordynowanym ujawnieniem.

Powiązane ujawnienie to wpis łączący zgłoszenie w twoim rejestrze z ujawnieniem prowadzonym gdzie indziej. Zawiera:

• 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 autora komponentu 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łę. Termin działania wyznacza wcześniejsza z tych dat.

Reszta to ponowne użycie tego, co już masz. Poziomy SLA w Kit opisują stan zgłoszenia (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 powiązania z synchronizacją statusów z systemami zewnętrznymi, a dokładnie tego wymaga biuletyn autora komponentu, 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 wyjaśnia zastosowanie: „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. Nie służy jednak do śledzenia koordynacji: lista odbiorców udostępnienia nie opisuje ich roli w sprawie.

Naturalnym miejscem na to jest etap triażu z AI. Gdy narzędzie wstępnej oceny 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.

Podobną potrzebę opisuje tekst 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.

Termin biegnie od uzyskania przez ciebie wiedzy o wykorzystywaniu podatności, niezależnie od uzgodnionego embarga. 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. Zapis obu dat pomaga odtworzyć przebieg sprawy. Dotrzymanie obowiązku zgłoszenia wymaga również potwierdzenia, kiedy trafiło ono do właściwego organu.

Jak obsłużyć zgłoszenie dotyczące kilku dostawców

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

1. Nie odrzucaj go bez sprawdzenia. 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 najwcześniejszy termin publikacji. Jeśli w odpowiedziach padło distros, twój limit to 14 dni. Jeśli CERT/CC, to 45. Zapisz tę datę.
4. Ustal, kto koordynuje sprawę. Jeśli koordynuje ją autor wspólnego komponentu, uzgodnij z nim datę dla swojego produktu. 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 uzgodniony termin publikacji. 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. Brak odpowiedzi może zostać opisany w publicznym ujawnieniu.

Zapisz, z którymi zgłoszeniami i dostawcami łączy się sprawa. Ustal wspólny termin publikacji i porównuj go z wewnętrznym SLA. Zespół powinien widzieć oba terminy przy zgłoszeniu.