Każdy poważny projekt ma stronę bezpieczeństwa, a strona jest tania. Użyteczne pytanie brzmi, czy zgłoszenie wysłane udokumentowanym kanałem prowadzi do poprawionego wydania, które zwykli użytkownicy mogą zainstalować. To wymaga czterech dowodów zamiast jednego twierdzenia, a wszystkie są weryfikowalne z zewnątrz bez sondowania czegokolwiek. Żaden nie wymaga testu przeciwko cudzemu serwerowi. Wszystkie mieszczą się na jednej stronie notatek.

Znajdź kanał i sprawdź, że istnieje

Zacznij od udokumentowanej drogi: strona polityki bezpieczeństwa, dedykowany adres lub plik /.well-known/security.txt, którego pole Contact jest zdefiniowane przez RFC 9116.

Potem przeczytaj akapit o zakresie, a nie przyjazne wprowadzenie. Które produkty są objęte, które wersje i jakiego traktowania projekt oczekuje?

Kanał należący do innego projektu albo do dostawcy hostingu zamiast do opiekuna nie jest procesem ujawniania dla ocenianego oprogramowania.

Publiczny tracker czy kanał prywatny

Zwykłe błędy należą do publicznego trackera i czerpią z niego korzyść. Zgłoszenie z możliwym do wykorzystania szczegółem nie, a publiczne złożenie naraża użytkowników, gdy opiekun wciąż je czyta.

Projekt, który oferuje tylko publiczny tracker, nie zapewnił kanału ujawniania, cokolwiek mówi jego dokumentacja.

Nic z tego nie upoważnia do testowania systemów, których nie posiadasz. Adres zgłoszeń to zaproszenie do przesłania informacji, a nie zgoda na sondowanie niepowiązanych publicznych serwerów.

Prześledź jedną poprawkę od początku do końca

Wybierz wcześniejszy komunikat i prześledź go: czy wymienia dotknięte wersje i wydanie, które je poprawia, i czy użytkownik może naprawdę zainstalować to wydanie?

Ten ślad to różnica między potwierdzeniem a naprawą. Uprzejma odpowiedź, która nigdy nie daje wydania, to wynik dla public relations. Krótki komunikat z numerem wersji i linkiem do pobrania to działający proces. Dobry komunikat szybko odpowiada na cztery rzeczy: co jest dotknięte, jaki jest wpływ, która wersja to poprawia i gdzie to dostać.

Historia wydań dopełnia resztę. Regularne wydania z jasnymi notatkami wskazują na projekt, który potrafi dostarczyć poprawkę, a to ważniejsze niż elokwentna polityka.

Opiekun klienta czy operator usługi

W przypadku VPN osoby piszące klienta i osoby obsługujące bramę to często różne organizacje. Problem w kodzie klienta i błąd przy wdrażaniu serwera wymagają różnych odbiorców.

Zdecyduj, którego z nich dotyczy twoje odkrycie, zanim je wyślesz, bo skierowanie do niewłaściwej strony zwykle kończy się ciszą, a nie odbiciem.

Co dowodzi nieobecność, a czego nie

Pusta lista komunikatów nie dowodzi, że produkt jest wolny od błędów. Może oznaczać młody projekt, małą powierzchnię albo że nikt nie patrzy.

Podobnie brak strony polityki nie jest dowodem złej wiary. To dowód, że nie możesz zweryfikować procesu, i to jest uczciwy wniosek do zapisania.

Co zapisać

Zapisz cztery fakty: kontakt, który możesz zweryfikować, zakres obejmujący twoją wersję, komunikaty wymieniające poprawione wydania i historię wydań pokazującą, że poprawki wychodzą.

Potem zapisz, co pozostaje nieznane. Przegląd, który to mówi, jest użyteczniejszy niż taki, który zamienia brakującą politykę w twierdzenie o bezpieczeństwie.

Powiązane artykuły