企业漏洞接收应建合并台账

多平台并行接收漏洞报告，已经成为企业安全团队的常态。同一条漏洞可能同时出现在不同渠道，也可能只出现在其中一个渠道，靠人工逐个平台盯守，漏报几乎是必然结果。行业自律框架逐渐对齐之后，平台的接收规则在趋同，但企业内部的接收侧却没有同步改造，二者的落差才是风险的来源。

台账要解决的不是记录，而是去重与追踪

合并台账的核心价值在于整合报告的处理闭环，并非简单地把各平台转来的报告贴进一张表。一条漏洞从进入企业视野开始，需要回答几个问题：它最初来自哪个平台、是否已被其他平台重复报送、当前由谁负责、验证结论是什么、修复结果是否已经回传。缺少统一台账时，这些信息分散在不同邮箱、工单和即时通讯群里，重复报送导致重复排期，而真正需要升级的漏洞又可能因为没人认领而停在原地。

在NVDB与CNVD、CNNVD等渠道长期并存的背景下，这种去重需求尤其明显。不同平台在收录标准和验证深度上存在差异，同一漏洞在不同渠道的描述完整度可能不同，合并台账应当保留来源字段，避免在合并时丢掉关键上下文。

入口收敛不等于渠道唯一

企业容易走向另一个极端：只保留一个接收邮箱，把其他渠道全部关闭。这在多平台并行的现实下并不现实，研究者习惯的报送路径不会因为企业内部的偏好而改变。更可行的做法是在接收端设置统一的归集层，无论报告从哪个平台、哪个邮箱或哪位员工转来，都先进入同一个记录队列，再按统一规则编号、分级、指派。入口可以多，但记录点必须唯一。

台账字段的设计应服务于后续动作，而不必追求字段数量。来源平台、报送时间、重复标记、责任人、验证状态、修复状态、回传状态，这几项足以支撑大多数企业的日常追踪。字段之外，更重要的是明确响应时限和内部升级路径，否则台账只会变成一份持续变长、无人回看的清单。

回传是台账闭环的最后一环

修复结果回传经常被忽略，却直接影响后续报送质量。提交者能否得知漏洞被确认、被修复，决定了他们下一次是否愿意继续通过正规渠道报送。合并台账应当把回传动作纳入状态记录，让每一条已修复漏洞都有可查证的闭环证据。对历史报送记录做一次回溯，确认哪些漏洞真正完成了闭环，是当前阶段成本较低、收益明确的准备工作。

自律公约的细则尚未完整公开，企业不必等待具体条款落地再动手。先把跨平台报告的归集、去重、指派和回传跑通，让流程进入可追溯状态，等规则进一步明确时再调整细节，比事后补课更从容。