AI 正在改变漏洞被发现和利用的速度。我们根据自身的研究成果和安全实践，发布一系列初步建议，帮助您加固防御体系。

• 分类

  智能体
• 产品

  Claude 企业版
• 日期

  2026 年 4 月 10 日
• 阅读时间

  5

  分钟
• https://claude.com/blog/preparing-your-security-program-for-ai-accelerated-offense

本周早些时候，我们发布了 Project Glasswing——这是我们的一项紧急行动，旨在将最新前沿模型 Claude Mythos Preview 的强大网络安全能力用于防御目的。在该公告及随附的技术博文中，我们描述了 AI 模型如何迅速降低发现和利用软件漏洞所需的资源、时间和技能门槛。

考虑到 AI 的飞速进步，我们还指出，具备类似能力水平的模型很快将广泛可用。在未来 24 个月内，大量可能已在代码中潜伏数年未被发现的漏洞，将被 AI 模型发现并串联成可用的攻击链。事实上，目前公开可用的、能力低于 Mythos 级别的模型，已经能够发现传统审查长期遗漏的严重漏洞。

幸运的是，这是一把双刃剑：虽然攻击者可以利用 AI 加快速度，但采用 AI 工具进行自我防护的防御者同样可以提速。在这篇文章中，我们基于安全团队和研究人员在使用前沿 AI 模型保护真实代码库和系统过程中的观察与经验，提供安全建议和实用技巧。随着我们进入 AI 驱动的网络安全时代，希望安全团队及其他相关人员能从中获得有益参考。

以下许多建议已是现有安全共识的一部分；我们根据哪些控制措施经得起考验、哪些已经失效，对其进行了优先级排序。如果您的组织已参照 SOC 2 和 ISO 27001 进行报告，这些建议将直接对应到您已在跟踪的控制项。

随着我们和 Project Glasswing 合作伙伴继续推进网络安全工作，我们将持续更新本指南。

当前应做之事

1. 缩小补丁缺口

AI 模型在识别未修补系统中已知且已修复漏洞的特征方面非常有效。将补丁逆向还原为可用的利用代码，正是这些模型擅长的机械式分析。这意味着，从补丁发布到利用代码出现之间的时间窗口正在缩短。

• 立即修补 CISA 已知被利用漏洞（KEV）目录中的所有内容。该目录包含确认正在被积极利用的漏洞。任何可从网络访问到此列表中的项目都应被视为紧急情况。
• 使用 EPSS 对剩余漏洞进行优先级排序。利用预测评分系统（EPSS）提供每日更新的概率，预测某个特定通用漏洞披露（CVE）在未来 30 天内被利用的可能性。先修补 KEV 列表，然后修补高于所选 EPSS 阈值的所有内容，这将帮助你将数千个未处理的 CVE 转化为可管理的队列。
• 缩短面向互联网系统的补丁修复时间。我们建议在利用代码出现后的 24 小时内修补面向互联网的应用程序，并在数天内修补其他漏洞。
• 在自动更新导致中断的风险可接受的情况下，自动化补丁部署和重启。手动审批步骤会增加延迟，而延迟现在已成为主要风险。

实用提示：大多数云和操作系统供应商已提供补丁自动化功能；启用它通常只是一个简单的配置更改。对于容器镜像和依赖清单，有多个开源扫描器可作为单个持续集成步骤运行，并使用 KEV 目录和 EPSS 的数据对 CVE 进行标注，因此优先级排序已内置其中。

2. 准备处理数量大幅增加的漏洞报告

在接下来的大约两年内，你用于接收、优先级排序和修复漏洞（无论是在你自己的代码中，还是在从供应商处购买的软件中）的流程将面临比今天大得多的压力。你的漏洞管理流程应计划从供应商和上游接收更多补丁。

• 为发现量的数量级增长做好规划。接收、分类和修复跟踪等环节需要跟上不断增加的漏洞暴露数量。如果你的安全会议仍然围绕电子表格和每周例会展开，那么你很可能无法跟上节奏。值得考虑引入一定程度的自动化——当然，需要有人类参与其中，以协助处理如此庞大的工作量。
• 检查你的开源依赖项的安全性。大多数软件供应链主要由开源组件构成。大多数开源项目没有服务级别协议，也没有承诺维持高水平的安全性。OpenSSF Scorecard 会根据分支保护、模糊测试覆盖率、签名发布和维护者活跃度等信号，自动为每个依赖项评分。它运行在 CI 中，有助于识别无人维护的软件包。
• 对你的供应商提出同样的期望。你的第三方风险管理流程应询问供应商，他们自身如何为加速的漏洞利用时间线做准备，以及他们是否在扫描自己的代码。

