AI批量提交来了，企业SRC怎么接？分级预筛、模板优化、内外部扫描区分实操

安全牛

2026年10月16日 14:28
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

点击蓝字 关注我们

写在前面

漏洞奖励计划本来是连接安全研究人员和企业的桥梁，但现在这个机制遇到了新麻烦——AI工具能批量生成漏洞报告了。Google最近暂停了开源软件漏洞奖励计划（OSS VRP）的部分提交，给所有企业敲响了警钟。

对中国企业来说，这事儿更紧迫。一边是《网络安全法》《数据安全法》等法规的硬性要求，一边是国产开源项目快速发展、企业数字化转型加速，建立有效的漏洞响应机制已经是绕不过去的坎儿。本文就从Google这个案例出发，聊聊AI时代，企业该怎么应对漏洞报告的\"质量危机\"。

一、Google为什么暂停了？

事情经过

Google暂停接收OSS VRP的产品漏洞报告，原因很直接：自动化提交的报告激增，但绝大多数验证后发现根本不成立。

不过暂停是有范围的：

• 供应链安全报告还能继续提交
• 2026年10月1日前提交的报告照常处理
• 其他漏洞奖励计划（像Google Cloud VRP）正常运行

这种\"精准打击\"的做法值得学习。面对报告量暴增，不是一刀切关门，而是找到压力最大的环节针对性调整。

OSS VRP是什么

这个计划2022年8月推出，覆盖Google维护的开源项目，包括Golang、Angular、Bazel这些大项目，还有关键的第三方依赖、GitHub配置等。奖金从100到31,337美元不等，重点关注供应链安全问题。

Google说正在重新调整计划，2027年第一季度会有更新。期间研究人员可以走其他渠道，比如Google Patch Rewards Program（最高奖励15,000美元）。

二、AI工具带来的双刃剑

改变了什么

静态分析、模糊测试这些自动化工具早就有了，但生成式AI带来的变化不一样：

门槛降低了：以前要深入理解代码才能写漏洞报告，现在AI几分钟就能生成看起来完整的描述。

效率提高了：批量分析代码、快速整理报告、自动化提交，一条龙。

规模放大了：一个人用AI工具，短时间内能提交几十上百份报告。

对中国企业来说影响更复杂。国内安全研究群体本来就庞大，补天、漏洞盒子、CNVD等平台活跃度高。但很多企业安全团队人手有限，验证能力跟不上报告数量的增长。

核心问题：数量不等于质量

Google说的\"绝大多数自动化提交无效\"，揭示了关键问题：报告多了，有效漏洞不一定多。很多报告存在这些毛病：

• 只有工具输出：直接粘贴扫描结果，没有人工分析
• 纯靠猜测：基于代码模式推测，没实际验证
• 无法复现：缺少触发条件和环境说明
• 影响不明：说不清楚攻击场景和实际危害

中国企业SRC团队面临的问题更现实：

• 每份报告都要工程师搭环境、分析代码、复现问题，成本高
• 同一问题被不同工具发现后重复提交
• 反复沟通确认细节，最后发现是误报

AI工具放大这些问题后，有限的安全资源被快速消耗，真正严重的漏洞反而因为\"排队\"延迟修复。

中国企业的特殊压力

相比国外企业，国内还有些独特挑战：

合规要求严：《网络安全漏洞管理规定》要求企业及时处理漏洞并上报，不能简单拒收。

SRC生态活跃：国内平台上研究者多，AI工具普及后批量提交可能来得更快。

开源用得多：大量使用开源组件，上游项目暂停接收时，下游企业暴露时间更长。

人才缺口大：网络安全人才缺口超过140万，审核资源本来就紧张。

三、不只是Google的问题

其他案例

curl项目：2025年1月，因为大量AI生成的低质量报告，直接结束了HackerOne上的赏金计划。

Intel：9月取消了Intigriti平台上的现金奖励，没说具体原因。

微软：虽没暂停，但5月提醒AI工具会增加运营压力。2025年单月发布了966个补丁，创历史纪录。

