Anthropic 如何保护其 AI 原生软件开发生命周期

Anthropic 如何保护其 AI 原生软件开发生命周期

原文：How Anthropic secures its AI-native software development lifecycle

*Anthropic AI 原生软件开发生命周期安全实践封面图。*

Anthropic 副首席信息安全官（Deputy CISO）Jason Clinton 详细介绍了安全工程团队如何保护一个由 AI 编写 80% 合并代码的软件开发生命周期（SDLC）。

在 Anthropic，代码量和部署速度均呈指数级增长。从 2021 年到 2025 年，我们的软件工程师平均每季度交付的代码量增长到了原来的 8 倍。

我们的评审、监控以及其他安全流程也必须跟上这一加速步伐，否则便注定会形成瓶颈（参见阿姆达尔定律）。

我们的软件开发流程同样发生了巨大变化。Claude 已从编码助手演变为主要的代码创作者和审查者。如今，合并进我们代码库的代码中，约有 80% 由 Claude 编写。

超过一半的代码由我们的内部版 Claude Tag 完成合并；人类工程师则专注于提供指导、设定意图并承担最终审批责任。

这意味着，我们的安全团队既要防守一个迅速扩张的攻击面，又要加固一个以非确定性、持续演进的智能体为核心的软件生命周期。本文将介绍我们保护软件开发生命周期（SDLC）所采用的策略。

*（本文应结合我们最近发布的 《智能体零信任》框架阅读；本文中的所有实现都采用了该框架的安全设计理念。）*

我们所防范的威胁十分具体：遭到入侵或提示词注入的智能体引入恶意改动；智能体把遭到投毒的供应链或依赖项当作可信输入；以及那些更常见、如今却以更大规模涌现的应用漏洞。下文介绍的每项控制措施，都至少对应其中一种威胁。

为了在不显著拖慢开发速度的前提下应对这些威胁，我们部署了几项总体策略，包括：

• 推动安全左移，并将安全全面融入代码开发阶段；
• 使用严格的访问与身份硬边界来限制影响半径；
• 在生产部署前后，将自动化的确定性评审与智能体评审结合起来；以及
• 在杠杆效应最高的环节引入人类参与。

本文将介绍我们在软件开发生命周期各个具体阶段实施的安全流程，以及这些流程背后的核心原则。随着模型能力不断演进，安全团队必须重新审视、甚至经常重塑自己的流程；相比具体做法，这些原则更为持久。

不断演进的软件开发生命周期

*AI 原生软件开发生命周期的演变。*

我们的开发团队已经详细介绍过软件开发生命周期发生的变化，因此在深入各个阶段之前，这里只做简要说明。

总体而言，我们的软件开发生命周期已经大幅压缩。相比漫长的规划周期，如今更多由原型开发和内部试用（dogfooding）驱动。创意来自组织的各个角落，前端、后端、设计等传统角色的边界也日趋模糊。评审与审批依然有人类参与，但同样由智能体闭环推动。

Claude Code 和 Claude Tag 从根本上改变并加速了每个阶段，但对于来自传统组织的开发者而言，各阶段的名称和目的并不陌生。这些阶段构成了天然的关卡，我们也将其作为 AI 原生软件开发生命周期安全流程的一部分。

规划（Plan）

我们最早实现的安全自动化之一，是一个简单的、由 Claude Opus 驱动的项目安全评审（PSR）Web 应用。它会读取项目设计文档，并根据 MITRE ATT&CK 框架进行分析，以识别潜在漏洞并提出缓解措施。

后来，我们将该系统连接到内部知识索引，对其进行了大幅增强。这个索引能够提供更深入的上下文，覆盖全组织范围的政策、历史决策和相关系统。

*Anthropic 内部自动化项目安全评审（PSR）流程。*

*这是 Anthropic 内部执行自动化 PSR 的流程。*

这样一来，我们不仅能更准确地理解潜在风险，还能捕捉 PSR 中缺失的信息。仅这一项实现，就节省了应用安全（AppSec）团队的大部分时间。在确认 Claude 能够准确评估风险后，如果 Claude 判定某次发布的风险足够低，我们便允许团队自行批准自己的项目。

