思科开源Antares，专攻漏洞定位

思科把安全模型做小了，也把任务边界收窄了

思科近日开放了 Antares 系列小语言模型的 350M 和 1B 参数版本，并计划继续推出 3B 版本。Antares 不追求通用编程能力，而是专门解决一个安全团队经常遇到、又极其耗时的问题：已知某类漏洞可能存在时，应该先检查代码库中的哪些文件。

**Antares 是一组面向漏洞定位任务的小语言模型，其核心能力是根据 CWE 类型及漏洞描述，在代码库中搜索并输出值得人工检查的文件和依据。**按照思科公布的信息，350M 与 1B 权重已上线 Hugging Face，3B 版本仍在后续发布计划中。

这不是一个会自动挖出未知零日漏洞的模型，也不是能独立完成代码审计、漏洞验证和补丁生成的安全智能体。思科把 Antares 的能力边界划得相当清楚：安全人员需要先给出 CWE 漏洞类型和相关描述，模型再借助终端命令检索代码库，最终生成检查报告。

漏洞定位不是漏洞发现

**漏洞定位（Vulnerability Localization）是根据已有漏洞类型或问题描述，从代码仓库中筛出最可能包含缺陷的文件、函数或代码区域。**它解决的是“去哪里看”，而不是“这里一定有漏洞”。

两者的差异直接决定了 Antares 应该如何使用。未知漏洞发现需要模型识别此前没有明确描述的危险行为，往往还要结合数据流、控制流、依赖关系、运行时状态和攻击面分析；漏洞定位则已有一个相对明确的假设，例如路径遍历、命令注入或权限检查不当，模型的任务是缩小人工审计范围。

**CWE 是由 MITRE 维护的软件与硬件弱点分类体系，用于描述漏洞背后的通用缺陷类型。**CWE 与 CVE 并不等价：CVE 通常对应某个具体产品中的已披露漏洞，CWE 则描述产生漏洞的缺陷模式。Antares 接收的是 CWE 类型及相关描述，这意味着它更像一个带有安全领域知识的代码检索员，而不是漏洞裁判。

一个典型场景是，企业安全团队已经通过威胁情报或历史事故确认某个项目可能存在 CWE-78 命令注入风险。面对数千个文件，工程师没必要从目录第一行开始阅读；Antares 可以先寻找外部输入、Shell 调用、参数拼接和过滤逻辑，将候选范围压缩到更小的文件集合，再交给分析工具和人工验证。

这个定位很务实，因为大型代码库中最昂贵的环节往往不是看懂一段危险代码，而是找到那段代码。

1B模型召回率22.4%，只比GPT-5.5高0.3个百分点

**思科的漏洞定位基准包含 290 个真实代码库、147 种 CWE 类型和 500 项测试任务。**这组测试覆盖的不是单一语言、单一项目或少数几类常见漏洞，因此比只测试几十个手工样例更接近实际安全审查环境。

思科披露的结果显示，Antares-1B 在漏洞文件检出率上达到 22.4%，在参与测试的模型中排名第一；GPT-5.5 的对应成绩为 22.1%，两者相差 0.3 个百分点，Antares-1B 的相对领先幅度约为 1.36%。

**召回率（Recall）是实际漏洞文件中被模型成功纳入候选结果的比例。**如果一项任务包含 100 个应被找到的漏洞文件，22.4% 的召回率意味着模型平均只能覆盖其中约 22 个，而不是能正确处理 77 个或成功率达到八成。

| 模型 | 参数规模 | 发布状态 | 漏洞文件召回率 | 部署方式 | 主要定位 | |---|---:|---|---:|---|---| | Antares-350M | 3.5亿 | 已发布 | 官方未披露 | 可本地部署 | 极轻量漏洞定位 | | Antares-1B | 10亿 | 已发布 | 22.4% | 可本地或内网部署 | 漏洞文件筛选与审查辅助 | | Antares-3B | 30亿 | 计划发布 | 尚未披露 | 预计支持本地部署 | 更高容量的漏洞定位 | | GPT-5.5 | 参数未公开 | 闭源服务 | 22.1% | 云端服务 | 通用模型参与专项测试 |