实用提示：研究那些能够评估易受攻击代码可达性的开源软件和第三方服务。构建自动化流程，通过对更新进行回归测试来建立信心，从而能够快速部署，持续向你的 IT 和生产基础设施交付新的软件更新。

上文我们提到了这些流程的自动化。人工智能可以在以下几个重要方面提供帮助：

• 加快分类速度。分类是一个瓶颈，因为它需要专家审查和分类。前沿模型可以针对现有积压任务对发现结果进行去重，利用其对你的资产的了解来评估暴露风险，并在预先识别受影响代码路径的情况下起草修复工单。
• 检查依赖项是否存在冗余。大多数大型代码库会累积多个实现相同功能的库（例如多个 HTTP 客户端、多个 JSON 解析器）。这给攻击者提供了更多机会，而对你却没有任何功能上的增益。让大语言模型分析锁定文件，询问哪些依赖项存在重叠（以及迁移和整合工作会是什么样子），这是一项只需一小时就能完成的工作，而且通常回报丰厚。
• AI 升级自动化。前沿模型越来越有能力生成补丁，并将其与漏洞报告一同提供。当报告清晰且详尽，甚至可能包含概念验证时，模型可以直接测试补丁，以确认漏洞利用路径已被封堵。它还可以直接自动化处理上游补丁的接收流程，验证升级不会破坏测试或内部系统。
• AI 供应商锁定规避。一些小型依赖项在 OpenSSF 评分卡上得分很低——可能是因为它们没有得到积极维护。你不应继续依赖这些依赖项；相反，你应该考虑让大语言模型自行编写代码，重新实现你实际使用的功能。

3. 在发布前发现漏洞

预防总是胜于补救。你应该假设，进入生产环境的漏洞最终都会被找到，因此你的安全测试需要提前进行。

• 在你的持续集成流水线中加入静态分析和 AI 辅助代码审查，并对高置信度的发现结果阻止合并。如果误报导致此方法不切实际，你应保留检查，但需要改进相关工具。OWASP 应用程序安全验证标准定义了在三个不同严格级别下“通过”测试的标准。
• 在你的持续交付流水线中加入自动化渗透测试。你可以对预发布环境运行与攻击者针对你的生产系统相同的扫描。
• 保护构建流水线。能够在代码提交和部署之间注入代码的攻击者无需寻找漏洞。SLSA 安全框架提供了一条分级路径：较低级别用于确定哪个提交产生了哪个工件，而更高级别则使构建过程本身可被验证。
• 采用“安全设计”实践。CISA 的承诺清单（默认启用多因素认证；无默认密码；透明的漏洞报告机制）是一个合理的最低门槛。
• 新代码优先使用内存安全语言。大量严重漏洞属于内存安全问题，这类问题在 Rust、Go 或托管运行时中不会出现。CISA、NSA 和 NCSC 已发布实用的路线图。现有的 C/C++ 代码无需重写，但新增的 C/C++ 代码应提供正当理由。借助 AI 辅助进行重写也日益可行。

实用建议：基于 OWASP Top 10 和特定语言规则集、作为 CI 动作运行的静态应用安全测试（SAST）工具已广泛可用，既有开源方案，也内置于代码托管平台（GitHub 上的 CodeQL 是最常见的起点）。为评估构建来源，OpenSSF 发布了一个可复用的工作流，可从 GitHub Actions 生成 SLSA Level 3 认证；采用该工作流的工作量远低于 SLSA 规范所暗示的程度。

与之前一样，在利用 AI 加速这方面工作方面存在一些明确的机会：

