Откуда взялся security.txt?
Откуда взялся security.txt? • 10 лет назад, ИБ-исследователь и бывший аналитик компании HackerOne Эд Фодил, предложил реализовать стандарт security.txt. Он описывает содержимое специального файла - того самого security.txt - который размещается в директории /.well-known и включает контактную информацию и инструкции для оповещения об уязвимостях. По сути, это - аналог robots.txt, только для специалистов по информационной безопасности. • Сама идея сформировалась после посещения конференции DEF CON и соревнований по кибербезопасности. Он размышлял о вкладе участников подобных мероприятий в развитие инфобеза. По его словам, источником вдохновения также послужили SECURITY.md и BUG-BOUNTY.md - файлы с политиками безопасности, которые разработчики добавляют в репозитории. В свою очередь, IETF-драфт нового стандарта был предназначен для более широких задач и включал следующие поля: • Contact - для указания email, номера телефона, URL специальной формы на сайте и других каналов коммуникации по теме уязвимостей. • Encryption - содержит ссылку на ключ шифрования, который ИБ-специалисты должны использовать для передачи сообщений. • Acknowledgements - компания может указать ссылку на веб-страницу, где она говорит спасибо исследователям, которые ей помогли. • Disclosure - формат предоставления информации об уязвимости. • При этом в репозитории, где автор делал заметки, изначально были отмечены и другие поля - например, In-scope, Out-of-scope-vuln, Rate-limit, Platform, Reward, Payment-method, Currency, Donate и Disallow. Они, помимо прочего, предоставляли больше информации о программах bug bounty, вознаграждении для этичных хакеров и декларировали, отчеты о каких уязвимостях не будут рассматриваться ИБ-специалистами компании, разместившей security.txt на своем сайте. • Разработчик решил не включать данные поля в драфт, потому что представители крупной технологической фирмы рекомендовали ему посмотреть, как владельцы сайтов отреагируют на новый стандарт. И уже потом корректировать его, анализируя обратную связь. В апреле 2022 года security.txt был опубликован как RFC 9116, и финальный список полей был действительно модернизирован. Например, было убрано поле Disclosure, вместо него появилось поле Policy со ссылкой на политики раскрытия информации - как стоит действовать ИБ-исследователям, желающим сообщить об уязвимости. Также появились поля: • Expires - дата, после которой файл считается устаревшим. • Hiring - информация о ИБ-вакансиях у компании-владельца сайта. • Preferred-Languages - языки, на которых стоит сообщать о найденных уязвимостях. • При этом стоит отметить, что стандарт security.txt должен был не заменить, но дополнить RFC 2142, который, помимо прочего, рекомендует владельцам сайтов завести почтовый ящик security@domain для приема сообщений о проблемах безопасности. Вот так и появился security.txt =) • К слову, приживается он не слишком активно. По некоторым оценкам - например, на основе анализа ресурсов из рейтинга Tranco, включающего миллион наиболее посещаемых веб-страниц - на 2022 год security.txt был представлен лишь на 3724 сайтах (0,37%). Более свежую оценку, пусть и на меньшей выборке, привел в своем блоге Себастьян Пиппинг. В 2025 году он проверил 50 компаний из своего списка пользователей libexpat (в него вошли такие организации, как Bosch, Ford, Yamaha и др.) и обнаружил security.txt на сайтах только 11 из них. • Сложно сказать наверняка, что поможет повысить узнаваемость этого стандарта и сделать его более распространенным. Однако отдельные страны уже реализуют профильные инициативы. Например, в Нидерландах государственные сайты обязали работать с security.txt на законодательном уровне. • Кстати, у нас применяется данный стандарт, но не везде. Пример: gosuslugi.ru/security.txt или mos.ru/security.txt. #Разное