Skoordynowane ujawnianie podatności: jak prowadzić program ujawniania

Czym jest skoordynowane ujawnianie podatności?

Skoordynowane ujawnianie podatności (CVD) to praktyka poufnej obsługi nowo znalezionej podatności między znalazcą a dostawcą do czasu udostępnienia poprawki lub środka łagodzącego, a następnie jej opublikowania. CERT Guide to Coordinated Vulnerability Disclosure opisuje je jako zbieranie informacji od znalazców podatności, koordynowanie wymiany tych informacji między właściwymi interesariuszami oraz ujawnianie podatności i środków łagodzących, także publicznie.

Dla dostawcy produktu CVD ma dwie części. Część zewnętrzna, czyli przyjmowanie zgłoszeń i publikowanie biuletynów, jest tematem tej strony. Część wewnętrzna, czyli weryfikacja, naprawa i wydanie, to cykl życia zarządzania podatnościami. Obie prowadzi zwykle PSIRT.

CVD, pełne ujawnienie i bug bounty

	Skoordynowane ujawnianie	Pełne ujawnienie	Bug bounty
Czym jest	Poufne zgłoszenie, poprawka, a potem publikacja w uzgodnionym terminie	Znalazca natychmiast publikuje szczegóły, z powiadomieniem dostawcy lub bez niego	Program płacący za prawidłowe znaleziska
Kto decyduje o terminie	Dostawca i znalazca wspólnie, czasem z koordynatorem	Znalazca	Warunki programu, zwykle zgodne z CVD
Ryzyko dla użytkowników	Najniższe: szczegóły stają się publiczne, gdy istnieje poprawka lub upłynie termin	Najwyższe: napastnicy dowiadują się o podatności razem z obrońcami	Jak w CVD
Koszt	Czas pracowników na triage i odpowiedź	Nieplanowana praca w trybie awaryjnym	Czas pracowników plus nagrody i często opłaty za platformę

Bug bounty nie jest alternatywą dla programu ujawniania podatności (VDP). To zachęta dodana do takiego programu. Każdy dostawca potrzebuje sposobu, w jaki każdy może zgłosić podatność; bug bounty decyduje tylko o tym, czy niektóre zgłoszenia będą płatne.

Co zawiera polityka ujawniania podatności

Polityka ujawniania podatności to publiczny dokument określający warunki Państwa programu. ISO/IEC 29147, międzynarodowy standard ujawniania podatności, wymaga jednego elementu, preferowanego sposobu kontaktu, i zaleca kilka kolejnych. Pełna polityka obejmuje:

• Jak zgłaszać. Dedykowany adres lub formularz internetowy oraz sposób bezpiecznego przesłania wrażliwych szczegółów, na przykład opublikowany klucz szyfrujący.
• Co zawrzeć w zgłoszeniu. Dotknięty produkt i wersję, kroki odtworzenia, skutki i sposób kontaktu ze zgłaszającym.
• Zakres. Które produkty, wersje i usługi są objęte, a które metody testowania są niedozwolone, takie jak odmowa usługi lub dostęp do danych innych użytkowników.
• Bezpieczna przystań. Zobowiązanie do niepodejmowania kroków prawnych wobec badań prowadzonych w dobrej wierze zgodnie z polityką.
• Czego mogą oczekiwać zgłaszający. Kiedy potwierdzą Państwo zgłoszenie, jak będą ich Państwo informować i jaki jest docelowy czas naprawy.
• Harmonogram ujawnienia. Kiedy szczegóły staną się publiczne i co się stanie, jeśli poprawka potrwa dłużej.
• Publikacja. Gdzie pojawiają się biuletyny i czy nadają Państwo identyfikatory CVE.
• Uznanie. Czy i jak wskazują Państwo zgłaszających oraz czy wypłacają nagrody.

Polityka powinna być krótka i konkretna. Zgłaszający czytają ją, aby zdecydować, czy zgłoszenie do Państwa jest bezpieczne i warte wysiłku.

security.txt: łatwy do znalezienia kontakt

Polityka działa tylko wtedy, gdy badacze mogą ją znaleźć. RFC 9116, opublikowany w kwietniu 2022, definiuje security.txt, mały plik tekstowy udostępniany pod adresem /.well-known/security.txt przez HTTPS.

Contact: mailto:[email protected]
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• Wymagane: Contact i Expires. RFC 9116 zaleca datę wygaśnięcia za mniej niż rok, aby plik się nie zdezaktualizował.
• Opcjonalne: Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical i Hiring.
• Podpisywanie: RFC zaleca podpis OpenPGP w postaci czystego tekstu, z ustawionym Canonical.