• AI 漏洞扫描。这里的逻辑很直接：你应该在攻击者之前，用他们可能使用的同类模型来扫描自己的代码和系统。这种方法只需要一个隔离的智能体、一个用于过滤噪声的验证步骤，以及一条接入现有分类处理流程的路径。你现在就可以用一个大语言模型来实现这一点。如果你要从本节中实施一件事，那就实施这个。
• 补丁生成。当 SAST 或扫描器发现一个问题时，前沿模型通常可以为其提出一个补丁。这并不能省去审查环节，但它将开发者的工作从“理解 bug 并编写修复方案”转变为“验证提出的修复方案是否正确”。后者速度更快。同样的方法也适用于内存安全迁移：大语言模型可以将一个独立的 C 模块连同测试一起移植到 Rust；审查者可以验证两者的等价性，而无需从头编写所有内容。

4. 找出代码中已有的漏洞

补丁能修复你所依赖软件中的已知漏洞，但你自己的代码库中却存在未知漏洞。大多数长期运行的生产代码已被人工审查过多次，但从未经过前沿模型的检查，而这种分析往往会发现新的、此前被忽视的问题。主动扫描可以在攻击者自己发现漏洞之前，识别出现代大语言模型能够触及的漏洞。

• 按暴露程度确定优先级。从解析不可信输入、执行身份验证或授权决策、或可从互联网访问的代码开始。这些路径上的发现最有可能产生实际影响。
• 包含遗留代码。早于当前审查实践、或原始作者已离职的代码，通常受到的近期审查最少。这正是你通过重新审查能获得最大收益的地方。
• 为修复工作预留预算。对旧代码进行结构良好的模型扫描，通常产生的发现数量少于SAST部署，但其中真实问题的比例更高。请规划工程时间来修复这些缺陷。

实用建议：选择一个当前维护者较少的面向互联网服务，扫描其输入处理和身份验证逻辑。在隔离环境中运行智能体，并添加验证步骤，确保你只对确认的发现采取行动。妥善完成一个服务，是估算更广泛项目成本的合理基础。

5. 为入侵设计

攻击者会试图在某处获得立足点。你需要限制他们从那里能触及的范围。

那些价值来源于制造摩擦——让攻击变得繁琐——而非硬性屏障（额外的跳板跳转、速率限制、非标准端口、基于短信的多因素认证）的缓解措施，在面对能够耐心完成这些繁琐步骤的对手时，效果会大打折扣。我们下面的建议倾向于即使攻击者拥有无限耐心也能生效的控制措施：硬件绑定的凭证、过期令牌，以及不存在的网络路径，而非仅仅是不便的路径。

• 采用零信任架构。对服务之间的每个请求都进行身份验证和授权，就像它来自互联网一样。CISA的零信任成熟度模型和NCSC的零信任原则都提供了分阶段的采用路径。
• 将访问权限与经过验证的硬件而非凭据绑定。生产系统和敏感的内部工具应仅能从受管理的员工设备访问，这些设备需具备经过认证的硬件身份，并配合使用抗钓鱼的 2FA（FIDO2 或通行密钥）。仅凭窃取的凭据绝不应足以获得访问权限。即使是生产服务之间的调用也应基于硬件身份。
• 按身份隔离服务。被攻破的构建服务器不应能查询生产数据库。被攻破的笔记本电脑不应能访问构建基础设施。在接收端强制执行此策略：每个工作负载都应携带自身的加密身份，每个服务仅接受其策略名称中指定的特定调用者的连接。网络分段仍可缩小爆炸半径和降低噪声，但它只是最后一道防线。
• 用短期令牌取代长期密钥。静态 API 密钥、嵌入式凭据和共享服务账户密码是攻击者借助模型辅助代码分析时最先发现的目标。应使用由身份提供商颁发的、范围狭窄的短期令牌。

实用建议：完全零信任是一项多年计划，但身份感知访问代理可以在不从根本上改变内部服务架构的情况下，为其提供设备验证和 MFA 控制的访问。各大主流云厂商均提供原生方案，同时也有多种开源和商业替代方案适用于本地或多云环境。对于密钥，每家主流云厂商都提供托管密钥存储服务；将最广泛共享的单个凭据移入其中并进行轮换，是推动其余凭据管理的有效强制手段。

6. 减少并盘点你所暴露的内容

本节基于两个重要原则。首先，你无法防御你不知道的系统。其次，暴露面越小，可攻击的目标就越少。

• 维护一份最新的清单，列出系统中所有面向互联网的主机、服务和 API 端点。攻击者可以进行自动化侦察；你的清单至少应同样准确。将这些系统纳入你的渗透测试和红队演练中。
• 停用不再使用的系统。没有明确负责人的遗留服务通常也处于未修补状态。
• 最小化每个服务暴露的内容。默认拒绝网络入站流量，并将 API 接口范围限制在实际所需的范围内。

