华为给AI挖洞加上人工闸门

华为不再为未经验证的AI报告买单

华为正在给AI自动挖洞加上一道强制性的“人工闸门”。截至2026年10月14日，华为终端安全奖励计划最新处置规则已经明确：凡是由AI辅助或自动化发现的漏洞，提交前必须经过人工分析与验证；累计提交5份符合条件的无效报告，平台有权封禁账号。

这次调整针对的不是AI工具本身，而是AI降低报告生成成本后带来的审核资源挤兑。华为表示，今年收到了大量利用AI工具辅助挖掘的漏洞报告，其中多数附带PoC，但仍存在由AI“幻觉”造成的误报。换句话说，一份报告即使包含代码、调用链和看似合理的技术解释，也不代表漏洞真的存在。

AI辅助漏洞报告是指研究者使用大语言模型、智能体、静态分析或自动化测试系统发现、分析并生成的漏洞报告。 华为没有禁止这类报告，也没有要求研究者隐藏AI使用痕迹，而是把验收标准从“形式完整”提高到了“真实可复现、影响可证明”。

有PoC不等于漏洞成立

PoC（Proof of Concept，概念验证）是用于证明某个漏洞能够被触发的代码、脚本、请求数据包或复现步骤。 在传统漏洞报告中，能运行的PoC通常是可信度的重要指标；但在生成式AI参与后，PoC也可能只是“长得像代码”的文本，甚至会调用不存在的函数、已经废弃的接口或错误的系统组件。

华为此次规则的核心变化，是不再把“附带PoC”直接等同于“完成验证”。 提交者需要证明漏洞能够从真实攻击入口触发，并产生可观察、可重复的安全后果，而不是只展示一段可疑代码、一个崩溃日志或模型推导出的理论风险。

按照公告，AI辅助或自动化发现的漏洞报告至少需要覆盖以下信息：

• 动态可执行的完整PoC；
• 受影响的产品、系统版本与危害说明；
• 简洁、清晰且可以重复执行的复现步骤；
• 完整日志、结果截图或演示视频；
• 从实际攻击场景入口出发的攻击路径；
• 对实际安全影响的明确证明。

“动态可执行”是这套要求里最关键的限定词。 静态扫描器报出一个疑似越界访问，或者大模型根据局部代码推断出权限绕过，都只能算线索；研究者还要在真实或等价环境中触发问题，确认输入能够到达目标代码，并排除编译配置、调试环境、测试桩和异常配置造成的假象。

EXP（Exploit，漏洞利用）是能够进一步展示漏洞实际利用效果的攻击链或验证程序。 华为鼓励白帽子提供完整EXP攻击链，但公告的重点并不是要求每个研究者都交出武器化利用代码，而是要求报告证明漏洞会造成越权、信息泄露、代码执行、持久化控制或其他实际安全影响。

最新HarmonyOS版本成为验证基线

漏洞影响范围必须落在奖励计划覆盖的产品内，并且要基于已升级到最新HarmonyOS版本的设备或系统进行验证。 这一要求压缩了旧版本漏洞、过期接口和已修复问题重复进入审核队列的空间，也意味着仅在历史固件或非标准环境中触发的问题，未必符合奖励条件。

版本基线看似只是报告格式要求，实际上会显著增加AI自动化挖洞的工程门槛。模型可以从旧代码、历史CVE、公开补丁和过期文档中迅速拼出一条“可能存在漏洞”的路径，但它未必知道目标接口在最新版本里是否仍可调用，也无法仅凭文本判断运行时权限、沙箱隔离和补丁状态。

华为还特别点名了几类不规范报告：由AI直接生成且未经人工复现、没有通过最新可调用接口触发、只截取不完整代码片段进行分析，或者没有给出实际安全影响证明。它们的共同问题并非使用了AI，而是没有完成从“模型猜测”到“工程事实”的最后一公里。