这里可以看到 AI 原生软件开发生命周期最早出现的一项关键调整。PSR 最初是为了在漫长且昂贵的编码过程开始前发现安全问题。在这一阶段发现问题，可以节省数月的返工时间。

如今，重大功能可以在数小时内生成多个原型，详细的架构评审因而不再是那么关键的关卡。将 PSR 应用连接到知识索引，既能捕捉原本可能遗漏的上下文，又不会造成不必要的减速。通过创建 Claude Code skill，Claude 还能进一步并行展开，在上下文所在的各个位置收集更多信息。

长期有效的原则：将安全智能体接入组织上下文。随着规划周期不断压缩，与其在已经不再需要详细文档的阶段强制补充文档，不如把这些智能体部署到上下文本来就存在的地方——聊天线程、既往评审和代码库。无论采用哪种方式，智能体都需要代码本身之外的上下文。

编码（Code）

AI 原生工程组织中的安全专业人员拥有了一根新的杠杆：他们可以直接影响代码的生成方式，从源头帮助预防漏洞。

过去，团队会观察反复出现的漏洞，再制定安全编码指南来应对；但这些指南很难强制执行，也很少能够实现标准化。

在 Anthropic，这些指南被编码进 CLAUDE.md 文件，并引用全组织通用的 skill，使代码从生成的那一刻起就遵循这些最佳实践。这一机制作为闭环运行：一旦智能体发现某类缺陷，相关文件便会得到更新，从而防止它在未来生成的代码中再次出现。

*从漏洞发现到安全编码指令更新的闭环。*

当然，这并不意味着所有代码一生成就完美无缺。我们团队最初在 CLAUDE.md 文件中加入指令，要求智能体在创建 PR 前执行 /security-review，作为最后一步。这个已普遍开放的命令，是我们团队内部评审工作流的产品化版本；它会查找潜在攻击者可控输入进入系统的位置，扫描可疑链接，然后验证自己的发现。

如今，这些评审会在 Claude 生成代码的同时进行。安装安全指导插件后，Claude 会随着工作进展同步审查对话和代码。它会在生成代码的同一个会话中提出安全改进建议，并处理常见漏洞。

PR 阶段的其他引导措施，则会推动内部的非技术团队将应用托管到我们的低代码应用托管平台上，从而避免长期困扰安全团队的影子 IT。

我们的一些客户选择通过 PreToolUse hook 集成 /security-review，使这一步成为更严格的关卡。这种方式同样有效，但我们的团队选择把强制代码评审关卡放在整个周期的测试/持续集成（CI）阶段。

除了影响和审查代码外，在这一阶段限制影响半径也是我们的首要关注事项之一。我们通过为身份设置硬边界（监控一节将进一步介绍），并让开发者在虚拟机上编写代码来做到这一点。

将编码工作迁移到远程虚拟机是一次相对顺利的转变。与仅使用笔记本电脑相比，它赋予我们更强的控制能力和可见性。这些虚拟机上的智能体流量受出站流量白名单控制。

当智能体读取可能携带提示词注入载荷的不可信输入时，这种严格的出站控制尤其重要。注入的指令无法访问互联网上的任意目的地：数据外泄路径被限制在少数几个受监控的服务内。

这里同样可以看到针对 AI 原生软件开发生命周期的明确调整。过去，远程编码主要用于保护知识产权；如今，我们看到更多成熟的 AI 编码团队采用这类环境来约束智能体。

长期有效的原则：在 AI 原生工程组织中，安全左移意味着在“发现漏洞”与“更新指令、定制 Claude 生成代码的方式”之间形成闭环。通过适当的硬边界，限制影响半径（最小智能体权限原则）以及智能体能够访问的内容。

测试（CI）

根据我的经验，在进行 AI 原生转型时，测试或 CI 阶段很快就会成为工程团队最痛苦的瓶颈。在 Anthropic，当大多数开发者开始使用智能体编码工具，并同时运行多个智能体之后，我们很快意识到：团队的速度上限，就是人类审查代码的速度。

有一点必须明确：人类问责仍是我们流程的核心。我们所做的，是将自动化智能体评审与确定性评审相结合，从而加速评审过程，同时把人类评审保留给受监管或真正关键的代码。

