Сторінка політики безпеки — не процес розкриття
Оприлюднена політика — це обіцянка. Контакт, який відповідає, відповідне охоплення й повідомлення із зазначенням виправлених версій є доказом того, що вона працює.
Кожен серйозний проєкт має сторінку безпеки, а сторінка коштує дешево. Корисне питання в тому, чи призводить звіт, надісланий документованим каналом, до виправленого випуску, який звичайні користувачі можуть установити. Для цього потрібні чотири докази замість однієї заяви, і всі вони перевіряються ззовні без будь-якого зондування. Жоден не потребує тесту проти чужого сервера. Усі вони вміщаються на одній сторінці нотаток.
Знайдіть канал і переконайтеся, що він існує
Почніть із документованого шляху: сторінка політики безпеки, виділена адреса або файл /.well-known/security.txt, поле Contact якого визначене в RFC 9116.
Потім прочитайте абзац про охоплення, а не привітний вступ. Які продукти охоплено, які версії і якого поводження проєкт просить?
Канал, що належить іншому проєкту або хостинг-провайдеру замість супровідника, не є процесом розкриття для програмного забезпечення, яке ви оцінюєте.
Публічний трекер чи закритий канал
Звичайні дефекти доречні в публічному трекері й отримують від нього користь. Звіт із використовуваною деталлю — ні, а публічне подання наражає користувачів на ризик, поки супровідник ще читає його.
Проєкт, який пропонує лише публічний трекер, не надав каналу розкриття, що б не казала його документація.
Ніщо з цього не дозволяє тестувати системи, якими ви не володієте. Адреса для звітів — це запрошення надіслати інформацію, а не дозвіл зондувати сторонні публічні сервери.
Простежте одне виправлення від початку до кінця
Виберіть минуле повідомлення й простежте його: чи називає воно уражені версії та випуск, що їх виправляє, і чи може користувач справді встановити цей випуск?
Цей слід — різниця між підтвердженням і ремонтом. Ввічлива відповідь, яка ніколи не дає випуску, — це результат для зв'язків із громадськістю. Коротке повідомлення з номером версії та посиланням на завантаження — робочий процес. Добре повідомлення швидко відповідає на чотири речі: що уражено, який вплив, яка версія виправляє і де це взяти.
Історія випусків доповнює решту. Регулярні випуски з ясними нотатками вказують на проєкт, здатний випустити виправлення, і це важливіше за красномовну політику.
Супровідник клієнта чи оператор сервісу
Для VPN люди, які пишуть клієнт, і люди, які експлуатують шлюз, часто є різними організаціями. Проблема в коді клієнта й помилка під час розгортання сервера потребують різних одержувачів.
Вирішіть, до кого з двох стосується ваша знахідка, перш ніж надсилати її, бо скерування не тій стороні зазвичай закінчується мовчанням, а не поверненням.
Що доводить відсутність і що ні
Порожній список повідомлень не доводить, що продукт вільний від дефектів. Він може означати молодий проєкт, малу поверхню або те, що ніхто не дивиться.
Так само відсутня сторінка політики не є доказом недобросовісності. Це доказ того, що ви не можете перевірити процес, і це чесний висновок, який варто записати.
Що записати
Запишіть чотири факти: контакт, який ви можете перевірити, охоплення, що покриває вашу версію, повідомлення із зазначенням виправлених випусків та історію випусків, яка показує, що виправлення виходять.
Потім зазначте, що залишається невідомим. Огляд, який це каже, корисніший за той, що перетворює відсутню політику на твердження про безпеку.