| 报告类型 | 是否可能受理 | 华为关注的判断依据 | 主要风险 | |---|---:|---|---| | AI生成结论，未人工复现 | 否 | 没有真实运行结果 | 模型幻觉、接口不存在 | | 只有局部代码分析 | 通常否 | 缺少完整数据流和触发路径 | 忽略上下文、误判边界条件 | | PoC可运行，但仅制造异常 | 不一定 | 是否造成实际安全影响 | 普通崩溃被包装成高危漏洞 | | 在旧系统或失效接口上触发 | 通常否 | 最新HarmonyOS是否仍受影响 | 重复提交已修复问题 | | 完整PoC并经人工验证 | 可以 | 可重复触发、版本明确、证据完整 | 仍需平台进一步定级 | | 完整EXP攻击链 | 优先价值更高 | 从攻击入口到安全后果闭环 | 需要严格保密与负责任披露 |

三份提醒，五份可能封号

华为为批量提交无效AI报告设置了明确的阶梯式处置线。 对于由AI直接生成、未经人工复现或无法证明实际影响的报告，平台将直接驳回，并且不再逐一解释驳回原因。

具体来说，同一账号累计提交3份此类无效报告，平台将予以提醒；累计达到5份，平台有权封禁其华为安全奖励计划账号。与单纯降低报告优先级相比，这套机制把低质量提交从“审核问题”升级成了“账号信誉问题”。

| 累计情况 | 处置方式 | 对研究者的影响 | |---|---|---| | 单份无效AI报告 | 直接驳回 | 平台可不逐一解释原因 | | 累计3份无效报告 | 账号提醒 | 表明提交质量已经触及警戒线 | | 累计5份无效报告 | 有权封禁账号 | 可能失去继续参与奖励计划的资格 | | 辱骂、威胁、骚扰或恶意刷屏 | 可立即终止资格或永久封禁 | 处置可覆盖账号持有人、团队或组织 |

“不逐一说明驳回原因”同样是一项重要变化。漏洞审核原本包含事实确认、影响评估、重复性检查和奖励定级，如果审核人员还要为批量生成的无效报告逐份撰写技术解释，AI就会把低成本提交转化成平台侧的高成本人工服务。

这是一场明显不对称的成本博弈。 AI可能在几分钟内生成几十份结构完整的报告，但审核人员仍需准备设备、安装对应版本、配置环境、检查日志并追踪调用链；只要每份报告耗费数十分钟，批量误报就足以拖慢真正高危漏洞的响应。

账号封禁机制因此并不只是惩罚措施，更像是一种速率控制。它迫使提交者在点击“提交”前承担最基本的验证成本，避免把厂商审核团队当成免费调试器，也减少高价值报告被大量噪声淹没的概率。

华为没有否定AI挖洞

华为此次收紧的是报告质量，而不是AI漏洞挖掘能力。 今年6月公布的2025年度华为终端安全奖励计划榜单中，360漏洞挖掘智能体获得一等奖，并以22543分位居年度排行榜首位，这说明经过验证、能够推动实际修复的自动化成果仍然受到认可。

这个案例恰好揭示了AI挖洞的分水岭。真正有效的漏洞挖掘智能体不只是读取代码后生成一篇分析文章，而是需要完成目标识别、路径搜索、测试样本构造、运行时验证、结果去重和报告整理，并最终进入厂商确认与修复闭环。

AI可以扩大安全研究者的搜索半径，但不能替代漏洞成立所需的证据链。 对成熟团队而言，AI适合承担代码审计、污点路径筛选、变异样本生成和历史漏洞模式匹配；人类研究者则负责环境搭建、可达性判断、权限边界分析、危害确认和负责任披露。

这也意味着，未来更有价值的安全智能体将不再以“生成了多少条告警”为核心指标。报告有效率、漏洞去重率、最新版本复现率、攻击链完成度以及最终推动修复的数量，才是更接近真实防御价值的衡量方式。

DevEco等终端工具暂不受理，但有两个例外