历史上，人类代码审查一直被奉为标准，但实证证据表明，它并不完美。全球的软件产品经常会将安全缺陷带入生产环境。我们的评审流程能够覆盖更多代码，并发现尤其复杂的问题，从而帮助降低这些风险。

随着我们通过要求智能体编写证据、证明其发现有效而逐渐建立信心，收到实质性评审意见的 PR 占比已从 16% 增长到 54%。我们还判断，过去 claude.ai 事故背后的缺陷中，大约有三分之一原本可以被我们现已实施的自动化流程发现。

发现这一点的并不只有我们。Intercom 曾分享，它会自动批准 19% 的 PR。其部署量翻了一番，同时由破坏性代码变更导致的停机时间减少了 35%。CircleCI 在构建 Chunk 时也得出了类似结论。Chunk 是一个基于 Claude 构建的自主智能体，用于解决 CI/CD 维护问题，并且会在人工看到之前自行验证修复结果。这种方法让智能体任务转化为已完成 PR 的比例翻了一番。

在 Anthropic，每当一个 PR 被创建，多个智能体都会自动对其进行评审。每个评审智能体都围绕特定而狭窄的关注点设计并限定范围，同时利用检索增强生成（RAG）获取与历史事故有关的额外上下文和记忆。

出于以下几个原因，这种方式远比一个巨型提示词或超级安全智能体更有效：

• 它们不会共享相同的偏见和盲点；
• 如果其中一个遭到入侵或犯错，其他评审者可以发现问题；
• 工作量不会被过度分散到多个关注领域。

需要说明的是，智能体不会在未经检查的情况下把代码合并到生产环境。我们按风险对代码库分级，并审慎决定哪些部分可以自动化。有些代码库整体都采用严格的人工审批流程。

对于由 Claude 审查和合并的代码，人类问责依然居于核心地位。每一次批准都会连同其所依据的信号和推理过程一起记录，并由人类审查根据风险加权抽取的样本。另一轮测试聚焦于诸如“用户 A 永远不能读取用户 B 的数据”这样的不变量，并会触发额外的人工评审。我们还会把智能体扫描与静态应用安全测试（SAST）工具结合起来；这些工具会直接在 PR 上发布结果。

无论是智能体扫描还是确定性扫描，大多数扫描方法都按用量计费。成本会随代码吞吐量增加而上升，各团队必须自行决定适合自己的覆盖程度。

在 Anthropic，我们接受成本将随代码交付速度提升而增长，但预计单位成本会下降。今天的模型在编码方面已经远胜数年前的所有模型，我们预计这一趋势还会持续。

长期有效的原则：自动化评审是一种不同类型的风险，需要以不同方式加以控制，例如设置多个关卡，并使用拥有独立上下文窗口的多个智能体。人类仍处于流程闭环中，但具体参与生命周期的哪个环节，可以依据代码库的性质而有所不同。

部署（CD）

Anthropic 维护着一套健壮的预发布环境。我们会在其中执行常见的安全最佳实践，例如针对重大版本发布开展外部渗透测试，以及定期执行动态应用安全测试（DAST）扫描，以发现静态扫描遗漏或无法看到的逻辑缺陷。

与软件开发生命周期的其他阶段一样，AI 既给安全团队带来新的挑战，也带来新的解决方案。一方面，抵达这一阶段的漏洞更少；另一方面，存活至此的漏洞往往最隐蔽、最难发现。

再加上代码交付量更大、频率更高，周期性动态测试似乎也不再那么“动态”了。

好消息是，AI 模型更擅长多步骤、跨组件推理，因此能够发现更多此类复杂漏洞。例如，今年 2 月，我们披露 Claude 发现并协助修复了超过 500 个高严重性开源软件漏洞。

在 Anthropic，我们正在预发布环境中实施由 AI 驱动的持续 DAST 扫描。这些扫描会在系统层面查找漏洞，尤其关注两个或多个服务之间的假设不成立的情况。目前已有多家供应商提供此类能力。

长期有效的原则：动态测试应与部署节奏相匹配。

监控（Monitor）

任何优秀的安全团队都知道，代码推送到生产环境后，工作并未结束。我们必须假设，任何漏洞都会被日益老练的攻击者迅速发现。