实用技巧：互联网范围的扫描索引是公开可查的；针对你自己的 IP 范围和域名查询其中一个索引，就能看到攻击者的侦察视角能看到什么。对于云资产，原生资产清单工具（AWS Config、Azure Resource Graph、GCP Asset Inventory）已经存在；关键在于如何查询它们。

AI 在这方面也能直接提供帮助：

• 清理陈旧代码和系统。识别未使用的代码很繁琐——但如上所述，AI 模型擅长处理繁琐的任务。一个对代码库和流量日志具有读取权限的模型，可以列出那些没有调用方且未收到流量的端点；在此基础上，它还能解释移除每个端点会产生什么影响。
• 自主外部红队演练。从外部将一个 AI 攻击型智能体指向你自己的网络边界，不提供任何凭证和源代码访问权限。然后，让它像攻击者一样行事：找出哪些是可访问的，对其进行指纹识别，并尝试将其发现串联起来，以建立初始立足点。这种自动化红队演练能够发现源代码扫描看不到的东西：被遗忘的主机、暴露的管理接口、默认凭证以及配置错误的存储。按照与资产清单刷新相同的频率来运行它。

7. 缩短事件响应时间

漏洞利用代码可能在补丁发布后数小时内出现。需要数天的响应流程太慢了。以下是一些关于如何缩短事件响应时间的思路：

• 在告警队列前端部署一个模型。每一条入站告警在人工看到之前，都应先经过自动化的初步调查。这种“分流智能体”对安全信息和事件管理（SIEM）平台拥有只读访问权限，并配备一套范围明确的查询工具，可以将你的注意力引导到最需要人工判断的告警上。
• 将工具的驻留时间和覆盖范围置于其他一切之上。这是 AI 自动化最能推动的两个指标；当漏洞利用窗口期缩短时，这两者都最为关键。
• 围绕安全事件实现记账自动化。在事件处理过程中，模型应负责记录笔记、捕获工件、并行开展调查线索，并起草事后总结与根因分析。而人类则应负责决策是否进行遏制、是否对外披露，以及如何与客户沟通。事件期间，人类的决策速度绝不应受限于那些更适合交给 AI 处理的事务，例如证据收集或文档撰写。
• 让模型驱动检测飞轮。威胁情报的摄入、候选检测规则的生成、匹配结果的搜寻，以及告警规则的调优——这些环节如今都已处于前沿模型的能力范围之内，它们能够端到端地运行整个流程。
• 针对同时发生的五起安全事件进行桌面推演。标准的演练场景假设某个周一出现了一个存在可用漏洞利用的关键 CVE。鉴于我们目前所看到的 AI 能力提升，这种假设可能并不明智。要真正检验你的应急响应能力，你应该运行一个版本：在同一周内发生五起安全事件。
• 对照 MITRE ATT&CK 框架映射检测覆盖范围。ATT&CK 提供了一套攻击者技术的标准术语，大多数检测工具已在使用。了解你能检测到哪些技术（以及哪些检测不到），比笼统地追求“提升检测能力”更有价值。你应优先覆盖横向移动和凭证访问的检测能力。
• 提前制定紧急变更流程。生产环境补丁需要两周的变更审批周期，这本身就是一种安全风险。紧急遏制措施（例如将某项服务下线、轮换凭证或阻断某条网络路径）同样如此。你应该提前决定谁有权批准这些操作，以及审批速度能有多快。

实用建议：选择一条已知误报率较高的噪声规则。将前沿模型接入其告警流，赋予其对底层数据的只读访问权限，并让模型为每次触发生成结构化的处置意见。与人工审核员进行为期两周的一致性评估。如果一致性比率在可接受范围内，再扩展到下一条规则。一次性尝试自动化整个队列并不值得。另外，Atomic Red Team 是一个开源库，包含映射到 ATT&CK 技术的小型安全测试；花一个下午运行其中几个测试，并检查现有日志记录实际检测到了哪些，就能生成一份具体的覆盖范围图。

以下是 AI 在响应时间方面可以提供帮助的一些方式：

