IT/AV终端检测认证事业部

做了PSTI、CRA、澳大利亚智能设备认证，却栽在一个"邮箱"上？

漏洞披露渠道公示——这个小要求能卡掉一半企业。很多企业做IoT出海合规，精力全放在技术上，却忽略了官网、说明书上公示漏洞接受渠道这个"不起眼"的强制要求。

先搞清楚：什么是"漏洞披露渠道"？

这个"找谁"，不能是你的客服电话，不能是你前台邮箱，更不能没有。它必须是一个专门的、公开的、可追溯的漏洞报告渠道。

很多中国企业的第一反应是——"我们产品没问题，为什么要公示漏洞渠道？"这个心态就错了。法规要求你公示漏洞渠道，不是因为你"有漏洞"，而是因为——你要有一个接收漏洞的机制。就像你开店要挂营业执照一样，不是因为你一定会违法，是因为监管需要确认你是正规经营。

各国标准怎么要求？一张表看懂

1 英国PSTI：最早落地，查得严

英国PSTI是全球第一个把"漏洞披露渠道"写进法律的IoT法规。PSTI的三条核心要求：

• 不得使用通用默认密码
• 公示漏洞披露联系点 ← 就是这条
• 明确产品安全更新期限

怎么查？英国市场监管机构（OPSS）的操作很简单——打开你官网，找"security"或"vulnerability disclosure"页面。找不到？不合规。找到了但邮箱是个销售邮箱？不合规。找到了但没人回复？不合规。

2 欧盟CRA：不止要公示，还要"限时通报"

CRA（网络弹性法案）的要求比PSTI更进了一步——不仅要公示漏洞接受渠道，还要有漏洞通报的时限机制。

CRA的漏洞通报时限：

怎么查？欧盟市场的检查更严格：产品文档里有没有漏洞报告说明？官网有没有专门的漏洞披露政策页面？有没有接入ENISA的单一报告平台？你的内部流程能不能做到24小时响应？

3 澳大利亚智能设备标准：要求最细

澳大利亚的《智能设备安全标准》，对漏洞披露渠道的要求写得非常细。具体要求：

• 至少一个联系点——可以是邮箱、表单、专用页面
• 确认收到——收到漏洞报告后要回复确认
• 状态更新——处理过程中要持续更新进度，直到问题解决
• 免费提供——不能让报告者付费
• 不需要个人信息——不能要求报告者提供身份证、公司信息等
• 可访问、清晰、透明——不能藏在犄角旮旯里

为什么写这么细？因为之前查下来发现，很多企业的漏洞渠道就是个摆设：邮箱是个僵尸邮箱，发了没人回；表单藏得很深，找不到；要填一大堆个人信息才让提交。现在直接把规则写死，省得打擦边球。

点评：澳大利亚的要求简直就是"标准答案"——你照着做，其他国家的要求基本也都满足了。

4 日本JC-STAR：NIST框架里的"软实力"要求

JC-STAR的技术依据是NIST IR 8425，里面有一条能力叫"Information & Query Reception（信息与查询接收）"。要求：

• 要有明确的联系点接收漏洞报告和维护信息
• 要有响应用户安全查询的能力
• 支持bug bounty计划更好

这条在JC-STAR的STAR-1等级里，虽然不是"一票否决"的硬指标，但——你没有？审核人员会扣分。你有？审核人员会觉得你"专业"。同样的产品，一个有漏洞披露页面，一个没有，审核员选谁？

企业最容易栽的5个坑

1 坑一：根本没有这个页面

最常见的情况。很多企业的官网：首页是产品介绍，关于我们是公司介绍，联系我们只有销售电话、商务合作邮箱——唯独没有"安全"或"漏洞报告"这一页。审核人员一打开官网，找不到——直接判不合规。

建议：官网导航栏加一个"Security"或"Vulnerability Disclosure"入口。就这么简单。

2 坑二：有页面，但邮箱是个摆设

有些企业意识到了，加了个页面，但——邮箱根本没人看；表单提交了，永远收不到回复；页面写得很正式，但实际上没人负责这个事。

3 坑三：说明书里不提

法规要求的不只是官网，还有产品说明书、用户手册里也要提。很多企业只在官网做了页面，说明书里完全没提。审核人员翻说明书，找不到——不合规。

建议：在用户手册的"安全与隐私"章节，加一段："如发现本产品的安全漏洞，请通过以下方式与我们联系：security@xxx.com。我们将在X个工作日内确认收到，并持续向您更新处理进度。"就这么几行字，但必须有。

4 坑四：要求报告者提供一堆个人信息

澳大利亚标准明确说了——不能要求报告者提供个人信息。但很多企业的漏洞报告表单，一上来就要填：姓名、公司、职位、邮箱、电话、详细地址。安全研究者一看：我报个漏洞，你查我户口？直接放弃。

建议：表单越简单越好。至少要有：联系邮箱（可选）、漏洞描述。不要强制要：姓名、公司、电话、地址。让研究者可以匿名提交。

5 坑五：没有状态更新机制

澳大利亚标准要求——报告后要持续更新处理状态。不是说你收到报告就完事了，而是：收到了，要回复"已收到"；评估中，要告诉研究者"正在评估"；修复了，要通知研究者"已修复"；修复不了，要说明原因和缓解措施。

很多企业的认知还停留在——"我们有个邮箱能收漏洞就行"。现在的标准要求是——你要有完整的漏洞响应流程，而且这个流程要对外公开、可追溯。这不只是"挂个邮箱"的事了，是一个完整的安全运营体系。

背后的逻辑在变

1. 从"企业自查"到"社区共治"

以前的网络安全是企业自己关起门来搞。现在的趋势是——发动全球安全研究者的力量，帮你找漏洞。漏洞披露渠道，就是这个"全球安全社区"的入口。你有渠道，全球的白帽子都能帮你测产品。你没渠道，有漏洞人家也不知道找谁报。

2. 从"自愿"到"强制"

以前是"建议你做漏洞披露"。现在是"不做就不合规，就不能卖"。英国PSTI、澳大利亚智能设备标准、欧盟CRA——全都是强制要求。这不再是"加分项"，是"必答题"。

3. 从"有没有"到"好不好"

以前只要有个邮箱就算过。现在的要求越来越细——要确认收到、要更新进度、要限时响应、要保护报告者隐私。漏洞披露渠道，正在从"一个页面"变成"一套体系"。

到底要怎么做？

1. 现状评估

检查你官网、说明书、APP里有没有漏洞披露渠道；对照各国标准，找出差距；告诉你哪些市场已经不合规了。

2. 漏洞披露政策（VDP）设计

写一份专业的漏洞披露政策，明确报告渠道、响应时限、隐私保护；多语言版本（英、日、德、法等），符合PSTI、CRA、澳大利亚、JC-STAR的要求。

3. 官网页面搭建指导

漏洞披露页面应该放什么内容；怎么设计表单；怎么导航才能让审核员一眼找到。

4. 内部流程建设

收到漏洞报告后，谁来处理？怎么确认收到？怎么更新进度？怎么分级处理？怎么跟研发团队对接修复？

5. 对接Bug Bounty平台

如果你的产品已经有一定知名度，可以考虑接入HackerOne、BugCrowd等平台，设计方案、降低成本、提高效果。

写在最后

现在花点时间把这个小细节搞定，比以后被打回重来划算多了。