我们的安全团队已经实施了业内标准做法，包括公开漏洞赏金计划、红队模拟攻击，以及定期扫描依赖项、密钥、供应链、云安全态势和容器中的漏洞。

Claude 在这些工作中发挥了重要作用，但这里我们将聚焦 AI 原生软件开发生命周期给监控工作带来的两项重大变化：告警分诊和代码迁移。

当 Anthropic 触发告警时，Claude 会开始：

• 审查生产日志；
• 定位缺陷根因；
• 编写事后分析报告；以及在某些情况下
• 编写用于修复缺陷的代码变更。

这个智能体不能做的，是自动部署修复。它是一个单一用途的系统账户智能体，仅拥有三项权限：创建新文档、在公司频道发帖，以及访问生产日志。

修复必须经过一个独立的“智能体—人类审查者”体系。原因仍然在于身份、权限和硬边界的管理：将代码推入生产环境时，限制影响半径至关重要。分离智能体也十分关键，因为一个或多个智能体会对另一个智能体形成制衡。

*以身份、权限和人工审批划定智能体的行动边界。*

这也是给首席信息安全官（CISO）的一条重要教训，而且是我付出代价才学到的。在考虑智能体的硬边界时，必须把它访问其他智能体的能力也纳入其中。

一次模型升级后，事件响应智能体主动通过 Slack 联系了另一个 Claude 实例。它要求那个拥有代码写入能力的智能体推送修复。这一行为如设计预期，在人工评审关卡被拦截下来，但这次经历让我们明白：边界应围绕访问权限和实际行动来划定，而不应围绕模型指令或我们以为模型能做什么来划定。如今在 Anthropic，智能体之间通过 Slack 通信已成为常态，我们也投入大量精力思考智能体身份模型。

第二项重大变化，是我们团队处理迁移的方式。每个安全工程团队都经历过这样的时刻：他们意识到，若要修复公司运作方式中的某个系统性缺陷，就必须进行代码迁移。过去，CISO 得四处游说，并要求各部门连续几个季度抽出一小部分工程资源，才能完成修复。

如今，迁移的经济成本已经下降，全公司协同的成本也随之降低。Claude 可以在几天内自动完成涉及数万行代码的迁移过程。

长期有效的原则：为每个智能体赋予单一用途的身份，并仅授予完成其工作所需的最低权限。如果允许智能体协作，应让它们使用与人类相同的渠道。

治理（Governance）

我们已经将许多安全流程自动化，但人类仍是确保软件开发生命周期安全不可或缺的一环。只是我们的注意力不再集中于审查代码和缺陷报告，而是转向 Claude Tag、各种闭环和仪表盘。

这凸显了强治理的重要性。如果某个 skill 过时，已发现的某类缺陷没有被写回 CLAUDE.md，或智能体的决策从未被抽样审查，那么整个体系都会退化。为了避免这种情况，我们采取了以下措施：

• 按风险对代码库分级，再依据风险等级实施自动化评审。
• 所有新的 AI 评审者都先以影子模式运行。新智能体先发布评论，交由人类审批，直到赢得信任。我们的团队也会对它们开展“红队测试”，尝试插入恶意变更。
• 抽样检查一定比例的自动批准结果。
• 监测关键生命体征。我们维护并密切监控一个仪表盘，汇总各项安全流程和工作流的关键指标。
• 将每次智能体行动送入安全信息与事件管理（SIEM）系统。每一次自动批准、工具调用和智能体间消息，都会连同所依据的信号一起记录并进入 SIEM，使任何决策事后都可归因、可审计。我们会利用这些数据，把智能体视作一种新型内部威胁，并在其行为偏离预期时触发告警。

长期有效的原则：安全工程师的工作将从监控缺陷，演变为监督自动化闭环。

唯一不变的是变化

软件开发生命周期及其加固手段正在以多快的速度演进，怎么强调都不为过。模型能力每个月都在进步，同时带来新的挑战和解决方案。

今天还不太奏效或经济上不太可行的做法，很可能很快就能实现。团队真正应该问的问题不是“我们负担得起扫描所有内容吗？”，而是“如果扫描几乎免费，我们会运行哪些扫描？”请以此为目标做好规划。

*本文作者为 Anthropic 副首席信息安全官 Jason Clinton。他感谢 Michael Segner 对本文所作的贡献。*