补天对比复盘：一次漏洞提交全过程
补天对比直接联系厂商，究竟哪种漏洞报告方式更高效？本文通过一个经脱敏处理的SaaS越权漏洞案例，复盘从确认授权范围、整理证据、提交审核到厂商修复的全过程，并比较两条渠道在响应效率、沟通成本、奖励确定性和信息保护方面的实际差异。
步骤一：先比较渠道，不急着提交
案例对象是一家中型SaaS服务商，研究者在书面授权的测试环境中发现权限校验异常：普通测试账号可能访问不属于本账号的非敏感演示数据。此时可选渠道有两个，一是直接联系厂商安全邮箱，二是通过补天提交。前者路径短，但厂商没有公开SRC规则；后者多一层平台审核，却能留下完整的处理记录。
这次补天对比没有只看奖金，而是设置四项判断指标：厂商是否有稳定接收渠道、漏洞归属是否清晰、报告是否需要第三方协助核验、提交后能否持续追踪。由于厂商安全邮箱长期未维护，最终选择补天作为主要渠道，避免报告被普通客服工单淹没。
步骤二：控制验证范围并固定证据
研究者没有继续扩大测试，而是使用两个自有测试账号完成最小化验证，只记录请求时间、账号角色、受影响功能和脱敏后的响应差异。没有下载真实用户数据，也没有尝试批量遍历。这样既能证明问题存在，又能降低对业务和他人信息的影响。
这一步是两种渠道共同的底线。相关规定明确，不得利用漏洞危害网络安全，也不得违规发布漏洞细节或利用程序。换句话说，选择补天并不等于自动获得测试授权，授权来源、测试边界和数据处理方式仍需由研究者自行确认。([cac.gov.cn](https://www.cac.gov.cn/2021-07/13/c_1627761607640342.htm?Offer=ab_ss_reeng_plt_ctrl&utm_source=openai))
步骤三：按审核视角组织报告
报告没有堆砌截图，而是按“资产归属—触发条件—验证过程—实际影响—修复建议”排列。标题直接说明业务模块和权限问题，正文标注测试账号均为自有账号，并提供可重复但不会扩大影响的验证路径。修复建议则落到服务端鉴权、对象归属校验和访问日志排查。
补天官方帮助页显示，报告过于简单、缺少证据、无法复现、影响有限或与已有记录重复，都可能影响审核结果。因此，平台渠道更看重报告结构化程度；直接联系厂商则可能允许即时沟通补充，但前提是厂商确实有人接收。([butian.net](https://www.butian.net/newneed))
步骤四：经历平台与厂商两轮处理
提交后，报告先进入平台审核。审核人员要求补充资产归属说明，研究者通过产品页和企业主体信息完成对应，没有再次进行高风险测试。初审通过后，报告被转交厂商，厂商复核时又询问是否影响生产环境，研究者仅依据已有证据回答，没有为追求更高评级追加验证。
与直接邮箱相比，这一阶段的优点是状态清楚，研究者能区分待审核、待补充、厂商处理和奖励确认；不足是沟通经过中间环节，复杂业务漏洞可能需要更多文字解释。官方说明也表明，不同SRC类型的审核和奖励节奏存在差异，应以对应厂商计划的实时规则为准。([butian.net](https://www.butian.net/newneed))
步骤五：复盘最终差异与适用场景
厂商最终确认问题并完成修复，案例从提交到关闭经历了平台核验、厂商复审和回访确认。若该厂商拥有成熟SRC和稳定安全团队，直接提交可能更快；但在联系方式模糊、企业响应机制不成熟或需要第三方协调时，补天的流程记录和归属协助更有价值。
这次补天对比的结论不是谁绝对更好，而是渠道要匹配对象。成熟厂商优先遵循其官方SRC规则；未建立响应机制的厂商，可考虑合规漏洞平台；任何情况下都不应重复向多个渠道同时提交同一漏洞，更不能公开细节施压。效率来自证据清楚和边界克制，而非测试动作更多。
推荐阅读
常见问题
- 补天和直接提交厂商SRC有什么区别？
- 直接SRC通常沟通链路更短，适合规则成熟的厂商；补天增加平台审核和协调环节，更适合接收渠道不明确、未建立SRC或需要第三方核验的情况。
- 同一个漏洞可以同时提交补天和厂商吗？
- 不建议同时提交。重复报告容易造成归属争议和重复审核，应先阅读厂商规则，选定一个正式渠道，并保留完整的提交时间与沟通记录。
- 提交补天就代表获得测试授权吗？
- 不代表。平台提供的是报告和响应渠道，研究者仍须确认目标范围、测试规则及授权条件，只进行必要、低影响的验证。