这个结果值得关注，但不值得神化。Antares-1B 的确以约十亿参数取得了专项榜首，说明任务收窄、领域数据和工具使用方式能够弥补参数差距；但 0.3 个百分点处在非常接近的区间，如果没有多次运行方差、置信区间和完整提示配置，就不能据此断言 Antares 在漏洞定位上稳定击败 GPT-5.5。

**22.4% 的绝对召回率也意味着 Antares 仍会漏掉多数目标文件。**对于安全审计而言，漏报通常比多报更危险，因此它不能成为代码合并、版本发布或合规检查的唯一闸门。更合理的用法是把它作为并行信号：模型给出候选文件，静态分析器提供规则命中，依赖扫描器检查组件风险，最后由安全人员综合判断。

350M模型的价值，不是跑分第一

**Antares-350M 的真正卖点是部署成本和响应位置，而不是追求最强推理能力。**3.5 亿参数已经小到可以进入开发者工作站、企业内网服务器和受控 CI 环境，而不必把完整私有代码库发送到外部模型服务。

在常见的半精度权重估算下，350M 模型仅参数本身约占 0.7GB，1B 模型约占 2GB；如果进一步使用 8bit 或 4bit 量化，参数存储还可以继续缩小。实际运行仍需额外计算 KV Cache、推理框架、上下文和工具调用开销，因此这些数字不能直接等同于完整显存需求，但足以说明 Antares 与数十亿、数百亿参数通用模型不是同一种部署负担。

本地部署对安全团队尤其重要，因为源代码、内部目录结构、未发布功能以及漏洞线索本身都是敏感资产。将模型放进企业内网，可以减少代码出域范围，也便于接入权限控制、审计日志、隔离执行环境和已有的安全开发流程。

小模型还有一个容易被忽视的优势：它更适合被高频调用。代码仓库可以在每次合并请求、版本分支更新或漏洞规则变化后重新扫描，而不必把每次审查都变成一次昂贵的通用大模型会话。

不过，本地运行不自动等于安全。模型可能执行终端搜索命令，企业仍需限制其文件访问范围、网络访问、命令白名单和输出权限，避免恶意仓库通过提示注入诱导模型读取凭据、环境变量或其他项目文件。

Antares更像“安全版代码搜索”，而不是AI审计员

**Antares 的产品形态更接近会理解 CWE 语义的代码搜索助手。**传统关键词检索只能寻找函数名、危险 API 或固定字符串，静态分析器依赖预先编写的规则，通用大模型则可能理解问题但部署成本较高；Antares 试图站在三者之间，用小模型理解漏洞描述，再通过终端工具完成仓库级搜索。

这种设计对多步骤任务很有用。某个身份验证绕过问题未必集中在一个文件中，入口路由、权限中间件、配置开关和测试代码可能分散在不同目录；单纯搜索“auth”会产生大量噪声，而模型可以围绕 CWE 描述调整查询方向，逐步建立候选文件列表。

但 Antares 输出的“检查报告”仍然只是调查起点。报告至少需要回答候选文件为何相关、使用了哪些搜索条件、遗漏风险在哪里，以及结果是否能复现；如果只输出一串文件名，安全团队很难判断它是基于代码语义、目录命名，还是训练数据记忆做出的选择。

对企业来说，Antares 最合适的落点不是替换现有扫描器，而是插入安全开发生命周期中的人工审查环节：

1. 由漏洞情报、红队报告或历史缺陷提供 CWE 类型和问题描述；
2. 由 Antares 在受控环境中检索仓库并生成候选文件；
3. 由静态分析、污点追踪和依赖分析验证候选路径；
4. 由安全工程师确认可利用性、影响范围和修复优先级；
5. 修复后再通过测试、扫描与代码评审完成闭环。