华为已经从2026年9月30日起暂停受理一般性的终端工具漏洞。 公告以DevEco等工具为例，意味着针对开发工具自身、但无法进一步影响终端设备或供应链安全的问题，现阶段通常不会进入奖励计划的常规受理范围。

这项调整仍保留了两个重要例外：

1. 漏洞能够导致华为自研工具的公有仓遭受供应链投毒；
2. 攻击者能够借助该工具进一步影响华为终端设备安全。

供应链投毒是指攻击者通过篡改代码、依赖包、构建流程或发布渠道，将恶意内容植入下游软件和设备。 这类漏洞虽然最初发生在开发工具侧，却可能沿构建链扩散到大量应用或终端，因此仍具有明显的系统性风险。

工具类漏洞暂停受理与AI报告治理有相同的资源配置逻辑。开发工具暴露的输入面较大，静态扫描和大模型很容易产出大量疑似命令注入、路径穿越或配置风险；如果这些问题既无法触达真实供应链，也不能影响终端安全，其审核优先级自然会低于能够直接威胁用户设备的漏洞。

一份合格的AI辅助报告该怎么准备

研究者现在需要把AI输出当成待验证假设，而不是可以直接提交的结论。 比较稳妥的工作流，是先让模型帮助定位可疑路径，再由人工完成最小复现、版本核验、攻击面确认和影响评估。

提交前至少应该完成以下自查：

• 确认目标产品属于华为终端安全奖励计划范围；
• 在最新HarmonyOS版本或公告认可的最新环境中重新测试；
• 确认调用的是现实存在且当前可访问的接口；
• 从攻击者真实可控的入口开始，而不是直接修改进程内存或内部状态；
• 提供一套他人可以重复执行的完整PoC；
• 保存原始日志、终端输出、截图或连续演示视频；
• 解释漏洞突破了哪一层安全边界；
• 说明最终造成的数据、权限、执行流或设备安全影响；
• 排除重复漏洞、已修复问题和正常产品行为；
• 删除模型虚构的函数名、版本号、CVE编号与不可靠引用。

最容易被忽略的是“真实攻击入口”这一条件。 如果一段有缺陷的内部函数只能在调试构建中由开发者手动调用，普通攻击者无法控制输入，也没有外部组件能够到达该路径，那么它可能是代码质量问题，却不一定构成可利用的安全漏洞。

日志和演示视频也不能替代因果关系说明。 一次应用崩溃可能来自内存不足、测试环境异常或错误配置，研究者仍需证明恶意输入与结果之间存在稳定关系，并解释攻击者能够获得什么超出原有权限的能力。

Bug Bounty进入“机器发现、人工担责”阶段

华为的新规则代表漏洞奖励计划正在从鼓励自动化发现，转向管理自动化产出。 当发现疑点的边际成本接近于零，平台就必须提高证据标准、限制无效提交，并把稀缺的人工审核能力留给更可能成立的问题。

从厂商角度看，这次调整是必要且相对克制的。华为没有简单关闭AI报告通道，而是通过完整PoC、最新版本验证、实际影响证明和账号信誉约束建立质量门槛，既保留了自动化发现高价值漏洞的机会，也降低了“用报告数量碰运气”的收益。

从研究者角度看，AI带来的效率红利依然存在，但最终责任没有转移给模型。大模型可以写出专业术语齐全的报告，却不会为误报消耗的审核时间负责；真正提交报告的人，必须对版本、接口、复现过程和安全影响承担判断责任。

华为此次规则可以概括为一句话：AI可以参与发现漏洞，但不能替你证明漏洞。 对安全行业而言，这不是AI挖洞退潮，而是评价标准开始从“会不会生成报告”回到“能不能产生可验证、可修复的安全结果”。

参考来源

• IT之家：AI挖掘的漏洞报告存在误报，华为要求提交前进行人工分析和验证——整理了华为终端安全奖励计划对AI辅助报告、无效提交处置及工具类漏洞受理范围的最新要求。