• 实现 100% 覆盖率的初步分类。一个范围界定得当的分类智能体可以调查每一条告警（而人类可能只关注超过特定严重性阈值的告警），并生成结构化的处置意见，供人类接受、拒绝或升级。实现这一机制的要点是：为模型提供一套最小的工具集（查询、思考、报告），让其自行选择调查策略，并根据运营指标衡量其输出结果。
• 事件记录员与并行调查员。在活跃的安全事件期间，模型可以同步记录笔记，为收集到的工件添加时间戳，沿着响应人员尚未触及的独立调查线索进行追踪，并在事件结束后根据记录草拟事后分析报告。这是前沿模型在安全工作中最不引人注目的应用——但它很可能也是影响力最大的应用。
• 针对自身环境的主动威胁狩猎。能够在源代码中发现漏洞的同类智能体，也可以在你的遥测数据中搜寻错误配置和入侵指标。你可以按照与外部攻击面扫描相同的频率来运行它。

向他人提交漏洞报告的建议

如果你正在扫描代码——无论是你自己的依赖项、开源项目还是供应商产品——并将发现的问题向上游报告，那么这些报告的质量决定了是否有人会据此采取行动。开源维护者已经收到大量低质量的自动化报告，许多人开始忽略任何看起来像是 AI 生成的内容。在增加报告数量的同时却没有增加有效信息，这会让包括你在内的所有人的处境变得更糟。

只有在经过人工验证并且有人愿意署名的情况下，才应该发送报告。具体来说：

• 用通俗的语言说明漏洞及其影响。维护者应该能从第一段就理解哪里出了问题以及为什么重要，而无需运行任何东西。
• 逐步讲解代码路径。展示输入从哪里进入、在哪里被错误处理、以及后果在哪里发生。这部分是区分真实发现与模式匹配的关键。
• 提供可复现的示例。一个维护者可以运行的概念验证，或者一个会失败的测试用例，比任何长篇解释都更有可信度。
• 附上一个你如果是维护者会接受的建议补丁。补丁表明报告者对代码库有足够深入的理解，能够以符合项目惯例的方式修复问题。
• 提前披露 AI 的参与。如果模型发现了漏洞或起草了报告，在第一行就说明这一点。维护者迟早会发现；隐瞒比主动披露更损害信誉。
• 尊重维护者的判断。如果他们拒绝了报告，你应该接受这一点。易于合作所带来的好感，远比为了一个漏洞而争论赢更有价值。

实用提示：在发送漏洞报告之前，一个有用的自我检查方法是关闭编辑器，凭记忆解释这个漏洞。如果你不参考模型输出就无法描述哪里出了问题，说明你对它的理解还不够深入，不足以提交报告。

如果你没有安全团队

上述大部分建议都假设你的组织有专门的安全职能。如果你是一个小型组织、独立开发者或开源维护者，同样的风险依然存在，但应对措施会更简单：

• 为你的操作系统、浏览器以及所有提供此功能的应用程序开启自动更新。这是目前最有效的单一防护措施，且无需持续投入精力。
• 优先选择托管服务而非自行部署。让拥有安全团队的服务提供商来运行数据库、身份验证和电子邮件系统，可以将修补漏洞的负担转移给他们。此类托管服务的成本几乎总是低于发生一次安全事件的成本。
• 在每一个支持通行密钥或硬件安全密钥的账户上使用它们。短信验证码可能被拦截，密码会被重复使用；而硬件密钥则无法被网络钓鱼手段窃取。
• 在你的代码托管平台上启用免费的安全工具。GitHub 的 Dependabot、秘密扫描和 CodeQL 对公共仓库是免费的，并且能够捕获企业级工具所能捕获的相当一部分安全问题。启用它们只需几分钟。

如果你维护一个开源项目，请发布一份 SECURITY.md 文件，说明联系谁以及联系后对方可以期待什么。借助 AI 辅助扫描，你收到的漏洞报告会比以往更多。其中一些会有价值，另一些则是自动生成的噪音。一个清晰的接收流程能帮助你区分它们，并向善意的报告者表明他们的努力不会白费。

致谢

本文由 Anthropic 安全工程与研究团队的成员撰写，包括 Donny Greenberg、Jason Clinton、Michael Moore、Abel Ribbink 和 Jackie Bow，并得到了 Jannet Park、Gabby Curtis 和 Stuart Ritchie 的贡献。

借助 Claude 改变你组织的运作方式