Кратко

  • В draft-bruhns-securitytxt-product-security-00 от 10 сентября 2026 года предложены необязательные поля Product-Security и Product-Security-Policy для формата RFC 9116.
  • Первое содержит URI контактов по уязвимостям продуктов и допускает порядок предпочтения; второе ведёт на HTTPS-политику об охвате, разборе, сроках и раскрытии.
  • Это индивидуальный Internet-Draft, а не принятый рабочей группой документ или утверждённый стандарт IETF. В действующем реестре IANA обоих полей нет.
  • Разные очереди улучшают первичную маршрутизацию, но не связывают модель, версию, повторно распространяемую сборку или сторонний компонент с принявшей ответственность командой.

Сообщение пришло, а изделие осталось ничьим

Исследователь воспроизводит ошибку на старой прошивке сетевого устройства. На сайте бренда есть специальный адрес продуктовой безопасности, письмо принято и получило номер. Позже выясняется, что линейку купила другая компания, конкретную версию обслуживал региональный партнёр, а повреждённый компонент разработан внешним проектом.

Почтовый канал в такой истории исправен. Не зафиксировано другое: кто признал артефакт своей зоной и способен принять решение об исправлении. Контактный URI выбирает первый переход. Он не назначает владельца кода, выпуска обновления и координации раскрытия.

Эта граница меняется со временем. OEM-поставка сохраняет одну марку при другом изготовителе, приобретение переносит команду, прекращение поддержки оставляет выпуски в эксплуатации, общая библиотека соединяет несколько поставщиков. Домен компании живёт дольше многих таких договорённостей.

Два предлагаемых расширения

Datatracker помечает Product Security Fields for security.txt как индивидуальный Internet-Draft. В истории на момент проверки есть только редакция 00 от 10 сентября. Публикация проекта открывает обсуждение, но не означает поддержку IETF, принятие рабочей группой или выпуск RFC.

Согласно тексту редакции, Product-Security может повторяться. Каждая строка содержит URI для сообщений об уязвимостях продукта и следует тем же ограничениям URI, что Contact. Порядок строк выражает предпочтение издателя.

Product-Security-Policy допускается один раз и указывает HTTPS-ресурс. Политика должна описывать охваченные продукты, подтверждение и триаж, ожидаемое время ответа, раскрытие и эмбарго, анонимные сообщения и гарантии добросовестным исследователям.

У охвата появляется явное место, но не автоматическая проверка. Ссылка сама не сообщает, перечислены ли нужная модель и версия, учтён ли конец поддержки и назван ли текущий сопровождающий. Она позволяет дать ответ, а не удостоверяет его наличие.

Запрос к IANA ещё не изменил реестр

Проект просит добавить два имени по политике Expert Review. В текущем реестре полей security.txt IANA нет ни Product-Security, ни Product-Security-Policy. Там присутствуют Contact, Expires, Canonical, Encryption, Policy, Preferred-Languages и зарегистрированные расширения, включая CSAF, Bug-Bounty и Hiring.

Предложение о регистрации и регистрация — разные события. RFC 8126 определяет Expert Review как оценку запроса назначенными экспертами по правилам соответствующего реестра. Текст раздела IANA Considerations не заменяет эту процедуру.

Локальные испытания возможны благодаря RFC 9116: неизвестные расширения следует игнорировать. Поэтому новый проект советует сохранять возможность принимать продуктовые сообщения через обычный Contact. Старый парсер не лишится маршрута, хотя ещё не понимает отдельной категории. Совместимость не равна подтверждённому внедрению.

Веб-источник не ведёт историю моделей

Обычная область действия RFC 9116 привязана к домену или IP-адресу, для которого получен файл. Она не распространяется автоматически на родительские и дочерние домены. Организация может публиковать сведения о продуктах и услугах, но формат не содержит реестр моделей, версий и смены сопровождающих.

У исследователя есть координата пакета, модель, диапазон серийных номеров, версия, сборка, ветка прошивки или commit. У издателя есть веб-источник, политика и очередь. Для контроля необходимо сохранить правило, по которому эти стороны сошлись.

Без него поздняя проверка увидит только доставку на домен бренда. Она не покажет, приняла ли команда нужный выпуск, передала ли поставщику и какую редакцию политики применила. Нынешняя веб-страница может незаметно заместить документ, действовавший в день сообщения.

Подлинность файла не означает компетенцию по продукту

RFC 9116 требует Expires, предусматривает Canonical и рекомендует подпись. Так можно распознать устаревшие контакты, найти задуманную копию и снизить риск перенаправления исследователя при компрометации сервера.

Каждый сигнал ограничен. Подпись связывает содержание с ключом, но не компонент с сопровождающим. Canonical URI указывает правильный файл, но не охваченную версию. Неистёкший срок показывает актуальность публикации, но не принятие случая.

Наличие или отсутствие security.txt также не разрешает и не запрещает тестирование. Продуктовая политика может описывать гарантии, однако их предметный и правовой охват определяется конкретным текстом, а не названием нового поля.

Квитанция о передаче артефакта

Запись начинается с данных отчёта: семейство, модель, компонент или пакет, версия, сборка, ветка прошивки и канал распространения — насколько они известны. Затем сохраняются источник и Canonical URL файла, время получения, Expires, результат проверки подписи и выбранная строка Product-Security с её местом в порядке предпочтения.

Нужны также URL Product-Security-Policy и хеш содержания либо номер редакции. Получатель указывает пункт охвата, который обосновал принятие, отказ или перенаправление, команду-хранителя и номер дела или передачи. Конфиденциальные детали уязвимости можно не публиковать; сама граница решения должна остаться.

Эта квитанция — редакционное предложение Daniel Kade, а не требование версии 00, RFC 9116 или IANA. Она не повторяет проверку работоспособности канала. Живой адрес подтверждает получение, а запись об артефакте — последовавшее решение об ответственности.

Источники