两个趋势

发现能力在扩大：工具确实能覆盖更多代码，发现更多问题。

验证能力在承压：验证、分级、修复的工作量增长可能超过发现速度。

关键不是\"能发现多少\"，而是\"能有效处理多少\"。

真正的安全收益取决于：

• 问题是否及时验证
• 风险是否准确评估
• 修复是否有效执行
• 经验是否转化为能力

漏洞奖励的价值

Google从2010年至今，已经支付超过8,160万美元。仅2025年就发了1,710万美元给700多名研究人员，比2024年增加40%。

这说明两点：漏洞奖励计划仍然重要；暂停部分提交是在寻找受理能力和报告质量的新平衡。

对建设SRC的中国企业：这不是\"设立就完\"的面子工程，而是需要持续投入、动态调整的运营体系。

四、研究人员怎么提交高质量报告

AI工具可以用来扩展排查范围，但提交前的验证不能省。以下做法能提高报告质量：

1. 说清楚影响范围

报告应该包括：

• 具体的产品、服务、代码仓库
• 受影响的版本号或范围
• 文件路径、函数名、行号
• 运行环境和特殊配置

反例：\"你们系统有SQL注入\"——太宽泛，没法定位。

正例：\"用户管理模块（/api/v2/users）处理'username'参数时存在SQL注入，影响版本3.2.0至3.5.1\"——清晰、可验证。

2. 给出复现步骤

这是报告核心，应该包括：

• 前置条件（需要什么权限、账户）
• 详细操作步骤
• 具体的输入内容和参数
• 预期行为 vs 实际行为

示例：

1) 普通用户登录（[email protected] / Test123）

2) 访问 https://target.com/api/profile

3) 修改Cookie中user\_id为2（管理员ID）

4) 刷新，发现能访问管理员信息

5) 预期：系统应验证user\_id，拒绝访问

6) 实际：直接返回了管理员敏感信息

3. 解释安全影响

不要只粘贴扫描结果，要说明：

• 攻击者能做什么
• 需要什么条件
• 影响哪些资产
• 造成什么后果

不够的描述：\"发现XSS漏洞\"

充分的描述：\"搜索功能存在XSS，攻击者可构造链接窃取Cookie，以受害者身份操作。页面无CSP保护且Cookie未设HttpOnly，利用成功率高。\"

对中国企业，还要考虑监管环境。涉及个人信息的应说明可能触及《个人信息保护法》哪些条款。

4. 标明验证边界

诚实说明验证限度：

• \"理论上可导致RCE，但我未构造完整利用链\"
• \"仅在Windows测试，Linux未知\"
• \"可能存在竞态条件，但难以稳定复现\"

区分\"已证实\"和\"待确认\"，帮助团队合理分配资源。

5. 选对提交渠道

不同类型走不同渠道：

• 业务漏洞 → 主站SRC
• 开源组件 → CNVD/CNNVD
• 供应链问题 → 特别标注
• 合规问题 → 专门通道

政策调整时及时更新提交策略。

五、企业如何维护有效机制

1. 维护清晰的披露政策

政策应该说明：

• 受理哪些产品和系统
• 漏洞如何分类
• 必须包含哪些信息
• 处理流程和时间预期
• 奖励标准
• 特殊情况说明

定期审查更新。参考Google，把\"产品漏洞\"\"供应链问题\"\"配置审查\"分开受理，配置不同的响应流程。

2. 优化报告模板

好的模板能在提交时就引导提供必要信息：

【漏洞标题】：简洁描述（不超过50字）

【影响产品/服务】：名称和版本

【漏洞类型】：SQL注入/XSS/越权等

【复现步骤】：详细列出

【预期行为】：应该怎样

【实际行为】：实际怎样

【安全影响】：攻击者能达成什么

【测试环境】：系统、浏览器等

【验证限制】：未测试的场景

\"安全影响\"和\"验证限制\"特别重要——它们需要人工判断，不是简单复制工具输出。

3. 建立分级机制