Warto ustawić przypomnienie w kalendarzu przed datą Expires. Wygasły plik mówi badaczom, że nikt go nie czyta.

Embarga i harmonogramy ujawniania

Embargo to okres między zgłoszeniem a publikacją. Najczęściej cytowaną normą jest polityka Google Project Zero: dostawcy mają 90 dni na udostępnienie łatki, a szczegóły są publikowane 30 dni po jej wydaniu. Dostawca, który potrzebuje nieco więcej czasu, może poprosić o okres karencji, łącznie maksymalnie do 104 dni. Gdy podatność jest już wykorzystywana w rzeczywistych atakach, termin skraca się do 7 dni.

Państwa własna polityka może określać inne warunki i wielu zgłaszających je akceptuje. Ważne, aby harmonogram był spisany, aby informowali Państwo zgłaszających i prosili o przedłużenie przed upływem terminu, a nie po nim. Biuletyn opublikowany zgodnie z planem, ze środkiem łagodzącym, jest lepszy niż milczenie.

Identyfikatory CVE i CNA

Większość biuletynów ma identyfikator CVE, dzięki czemu klienci i narzędzia mogą je dopasować. Identyfikatory nadają CVE Numbering Authorities (CNA), organizacje upoważnione do ich nadawania w uzgodnionym zakresie. Wielu dostawców oprogramowania jest CNA dla własnych produktów, co pozwala im nadawać identyfikator i publikować rekord we własnym terminie. Jeśli nie są Państwo CNA, identyfikator nadaje CNA, którego zakres obejmuje Państwa produkt, lub CNA of Last Resort.

Koordynacja wielu stron

Niektóre podatności dotyczą jednocześnie wielu dostawców: błąd w szeroko stosowanej bibliotece, protokole lub układzie. Wtedy koordynator pomaga dotrzeć do każdego dotkniętego dostawcy i uzgodnić jedną datę publikacji.

• CERT/CC, działający w Software Engineering Institute na Carnegie Mellon University, koordynuje sprawy obejmujące wielu dostawców i publikuje przewodnik CERT po CVD.
• Krajowe zespoły CSIRT w UE. Zgodnie z NIS2 każde państwo członkowskie wyznacza CSIRT jako koordynatora CVD. Działa on jako zaufany pośrednik między zgłaszającymi a dostawcami, negocjuje terminy ujawnienia, zajmuje się podatnościami dotyczącymi kilku podmiotów i przyjmuje zgłoszenia anonimowe.
• European Vulnerability Database (EUVD) agencji ENISA, utworzona na mocy NIS2, działa od maja 2025 i publikuje informacje o publicznie znanych podatnościach, w tym o podatnościach koordynowanych w UE.

ISO/IEC 29147 obejmuje też przypadek, w którym występują Państwo w obu rolach: jako dostawca, którego produkt zawiera podatny komponent innego dostawcy, muszą Państwo zgłosić to temu dostawcy i poinformować własnych klientów.

Po otrzymaniu zgłoszenia

1. Potwierdzić w terminie obiecanym w polityce i przekazać zgłaszającemu identyfikator śledzenia.
2. Zweryfikować zgłoszenie i ocenić dotkliwość problemu.
3. Ustalić, czego dotyczy: każdy produkt, wydanie i wspieraną gałąź zawierające podatny kod lub komponent.
4. Naprawić i wydać dla każdej dotkniętej gałęzi, informując zgłaszającego na bieżąco.
5. Opublikować biuletyn z identyfikatorem CVE, dotkniętymi wersjami, naprawą i wskazaniem zgłaszającego. Biuletyny czytelne maszynowo używają CSAF, a VEX mówi klientom, których produktów to nie dotyczy.

Pełny proces, z rolami, terminami i metrykami, opisuje cykl życia zarządzania podatnościami.

Regulacje czynią polityki CVD obowiązkowymi

Unijny Cyber Resilience Act wymaga od producentów wdrożenia i egzekwowania polityki skoordynowanego ujawniania podatności oraz podania adresu kontaktowego do zgłaszania podatności, także w komponentach zewnętrznych (załącznik I, część II). Obowiązki te stosuje się od 11 grudnia 2027; zob. czego wymaga CRA. Art. 21 ust. 2 lit. e NIS2 wymienia obsługę i ujawnianie podatności wśród środków bezpieczeństwa, które muszą stosować podmioty kluczowe i ważne. W USA Executive Order 14028 nakazał opracowanie wytycznych dla łańcucha dostaw oprogramowania, obejmujących udział w programie ujawniania podatności.

