Страница политики безопасности — не процесс раскрытия

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

Найдите канал и убедитесь, что он существует

Начните с документированного пути: страница политики безопасности, выделенный адрес или файл /.well-known/security.txt, поле Contact которого определено в RFC 9116.

Затем прочитайте абзац об охвате, а не дружелюбное вступление. Какие продукты охвачены, какие версии и какого обращения проект просит?

Канал, принадлежащий другому проекту или хостинг-провайдеру вместо сопровождающего, не является процессом раскрытия для оцениваемого программного обеспечения.

Публичный трекер или закрытый канал

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

Проект, предлагающий только публичный трекер, не предоставил канал раскрытия, что бы ни говорила его документация.

Ничто из этого не разрешает тестировать системы, которыми вы не владеете. Адрес для отчётов — приглашение прислать информацию, а не разрешение зондировать посторонние публичные серверы.

Проследите одно исправление от начала до конца

Выберите прошлое уведомление и проследите его: называет ли оно затронутые версии и выпуск, который их исправляет, и может ли пользователь действительно установить этот выпуск?

Этот след — разница между подтверждением и ремонтом. Вежливый ответ, который никогда не даёт выпуска, — результат для связей с общественностью. Краткое уведомление с номером версии и ссылкой на загрузку — работающий процесс. Хорошее уведомление быстро отвечает на четыре вопроса: что затронуто, каково воздействие, какая версия исправляет и где это получить.

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

Сопровождающий клиента или оператор сервиса

Для VPN люди, пишущие клиент, и люди, эксплуатирующие шлюз, часто являются разными организациями. Проблема в коде клиента и ошибка при развёртывании сервера требуют разных получателей.

Решите, к кому из двух относится ваша находка, прежде чем отправлять её, потому что направление не той стороне обычно заканчивается молчанием, а не возвратом.

Что доказывает отсутствие и что нет

Пустой список уведомлений не доказывает, что продукт свободен от дефектов. Он может означать молодой проект, малую поверхность или то, что никто не смотрит.

Равным образом отсутствующая страница политики не является доказательством недобросовестности. Это доказательство того, что вы не можете проверить процесс, и это честный вывод, который стоит записать.

Что записать

Запишите четыре факта: контакт, который вы можете проверить, охват, покрывающий вашу версию, уведомления с указанием исправленных выпусков и историю выпусков, показывающую, что исправления выходят.

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