快速预筛：经验丰富的工程师快速判断基本要素，不完整的退回补充。

风险分级：

• P0（紧急）：已被利用的0day、核心业务高危漏洞
• P1（高优先级）：可复现、影响明确、风险高
• P2（中优先级）：需进一步验证或影响有限
• P3（低优先级）：信息类、理论风险

自动化辅助：用规则或AI辅助筛查，但最终判断要结合人工验证。例如自动识别重复报告、标记缺少关键信息、检测批量提交模式。

关键原则：确保高风险问题能优先处理。

4. 区分内外部扫描

内部扫描：企业自己用工具扫描，结果进内部流程，由团队批量处理。

外部报告：应该已经过提交者验证。批量扫描结果不应未经验证就提交。

SRC规则可以明确：\"本平台接收经过验证的漏洞报告。单纯的工具输出不符合标准。批量提交相似问题的，我们保留调整优先级或暂停接收的权利。\"

5. 建立运营指标

质量指标：有效率、重复率、验证耗时、误报率

效率指标：接收到确认时间、确认到修复时间、积压数量、处理能力

影响指标：高危漏洞数、避免的事件、研究人员活跃度、投入产出比

数据驱动识别瓶颈，针对性优化。即使Google这样成熟的计划也在持续调整。

六、给中国企业的特别建议

兼顾合规与效率

《网络安全漏洞管理规定》要求及时处理，不能简单拒收。可以这样平衡：

• 不同来源设置不同流程
• 通过详细要求筛选高质量报告
• 对必须处理的报告（已公开、已利用）设最高优先级

重视供应链安全

上游项目暂停接收时，下游企业风险窗口延长。建议：

建立组件清单（SBOM）

• 监控关键依赖的变化
• 建立替代报告渠道
• 培养内部验证修复能力

培养验证能力

不要把SRC指标设为\"报告数量\"\"注册人数\"。应该关注：

• 有效漏洞率
• 高危漏洞发现数
• 平均修复时间
• 重复发现率（越低越好）

投入资源培养内部能力：安全测试技能、自动化验证环境、知识库建设。

保持社区互动

• 及时反馈报告状态
• 调整规则提前公告
• 认可高质量贡献
• 定期交流学习

良好的社区关系能在调整时获得理解，也有助于吸引人才。

写在最后

Google暂停OSS VRP部分提交，不是否定AI或研究社区，而是在新环境下调整机制。对中国企业的三个启示：

第一，自动化扩大发现面，但验证能力决定收益。AI能发现更多线索，但只有验证、评估、修复到位的漏洞，才能转化为真正的安全改进。不要追求\"收到多少报告\"，要关注\"修复了多少风险\"。

第二，漏洞响应是持续运营的体系。要根据外部环境（工具、法规、威胁）和内部能力（人员、流程、资源）持续调整。Google这么有经验的企业也在动态优化，中国企业更应建立灵活机制。

第三，质量优先是长期方向。能被复核、能说明影响、能导向修复的报告，永远比数量堆积更有价值。AI工具普及后，行业会更重视\"验证过的有效发现\"，而不是\"可能存在的潜在问题\"。

对经历数字化转型、面临严格监管的中国企业，现在正是优化漏洞响应机制的好时机。通过提高质量要求、优化流程、培养能力、加强互动，不仅能应对AI时代挑战，更能建立真正有效、可持续的安全治理体系。

安全研究的价值，从来不在于发现多少\"疑似问题\"，而在于修复多少\"真实风险\"。让我们回到\"有效影响\"这个本质，共同推动中国网络安全生态向更健康、更专业的方向发展。

相关阅读

沙箱“未发现威胁”≠文件安全：60%定向攻击样本会装乖，一线分析师别被干净报告骗了

【重磅发布】安全牛《自主智能体Agentic AI风险治理与安全应用指南》

AI说91.5%高危，维护者只认51.3%：漏洞定级这活儿，为什么还是离不开人？

联系我们

合作电话：18610811242

合作微信：aqniu001

联系邮箱：[email protected]