Генератор и проверка security.txt
Составьте корректный security.txt по RFC 9116, чтобы исследователи знали, как с вами связаться, или вставьте готовый файл и посмотрите, что в нём не так. Часть подготовки к Регламенту ЕС о киберустойчивости.
Работает полностью в браузере
Создать security.txt
Проверить security.txt
Проверяет текст только по RFC 9116. Страница не загружает ваш сайт (всё, что вы вводите, остаётся на этой странице, поэтому вставляйте файл целиком), не проверяет подпись OpenPGP и не проверяет, что указанные адреса работают. Это шаблон, а не юридическая консультация.
Как создать и проверить security.txt
- Укажите хотя бы один Contact (адрес электронной почты, номер телефона или страницу https://) и проверьте дату Expires. Заполните нужные необязательные поля, например Policy и Preferred-Languages.
- Скопируйте файл или скачайте его и опубликуйте по адресу
/.well-known/security.txtна своём домене по HTTPS как обычный текст. - Чтобы проверить существующий файл, вставьте его текст в проверку. Сначала исправьте ошибки, затем посмотрите предупреждения. Чтобы проверить поле Canonical, укажите адрес, с которого файл отдаётся.
- Поставьте в календаре напоминание обновить Expires до того, как срок истечёт.
Для чего нужен security.txt
Когда исследователь, клиент или CERT находит уязвимость в вашем программном обеспечении, первая проблема — кому о ней сообщить. security.txt — это небольшой текстовый файл по фиксированному адресу /.well-known/security.txt, который отвечает на этот вопрос: в нём указаны контакт, срок действия и, при желании, ссылка на вашу политику раскрытия уязвимостей и открытый ключ. Формат описан в RFC 9116, и многие сканеры, платформы bug bounty и национальные CERT ищут этот файл в первую очередь.
Для поставщика программного обеспечения в ЕС он также помогает выполнять обязанности по Регламенту ЕС о киберустойчивости (Cyber Resilience Act, CRA): приложение I предполагает, что у посторонних есть опубликованный способ сообщить об уязвимостях, а у вас есть процесс их обработки. Регламент не называет этот формат, но обычно контакт публикуют именно так. Остальную настройку, включая 24-часовой отсчёт, описывает руководство по отчётности для небольших поставщиков.
Поля файла
Contact и Expires обязательны. Contact может повторяться и должен быть URI: mailto:, tel: или https:. Expires указывается один раз как дата и время вида 2027-12-31T23:59:59Z, и RFC 9116 просит ставить срок меньше чем через год. Encryption, Acknowledgments, Policy, Hiring и Canonical — необязательные ссылки, и каждый веб-адрес должен быть https. Preferred-Languages указывается один раз и перечисляет коды языков. Поля, которых нет в RFC, читатели игнорируют, поэтому проверка помечает их предупреждениями: чаще всего это опечатки.
Советы
- Используйте почтовый ящик, который читают несколько человек, а не адрес одного сотрудника, и проверьте его, написав туда письмо.
- Составьте политику раскрытия уязвимостей и укажите её в поле Policy.
- Узнайте свои сроки до того, как придёт сообщение: 24-часовые часы CRA для инцидентов превращают момент, когда вы узнали о проблеме, в конкретные даты и время.
Вопросы и ответы
Требует ли Регламент о киберустойчивости файл security.txt?
Нет. Регламент ожидает, что у производителя есть политика скоординированного раскрытия уязвимостей и опубликованный способ сообщить об уязвимости. Файл security.txt — распространённый способ опубликовать такой контакт, и специалисты его рекомендуют, но формат в регламенте не назван. Подробнее в руководстве для небольших поставщиков.
Куда именно нужно положить файл?
По адресу https://ваш-домен/.well-known/security.txt по HTTPS с типом содержимого text/plain; charset=utf-8. Для старых систем RFC 9116 допускает также копию в /security.txt. Публикуйте файл на каждом домене и поддомене, который нужно охватить.
На какой срок вперёд ставить Expires?
По RFC 9116 срок должен быть меньше года, чтобы исследователи могли доверять тому, что контакты поддерживаются в актуальном состоянии. Генератор по умолчанию ставит чуть меньше года. Когда дата проходит, читателям предписано игнорировать файл, поэтому обновляйте его заранее.
Нужно ли подписывать файл PGP?
Нет, подпись необязательна, но рекомендуется. Подписанный файл — это сообщение OpenPGP с открытой подписью, его создаёт команда gpg --clearsign security.txt. Проверка распознаёт подписанный формат и смотрит на его структуру, но саму подпись проверить не может; для этого используйте gpg --verify.
Почему проверка не загружает мой сайт?
Чтобы страница оставалась приватной: она целиком работает в вашем браузере и не обращается к другим сайтам. Откройте файл в соседней вкладке, скопируйте текст и вставьте его сюда. Так вы заодно проверите то, что реально получают посетители.
Для чего нужно поле Canonical?
В нём перечислены адреса, по которым файл должен отдаваться, чтобы читатель мог убедиться, что файл, найденный по одному адресу, действительно принадлежит этому месту. Если указать адрес, с которого вы отдаёте файл, проверка убедится, что одна из строк Canonical ему соответствует.