Unit 42用多模型持续找漏洞:单一模型命中率不到40%

|作者: QUASA 编辑团队|2 分钟阅读| 2
Unit 42用多模型持续找漏洞:单一模型命中率不到40%

Palo Alto Networks在 2026年9月22日的公告 中宣布,Unit 42 Continuous Frontier AI Defense已面向全球提供年度订阅,以Claude Mythos 5、GPT-5.6-Cyber及开放权重模型持续发现和验证企业系统漏洞,并提供修复建议。服务覆盖Web应用、API、云基础设施、源代码仓库和网络资产;不同订阅方案使用的模型组合可能不同。

Axios的同期报道 引述Palo Alto Networks的测试结果称,在复杂企业环境中,没有任何单一模型发现超过40%的漏洞,而Mythos 5与GPT-5.6-Cyber发现的问题重合率低于10%。原始表述是“不超过”,未排除恰好达到这一上界;这组数字也不是客户环境的实际防护率。多模型持续测试可以缩短两次定期测试之间的空档,但已公开的结果不足以证明它能全面替代渗透测试。

服务怎样把多模型用于持续测试

这项服务先对约定范围内的资产进行基线检查,随后在环境变化时继续测试。其多模型架构会把具体任务分配给相应模型,再结合Unit 42的威胁情报与攻防人员经验处理发现。这样做的理由是不同模型可能找到不同问题;模型数量增加本身并不能证明某个发现真实可利用。

公开的服务流程可以概括为一条连续的工作链:

  1. 扫描:在授权范围内寻找应用、接口、代码、云资源和网络资产的可疑暴露点。持续运行意味着资产或配置变化后仍会产生新的检查任务,而不是仅交付一次快照。
  2. 验证:对候选问题测试真实环境中的可利用性。模型提出的线索如果无法复现,就不应直接当作已经成立的漏洞交给开发团队。
  3. 攻击路径:检查分散的问题能否串联成端到端路径。单独看影响较小的缺陷,一旦与身份校验或会话处理问题相连,优先级可能改变。
  4. 修复:交付排序后的建议、代码层面的指引和虚拟补丁建议。建议进入报告,不代表客户的代码、配置或防护规则已经被修改。

这几个环节解决的问题不同。扫描扩大寻找范围,验证减少未经证实的告警,攻击路径说明问题如何产生业务影响,修复才会改变实际风险。厂商还提供将服务与Frontier Virtual Patching配合使用的方案:虚拟补丁可在正式补丁发布或部署前限制利用路径,但不能消除原有的代码或配置缺陷。企业仍须确认防护措施是否启用,以及根因修复后原路径是否已经失效。

厂商测试数据说明了什么

Unit 42的技术说明 称,其内部部署在三周内获得了相当于传统渗透测试一年所发现的结果;按产品统计,多模型架构发现的高危及严重漏洞为旧方法的3.2倍,工程团队的平均修复时间下降51%。这些是厂商内部环境中的比较,不能直接推算为购买服务后的客户收益,也不能把修复时间的变化单独归因于某一个模型。

单模型发现率和模型之间的低重合率,支持在同一流程中使用不同模型寻找线索,但没有给出组合后的完整检出率。要算出这一比率,必须先知道测试范围内实际存在多少漏洞,以及这些漏洞如何被确认;公开材料没有提供可供独立复算的完整样本与方法。重合少也可能受资产类型、任务分配和验证标准影响,不能直接推论为遗漏问题已经被补齐。

同样,发现更多高危问题与阻止更多攻击不是同一指标。前者描述测试产出,后者还取决于问题是否可利用、企业是否及时修复,以及修复后能否通过复测。尤其在持续测试中,重复发现、环境变化导致的失效证据和人工判定的误报都可能影响报告数量。评估服务效果时,应把已验证的攻击路径与已关闭的风险分开记录。

它能否替代定期渗透测试

持续测试最直接的价值是跟上变化:应用发布新版本、API增加入口或云配置调整后,原来的测试结论可能不再适用。定期渗透测试则通常围绕商定的目标、时间窗口和交付范围展开,便于对特定业务流程做集中检查。两种方式的覆盖频率不同,不能只凭持续运行这一特点判断其中一种已经涵盖另一种的全部工作。

决定能否减少现有测试,关键仍是实际授权范围。如果生产环境不允许某些验证动作,第三方系统没有测试许可,或关键业务流程未列入服务范围,持续扫描也无法补上这些缺口。涉及交易规则、角色权限和异常业务步骤的问题,还需要熟悉系统的人判断模型发现是否成立、能否造成实际损失。

持续执行还要求明确停止条件。验证动作可能触及真实账户、敏感数据或系统可用性,因此客户需要约定可用的测试账户、环境、时间及升级路径。服务能够提交代码建议或虚拟补丁建议,并不意味着供应商应自动获得生产环境的合并、部署和回滚权限。这些权限边界直接决定持续测试能运行到哪一步,也决定其报告能否替代既有测试交付物。

初创团队采购时要保留哪些权限

人员有限的团队尤其需要把模型能力与操作授权分开谈。该服务可能接触代码仓库、应用接口和云资产;采购时应要求供应商写明访问方式、数据处理范围、结果复核责任,以及订阅终止后的撤权程序。模型组合随方案变化,也意味着演示环境中的发现能力未必等同于实际购买的配置。

  • 测试范围:列出可测的应用、仓库、云账户和第三方资产,并写明新增资产由谁批准纳入。对可能影响生产业务的利用验证,单独约定允许的动作和停止条件。
  • 人工复核:要求高优先级发现附带受影响资产、复现前提和验证证据。对无法复现或业务影响有争议的报告,保留由客户安全与业务负责人共同裁定的渠道。
  • 变更控制:区分修复建议、生成的代码改动和实际部署。代码合并、配置调整、虚拟补丁启用及回滚均应由客户指定人员批准。
  • 数据边界:在合同中确认源码、凭据和遥测信息会进入哪些模型及处理环境、保存多久、能否用于训练,以及撤销访问后如何处理已有数据。
  • 效果验收:分别统计已验证的攻击路径、误报、修复后的复测结果和仍受环境限制而无法验证的问题,避免只按扫描次数或报告总数验收。

目前可以确认的是,这项年度订阅服务已推出,并以多模型、持续测试和攻击路径验证为核心能力。厂商测试为采用多模型提供了依据,但尚无足够公开数据证明它在不同客户环境中的完整覆盖率。传统渗透测试是否需要调整,仍取决于具体资产的测试权限、人工复核质量和修复结果。

相关阅读:

分享:

订阅我们的新闻通讯

将最新 Web3、AI 和加密货币新闻直接发送到您的邮箱。

0