安全政策页面不等于披露流程

每个认真做事的项目都有安全页面，而一个页面很便宜。真正有用的问题是：通过文档记载的渠道发出的报告，是否会带来普通用户可以安装的修复版本。这需要四份证据而不是一句声明，而且全都可以从外部核查，无需探测任何东西。没有一项需要拿别人的服务器做测试。它们全都写在一页笔记里就够。

找到渠道并确认它确实存在

从文档记载的路径开始：安全政策页面、专用邮箱地址，或者一个 /.well-known/security.txt 文件，其 Contact 字段由 RFC 9116 定义。

然后读范围那一段，而不是友善的开场白。哪些产品在覆盖范围内、哪些版本，项目要求怎样的处理方式？

属于另一个项目、或属于托管服务商而非维护者的渠道，并不是你在评估的这款软件的披露流程。

公开问题跟踪器还是私密渠道

普通缺陷适合放在公开跟踪器里，也能从中受益。含有可利用细节的报告则不适合，公开提交会在维护者还在阅读时就把用户暴露出去。

只提供公开跟踪器的项目，无论文档怎么写，都没有提供披露渠道。

这一切都不授权你去测试不属于自己的系统。报告地址是邀请你发送信息，不是允许你探测无关的公共服务器。

把一次修复从头追到尾

挑一份过去的安全公告追一遍：它是否写明了受影响的版本和修复该问题的发行版，用户是否真的能安装那个发行版？

这条轨迹正是确认与修复之间的差别。礼貌的回复若从不产出任何发行版，那只是公关结果。一份带版本号和下载链接的简短公告，才是能运转的流程。好的公告会迅速回答四件事：什么受影响、影响是什么、哪个版本修复、到哪里获取。

发行历史可以补上其余部分。定期发布并附有清晰说明，说明这个项目有能力交付修复，这比雄辩的政策更重要。

客户端维护者还是服务运营方

对 VPN 而言，编写客户端的人和运营网关的人常常是不同组织。客户端代码的问题与服务器部署的失误需要不同的接收方。

发送之前先判断你的发现属于哪一方，因为发给错误的一方通常以沉默收场，而不是被退回。

缺失能证明什么，不能证明什么

公告列表为空，并不能证明产品没有缺陷。它可能意味着项目年轻、暴露面小，或者根本没人看。

同样，缺少政策页面也不是恶意的证据。它只证明你无法核实这套流程，而这才是应当记下的诚实结论。

该记下什么

记下四件事：可核实的联系方式、覆盖你所使用版本的范围、写明已修复发行版的公告，以及显示修复确实会发布的发行历史。

然后记下仍然未知的部分。一份这样说明的评估，比把缺失的政策说成安全结论的评估更有用。