开放权重不等于可以直接进入生产

Antares 在 Hugging Face 发布模型权重，降低了企业试验门槛，但生产使用仍需核对模型卡、许可证和评测条件。“开源模型”在行业传播中经常被用来泛指可下载权重，严格意义上的开源还涉及训练代码、数据可得性、许可证限制和再分发权利，企业不应只看到下载按钮就默认没有合规成本。

安全团队还需要重点验证模型在自身技术栈上的效果。思科基准覆盖 147 种 CWE，但不同企业的代码语言、框架、单体仓库结构和内部封装差异很大；公开项目上的 22.4% 召回率，不能直接外推为某个 Java 微服务集群、嵌入式 C 项目或大型 TypeScript 单仓的实际成绩。

更可靠的上线方式是先建立内部回放集。企业可以选取已修复漏洞及对应提交，隐藏修复位置后让 Antares 进行定位，再分别统计文件级召回率、候选数量、误报率、单任务耗时和人工节省时间。只有当模型能稳定减少审查成本，同时不让关键漏洞漏报率恶化时，才值得接入持续集成流程。

它不能替代SBOM、动态测试和人工审查

**SBOM 是列出软件所包含组件、版本及依赖关系的软件物料清单。**Antares 主要阅读和搜索代码，并不能替代 SBOM 与软件组成分析；如果漏洞来自第三方依赖、容器基础镜像或构建产物，模型可能根本看不到真正的风险来源。

思科也明确表示，完整的软件安全防护仍需要结合依赖组件分析、软件组成分析、敏感信息扫描、动态安全测试、威胁建模、漏洞修复和人工安全审查。原因很直接：这些手段观察的是不同层面的证据，任何单一模型都无法覆盖代码、依赖、配置、运行时行为和业务权限的全部攻击面。

一套更完整的组合应该包括：

• 静态应用安全测试：检查源码和数据流中的危险模式；
• 软件组成分析与 SBOM：发现第三方组件及供应链漏洞；
• 敏感信息扫描：识别令牌、证书和口令误提交；
• 动态安全测试：在运行状态下验证输入、权限与响应行为；
• 威胁建模：从业务资产和攻击路径判断风险优先级；
• 人工代码审查：确认漏洞是否真实、是否可利用以及如何修复；
• Antares 类定位模型：缩小人工搜索范围，提高前述环节的衔接效率。

小模型正在进入“窄任务胜过大模型”的阶段

**Antares 最有价值的信号，是安全模型竞争开始从“谁更聪明”转向“谁更适合嵌入流程”。**一个 1B 模型在思科专项基准上以 22.4% 略高于 GPT-5.5 的 22.1%，并不能证明小模型全面优于大模型，却足以证明企业不必为每个任务都调用参数规模最大的通用系统。

领域小模型可以把能力集中在明确输入、固定工具和可评价输出上。漏洞定位的输入是 CWE 与问题描述，工具是终端搜索，输出是候选文件和报告，评价指标是实际漏洞文件召回率；这种任务闭环比“让模型全面审计整个仓库”更容易训练、测量和部署。

Antares 当前最明显的短板依然是绝对效果有限。22.4% 的召回率意味着它适合作为第二双眼睛，却远未达到无人值守水平；未来 3B 版本能否在保持本地部署优势的同时显著提高召回率，以及是否会带来更多无关候选文件，将决定这个系列能否从研究项目走向企业安全流水线。

思科这次没有造一个“自动黑客”，而是做了一个目标明确的代码库排查助手。这个方向不够炫，但对每天需要在庞大仓库里追踪漏洞线索的安全工程师来说，可能比又一个会聊天的通用模型更实用。

参考来源

• IT之家：思科推出 Antares 小语言 AI 模型，专为定位漏洞设计——整理了模型规模、发布计划、使用方式及思科基准测试结果。
• Hugging Face：Cisco Antares 相关模型检索页——用于查找 Antares 模型权重、模型卡、许可证与后续版本更新。