Zgłoszenie jest tylko tak użyteczne jak Państwa zapis tego, co dostarczono

Każde zgłoszenie rodzi to samo pierwsze pytanie: które z naszych wydań to zawierają? CRACI uruchamia Państwa buildy GitHub Actions na własnych runnerach i rejestruje pakiety faktycznie pobrane przez każde zadanie, łącznie z zależnościami przechodnimi, pakietami przywróconymi z cache CI i zależnościami, których nie wymienia żaden lockfile. Historia buildów pokazuje, które wcześniejsze buildy zawierały podatną zależność, dzięki czemu znają Państwo okres narażenia, a widok inwentarza pokazuje, które wersje oprogramowania są wdrożone w których produktach.

CRACI agreguje SBOM-y z wielu buildów i repozytoriów i stale ponownie ocenia monitorowane SBOM-y, więc gdy podatność w komponencie open source zostanie opublikowana, widzą Państwo wszystkie miejsca, w których występuje. Zespoły bezpieczeństwa wykonują triage znalezisk i przekazują je zespołom odpowiedzialnym za poprawkę, CRACI obsługuje VEX, a bramki polityk mogą blokować buildy zawierające określony CVE po jego naprawieniu. Zob. śledzenie podatności.

Skoordynowane ujawnianie podatności: najczęściej zadawane pytania

Czym jest skoordynowane ujawnianie podatności?

Skoordynowane ujawnianie podatności (CVD) to proces, w którym osoba znajdująca podatność zgłasza ją poufnie dostawcy, dostawca ją naprawia, a szczegóły są publikowane, gdy użytkownicy mogą się chronić, zwykle w terminie uzgodnionym przez strony. Koordynatorzy, tacy jak CERT/CC lub krajowy CSIRT, wkraczają, gdy z dostawcą nie ma kontaktu lub gdy problem dotyczy kilku dostawców.

Czym VDP różni się od bug bounty?

Program ujawniania podatności (VDP) mówi każdemu, jak zgłosić podatność i czego się spodziewać, bez płacenia za znaleziska. Bug bounty płaci badaczom za prawidłowe znaleziska, zwykle w określonym zakresie i często przez platformę bug bounty. Większość organizacji zaczyna od VDP; bug bounty to opcjonalny dodatek do niego, a nie zamiennik.

Co powinna zawierać polityka ujawniania podatności?

Co najmniej sposób zgłaszania: adres kontaktowy lub formularz. ISO/IEC 29147 zaleca też określenie, co powinno zawierać zgłoszenie, jak bezpiecznie się komunikować, czego i kiedy mogą oczekiwać zgłaszający, co jest objęte zakresem, jak publikują Państwo biuletyny i jak wskazują zgłaszających. Większość polityk dodaje oświadczenie o bezpiecznej przystani i harmonogram ujawnienia.

Czym jest security.txt?

security.txt to zwykły plik tekstowy zdefiniowany w RFC 9116 i udostępniany pod adresem /.well-known/security.txt. Mówi badaczom, gdzie zgłaszać podatności. Musi zawierać pola Contact i Expires i może odsyłać do polityki, klucza szyfrującego i strony podziękowań.

Jaki jest typowy termin ujawnienia?

Najczęściej cytowaną normą jest 90 dni. Google Project Zero daje dostawcom 90 dni na udostępnienie łatki i publikuje szczegóły 30 dni po niej, z terminem 7 dni, gdy podatność jest już wykorzystywana w rzeczywistych atakach. Państwa własna polityka może określać inne warunki, a koordynatorzy negocjują je indywidualnie.

Czy polityka skoordynowanego ujawniania podatności jest obowiązkowa?

Coraz częściej tak. Unijny Cyber Resilience Act wymaga od producentów produktów z elementami cyfrowymi wdrożenia i egzekwowania polityki CVD oraz podania adresu kontaktowego do zgłoszeń, a NIS2 wymienia obsługę i ujawnianie podatności wśród wymaganych środków bezpieczeństwa. Gdzie indziej często wymagają jej klienci i zasady zakupowe.

Czy trzeba być CNA, aby otrzymać identyfikator CVE?

Nie. CVE Numbering Authority (CNA) nadaje identyfikatory CVE w swoim zakresie, a wielu dostawców zostaje CNA dla własnych produktów. Jeśli nie są Państwo CNA, identyfikator może nadać CNA, którego zakres obejmuje Państwa produkt, lub CNA of Last Resort.