Zasady ujawniania podatności

W skrócie

Ta strona definiuje zasady skoordynowanego ujawniania podatności w NextPDF. Wyjaśnia, jak prywatnie skontaktować się z opiekunami projektu, jakiego harmonogramu odpowiedzi oczekiwać oraz jak działają embarga.

Granica. Zasady ujawniania są zobowiązaniem proceduralnym, a nie gwarancją harmonogramu ani wyniku. Poniższe cele są składanymi w dobrej wierze zobowiązaniami opiekunów wobec zgłaszającego; opisują proces, którego projekt przestrzega, a nie umowną obietnicę, że którekolwiek konkretne zgłoszenie zostanie potwierdzone, poddane wstępnej ocenie, naprawione lub ujawnione w określonym terminie. Termin skoordynowanego ujawnienia jest negocjowany, a nie gwarantowany jednostronnie.

Instalacja

Nie dotyczy. Aby zgłosić podatność, nie trzeba niczego instalować. Maszynowo odczytywalny punkt kontaktowy jest publikowany pod adresem /.well-known/security.txt (Request for Comments (RFC) 9116). Plik SECURITY.md w repozytorium jest autorytatywną wersją zasad czytelną dla człowieka.

Przegląd koncepcyjny

Zasady te realizują skoordynowane ujawnianie podatności zdefiniowane w ISO/IEC 29147 oraz proces obsługi opisany w ISO/IEC 30111 (iso_iec_30111#x9.x43.p2): prywatne przyjmowanie zgłoszeń, wstępną ocenę oraz ocenę istotności, naprawę w trybie embarga i wspólną publikację. Jeśli podatność dotyczy wielu dostawców, zaangażowane strony koordynują termin publikacji ostrzeżenia, zamiast ustalać go jednostronnie (iso_iec_29147#x3.x110.p13).

Proces ten jest również zgodny z obowiązkami producenta w zakresie obsługi podatności wynikającymi z aktu Unii Europejskiej (UE) o cyberodporności (Cyber Resilience Act, CRA) (eu_cra#x1.p191) oraz z praktyką „odpowiadania na podatności” opisaną w Secure Software Development Framework (SSDF) opracowanym przez National Institute of Standards and Technology (NIST) (nist_sp_800_218#x15). Oba dokumenty przedstawiają je jako powtarzalne obowiązki proceduralne, a nie jako rękojmię gwarantującą jakikolwiek indywidualny wynik.

Powierzchnia API

Nie dotyczy. Ujawnianie jest procesem, a nie interfejsem programistycznym aplikacji (API). Maszynowo odczytywalnym punktem wykrywania jest plik security.txt zgodny z RFC 9116; narzędzia odczytują jego pola Contact: oraz Expires:. Ta strona nie powiela zawartości tego pliku poza kanałami wymienionymi poniżej.

Przykład kodu — szybki start

Nie dotyczy. Podczas zgłaszania podatności nie ma żadnego kodu do uruchomienia. Skorzystaj z prywatnego kanału:

• GitHub Security Advisories (zalecane — szyfrowanie danych w spoczynku, dziennik audytu): otwórz roboczą wersję ostrzeżenia w zakładce GitHub Security projektu.
• E-mail: [email protected] z dopiskiem [SECURITY] w temacie. Jeśli wymagane jest szyfrowanie end-to-end, a w pliku security.txt nie jest jeszcze opublikowany żaden klucz OpenPGP, skorzystaj zamiast tego z kanału GitHub Security Advisory.

Nie zgłaszaj za pośrednictwem publicznych zgłoszeń (issues), publicznych list mailingowych, mediów społecznościowych ani czatu. Publiczne ujawnienie przed naprawą naraża na ryzyko użytkowników korzystających z wersji bez poprawki.

Przykład kodu — środowisko produkcyjne

Nie dotyczy.

Przypadki brzegowe i pułapki

• Cele są zobowiązaniami, a nie umowami o poziomie usług (SLA). Poniższy harmonogram określa, do czego projekt dąży. Złożony problem dotyczący wielu komponentów lub wymagający koordynacji z podmiotami zewnętrznymi może zająć więcej czasu; projekt informuje zgłaszającego o postępach.
• Długość embarga podlega negocjacjom i ma górną granicę. Domyślne embargo trwa od wstępnej oceny do wydania poprawki. Jeśli potrzebujesz więcej czasu, poproś o to wyraźnie podczas otwierania ostrzeżenia. Po upływie maksymalnego okresu projekt opublikuje ostrzeżenie niezależnie od tego, czy poprawka jest dostępna, zgodnie z branżowymi normami skoordynowanego ujawniania. Chroni to użytkowników przed wstrzymywaniem ostrzeżenia na czas nieokreślony.
• Istotność wyznacza harmonogram. Krytyczny, aktywnie wykorzystywany problem jest obsługiwany w skróconym harmonogramie; sugestia dotycząca wzmocnienia o niskiej istotności nie. Istotność jest oceniana podczas wstępnej oceny i może zostać zweryfikowana.
• Nadawanie identyfikatora Common Vulnerabilities and Exposures (CVE) jest częścią wstępnej oceny. Opiekun projektu wnioskuje o CVE za pośrednictwem GitHub Security Advisory przez rejestrację projektu jako CVE Numbering Authority (CNA), w ramach etapu wstępnej oceny; zgłaszający nie musi składać osobnego wniosku.

Wydajność

Nie dotyczy.

Uwagi dotyczące bezpieczeństwa

Cele dotyczące harmonogramu odpowiedzi są zobowiązaniami wobec zgłaszających i stanowią podstawowy poziom obsługi podatności w projekcie. Są to cele, a nie gwarancje:

Etap	Cel
Potwierdzenie otrzymania	w ciągu 1–2 dni roboczych
Wstępna ocena + ocena istotności	w ciągu ~5 dni roboczych / 7 dni kalendarzowych
Opracowanie poprawki + prywatny przegląd	zazwyczaj 14 dni roboczych; 30–90 dni dla złożonych potwierdzonych CVE w zależności od istotności
Przypisanie CVE (jeśli zaakceptowane)	równolegle z poprawką, przez kanał GitHub CNA
Skoordynowane publiczne ujawnienie	przy wydaniu poprawki, w terminie ustalonym wspólnie ze zgłaszającym
Embargo (od wstępnej oceny do wydania)	domyślnie ~90 dni, skracane w przypadku aktywnego wykorzystywania, z możliwością wydłużenia na wyraźną prośbę do ustalonego maksimum

Recenzenci mogą sprawdzić następujące zasady procesu:

1. Najpierw prywatnie. Żaden publiczny kanał nie jest akceptowany jako kanał przyjmowania zgłoszeń. Jedynymi akceptowanymi kanałami są GitHub Security Advisory oraz adres e-mail ds. bezpieczeństwa.
2. Skoordynowane, a nie jednostronne. Czas ujawnienia jest negocjowany ze zgłaszającym oraz wszystkimi dostawcami, których problem również dotyczy (iso_iec_29147#x3.x110.p13).
3. Ograniczone embargo. Embargo ma domyślny czas trwania oraz sztywną górną granicę; projekt nie wstrzymuje ostrzeżenia na czas nieokreślony.
4. Uznanie autorstwa na życzenie. Badacze są wymieniani z imienia po wygaśnięciu embarga, chyba że poproszą o anonimowość.

Stwierdzenia te opisują proces, którego projekt zobowiązuje się przestrzegać. Nie gwarantują jednak, że dane zgłoszenie zakończy się poprawką, nadaniem CVE ani ujawnieniem w określonym terminie.

Zgodność

Nie jest to profil zgodności. Zasady te są zgodne z ISO/IEC 29147, ISO/IEC 30111 oraz z przytoczonymi powyżej obowiązkami proceduralnymi CRA i SSDF; sformułowanie „zgodne z” jest świadomym wyborem. Projekt nie deklaruje certyfikacji według żadnego z tych schematów. Dokumenty te definiują rzetelny proces; ta strona dokumentuje zobowiązanie projektu do jego prowadzenia.

Zobacz także

• Centrum zaufania
• Model zagrożeń silnika
• Model bezpieczeństwa podpisu i szyfrowania
• Plik SECURITY.md w repozytorium oraz /.well-known/security.txt (RFC 9116)