TanodTools
PL

Generator i walidator security.txt

Zbuduj poprawny plik security.txt zgodny z RFC 9116, aby badacze wiedzieli, jak się z Tobą skontaktować, albo wklej istniejący i zobacz, co jest w nim nie tak. To część przygotowań do unijnego aktu o cyberodporności (CRA).

Działa w całości w Twojej przeglądarce

Wygeneruj plik security.txt

Wymagane
Adres e-mail, numer telefonu z numerem kierunkowym kraju albo strona https://. Badacze próbują najpierw pierwszego wiersza.
Opcjonalne
Twoja polityka ujawniania podatności. Napisz ją tutaj.
Link https:// do Twojego klucza publicznego, rekord dns: lub odcisk openpgp4fpr:.
Kody języków oddzielone przecinkami.
Adres, pod którym ten plik będzie udostępniany. Zalecane, zwłaszcza dla plików podpisanych.
Strona z podziękowaniami dla badaczy, którzy zgłosili problemy.
Strona z Twoimi ofertami pracy w obszarze bezpieczeństwa.

    Gdzie go umieścić

    Zapisz plik jako security.txt i udostępnij go pod adresem https://your-domain/.well-known/security.txt przez HTTPS jako zwykły tekst (text/plain; charset=utf-8). Zrób tak samo w każdej domenie, którą chcesz objąć. Aby go podpisać, uruchom gpg --clearsign security.txt i opublikuj wynik.

    Sprawdź plik security.txt

    Domena lub pełny adres. Służy do sprawdzenia, czy pole Canonical pasuje. Nic nie jest pobierane.

      Sprawdza tekst wyłącznie pod kątem RFC 9116. Nie pobiera Twojej strony (nic, co wpiszesz, nie opuszcza tej strony, dlatego wklej plik), nie weryfikuje podpisu OpenPGP ani nie sprawdza, czy dany adres działa. To szablon, a nie porada prawna.

      Jak utworzyć i sprawdzić plik security.txt

      1. Wpisz co najmniej jedno pole Contact (adres e-mail, numer telefonu lub stronę https://) i sprawdź datę Expires. Wypełnij wybrane pola opcjonalne, takie jak Policy i Preferred-Languages.
      2. Skopiuj plik lub pobierz go i opublikuj pod adresem /.well-known/security.txt w swojej domenie przez HTTPS jako zwykły tekst.
      3. Aby sprawdzić istniejący plik, wklej jego tekst do walidatora. Popraw błędy, a potem przejrzyj ostrzeżenia. Podaj adres, pod którym plik jest udostępniany, aby przetestować pole Canonical.
      4. Ustaw w kalendarzu przypomnienie, aby odnowić Expires, zanim data minie.

      Do czego służy security.txt

      Gdy badacz, klient albo zespół CERT znajdzie słabość w Twoim oprogramowaniu, pierwszy problem to ustalenie, komu o tym powiedzieć. Plik security.txt to mały plik tekstowy pod stałym adresem, /.well-known/security.txt, który na to odpowiada: podaje kontakt, datę wygaśnięcia, a opcjonalnie link do polityki ujawniania podatności i klucz publiczny. Format opisuje RFC 9116, a wiele skanerów, platform bug bounty i krajowych zespołów CERT szuka tego pliku, zanim zajrzy gdziekolwiek indziej.

      Dla dostawcy oprogramowania w UE wspiera on także obowiązki wynikające z aktu o cyberodporności: załącznik I oczekuje opublikowanego sposobu, w jaki osoby z zewnątrz mogą zgłaszać podatności, oraz procesu ich obsługi. Rozporządzenie nie wskazuje tego formatu, ale to zwykły sposób publikacji kontaktu. Poradnik zgłaszania dla małych dostawców opisuje pozostałe elementy konfiguracji, w tym zegar 24 godzin.

      Pola

      Contact i Expires są wymagane. Contact może wystąpić kilka razy i musi być identyfikatorem URI: mailto:, tel: lub https:. Expires występuje raz, jako data i godzina, na przykład 2027-12-31T23:59:59Z, a RFC 9116 prosi o termin krótszy niż rok. Encryption, Acknowledgments, Policy, Hiring i Canonical to opcjonalne linki, a każdy adres internetowy musi używać https. Preferred-Languages występuje raz i wymienia kody języków. Pola, których RFC nie definiuje, są ignorowane przez odbiorców, więc walidator zgłasza je jako ostrzeżenia: zwykle to literówki.

      Wskazówki

      • Użyj skrzynki, którą czyta kilka osób, a nie adresu jednej osoby, i sprawdź ją, pisząc na nią wiadomość.
      • Napisz politykę ujawniania podatności i podlinkuj ją w polu Policy.
      • Poznaj swoje terminy, zanim nadejdzie zgłoszenie: zegar zgłoszeń 24 godz. CRA zamienia moment uzyskania wiedzy o zdarzeniu na terminy z datami.

      Najczęstsze pytania

      Czy akt o cyberodporności wymaga pliku security.txt?

      Nie. Rozporządzenie oczekuje, że producenci będą mieć politykę skoordynowanego ujawniania podatności i opublikowany sposób zgłaszania podatności. Plik security.txt to powszechny sposób publikacji takiego kontaktu i praktycy go zalecają, ale rozporządzenie nie wskazuje tego formatu. Zobacz poradnik dla małych dostawców.

      Gdzie dokładnie umieścić plik?

      Pod adresem https://twoja-domena/.well-known/security.txt, udostępniany przez HTTPS z typem zawartości text/plain; charset=utf-8. RFC 9116 dopuszcza też kopię pod /security.txt dla starszych konfiguracji. Opublikuj plik w każdej domenie i subdomenie, którą chcesz objąć.

      Jak daleko w przyszłość ustawić Expires?

      RFC 9116 mówi, że data powinna przypadać za mniej niż rok, aby badacze mogli ufać, że dane kontaktowe są aktualne. Generator domyślnie ustawia datę tuż poniżej roku. Gdy data minie, odbiorcy mają ignorować plik, więc odnów go z wyprzedzeniem.

      Czy muszę podpisać plik kluczem PGP?

      Nie, podpisywanie jest opcjonalne, ale zalecane. Podpisany plik to wiadomość OpenPGP podpisana jawnie (cleartext), wykonana poleceniem gpg --clearsign security.txt. Walidator rozpoznaje format podpisany i sprawdza jego ogólną strukturę, ale nie zweryfikuje samego podpisu; użyj do tego gpg --verify.

      Dlaczego walidator nie pobiera mojej strony?

      Aby zachować prywatność: działa w całości w Twojej przeglądarce i nie wysyła żądań do innych witryn. Otwórz plik w karcie przeglądarki, skopiuj tekst i wklej go tutaj. Dzięki temu sprawdzisz też to, co faktycznie dostają odwiedzający.

      Do czego służy pole Canonical?

      Wymienia adresy, pod którymi plik ma być udostępniany, dzięki czemu odbiorca może potwierdzić, że plik znaleziony pod jednym adresem naprawdę tam należy. Jeśli podasz adres, z którego udostępniasz plik, walidator sprawdzi, czy któryś wiersz Canonical do niego pasuje.