Anthropic 如何保障AI原生软件开发生命周期的安全

Anthropic 副首席信息安全官 Jason Clinton 详细介绍了安全工程团队如何保护一个 80% 合并代码由 AI 撰写的 SDLC。

在 Anthropic，代码量和部署速度呈指数增长。我们的软件工程师平均每季度发布的代码量是 2021 年至 2025 年的 8 倍。

我们的审查、监控和其他安全流程需要随着这种加快的速度进行扩展。否则，这将成为瓶颈的公式（Amdahl 定律：https://en.wikipedia.org/wiki/Amdahl%27s_law）。

我们的软件开发流程也发生了巨大变化。Claude 已从编码助手发展为主要创作者和审查者。Claude 撰写：https://www.anthropic.com/institute/recursive-self-improvement 目前约 80% 合并到我们代码库中的代码。

超过一半的代码由我们内部版本的 Claude Tag 合并：https://www.anthropic.com/news/introducing-claude-tag，而人类工程师专注于指导、设定意图并拥有最终批准权。

这意味着我们的安全团队必须防御快速扩张的攻击面，并强化以非确定性、不断演化的代理为核心的生命周期。在本文中，我将介绍保护软件开发生命周期（SDLC）的策略。

（本文旨在与我们最近发布的零信任代理框架：https://claude.com/blog/zero-trust-for-ai-agents 结合使用；本文中所有内容在实施上都使用了该框架的安全设计理念）。

我们设计应对的威胁是具体的：被攻破或被提示注入的代理可能引入恶意更改；供应链和依赖被污染，代理将其作为可信输入摄取；以及现在以更高频率出现的更常见应用程序漏洞类别。下面的每一个控制措施至少对应上述一种威胁。

我们部署了几种总体策略，以实现这一目标，同时不会显著降低开发速度，包括：

在这篇文章中，我们将介绍在软件开发生命周期特定阶段中实施的安全流程，以及其背后的核心原则。这些原则具有更持久的价值，因为随着模型能力的演进，安全团队必须重新审视并经常重新设计其流程。

我们的开发团队已经详细介绍了他们对软件开发生命周期所做的更改：https://claude.com/blog/running-an-ai-native-engineering-org，所以在深入每个阶段之前，这里将做一个简要的概述。

从宏观上来看，我们的软件开发生命周期是压缩的。它更多由原型和内部采用（自家试用）驱动，而不是长时间的计划周期。创意来自组织的各个角落，传统角色（前端、后端、设计）界限模糊。审查和批准仍然有人工参与，但也由智能循环驱动。

虽然每个阶段都被Claude Code和Claude Tag从根本上转变并加速了，但每个阶段的名称和目的对于来自更传统组织的开发者来说并不陌生。这些是自然的关卡，我们也将其用作AI原生软件开发生命周期的安全流程的一部分。

我们最早的安全自动化之一是一个由Claude Opus驱动的简单的PSR（项目安全评审）网页应用。它会接收项目设计文档，并根据MITRE ATT&CK框架：https://attack.mitre.org/ 分析文档，以识别潜在漏洞并提出缓解建议。

通过将其连接到内部知识索引，我们显著增强了系统，提供了整个组织范围内的政策、过去的决策和相关系统的更深层次背景。

这让我们更好地了解潜在风险，并且还捕获了PSR中缺失的信息。这一实现节省了大多数应用安全团队的时间。一旦我们对Claude在风险评估中的准确性有信心，如果Claude认为项目启动风险较低，我们就允许团队自行批准项目。

这里我们可以看到AI原生软件开发生命周期的首个关键适应。PSR最初是为了在漫长且昂贵的编码过程之前发现安全问题而设计的。在这一阶段捕捉到问题可以节省数月的重新开发时间。

今天，多个主要功能的原型可以在数小时内创建，使得详细的架构审查不再是关键障碍。将我们的 PSR 应用程序连接到知识索引，可以捕捉到在其他情况下可能会被忽略的上下文，而不会制造不必要的速度障碍。创建 Claude Code 技能使 Claude 能够进一步扩展并捕捉其所在位置的额外上下文。

持久原则：将安全代理连接到组织上下文。随着规划周期的压缩，更有效的方法是将这些代理带到上下文已经存在的地方——聊天线程、先前的审查、代码库——而不是在可能不再需要的阶段强制进行详细文档记录。无论哪种方式，代理都需要代码之外的上下文。

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

此前，团队观察到重复出现的漏洞，并制定安全编码指南以加以解决，但这些指南难以强制执行且很少标准化。

在 Anthropic，这些指南被编码在 CLAUDE.md 文件中，并引用组织范围的技能，因此代码在生成的瞬间就会遵循这些最佳实践。这是闭环流程的一部分。一旦代理发现某类漏洞，相关文件就会被更新，以防止其在未来的代码中再次出现。

当然，这并不意味着所有代码都是完美的。我们的团队从一个 CLAUDE.md 文件开始，该文件指示代理在打开 PR 之前运行 /security-review：https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code 作为最后一步。这个广泛可用的命令是我们团队内部审查工作流程的产品化版本，它会查找潜在攻击者可控输入的地方，扫描可疑链接，然后验证其发现。

如今，这些审查在 Claude 生成代码的同时进行。一旦安装了安全指导插件：https://code.claude.com/docs/en/security-guidance，Claude 就会在生成代码的过程中审查对话和代码。它会在生成代码的同一会话中提出安全改进建议并处理常见漏洞。

在 PR 阶段的其他推动措施，会促使内部非技术团队将他们的应用托管在我们的低代码应用托管平台上，从而避免传统上困扰安全团队的影子 IT 问题。

我们的一些客户选择将 /security-review：https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code 与 PreToolUse 钩子集成，这使得这一步骤成为更严格的门槛。这也很有效，但我们的团队选择将严格的代码审查门槛纳入循环的测试/CI 阶段。

除了塑造和审查代码之外，限制潜在影响范围是我们在这一阶段的主要关注点之一。我们通过在身份上设置严格边界（在监控部分会详细说明）以及让开发者在虚拟机上进行编码来实现这一点。

将我们的编码迁移到远程虚拟机是一种相对轻松的转变，并且相比仅使用笔记本电脑，我们获得了更高的控制力和可见性。这些虚拟机上的代理流量是经过出站白名单控制的。

这些严格的出站控制尤其重要，当代理正在读取可能携带提示注入负载的不受信输入时。注入的指令无法到达互联网中的任意目标：外泄路径仅限于一小部分受监控的服务。

在这里，你可以再次看到对 AI 原生软件开发生命周期的明确适应。以前远程编码主要用于保护知识产权，而今天我们看到更成熟的 AI 编码团队采用这些环境作为限制代理的手段。

持久原则：在 AI 原生工程组织中向左转意味着闭合漏洞发现与更新指令之间的循环，以定制 Claude 的代码生成方式。根据需要限制潜在影响范围（最小代理原则）以及代理能访问的内容，并设置严格边界。

根据我的经验，在 AI 原生转型过程中，测试或 CI 阶段很快就会成为工程团队最痛苦的瓶颈。在 Anthropic，一旦大多数开发者开始使用代理式编码工具并同时运行多个代理，团队速度很快就明显受限于人工审查代码的速度。

让我们明确一点：人工责任仍然是我们流程的核心。我们所做的是通过结合自动化的代理审查和确定性审查来加速审查流程，同时将人工审查保留给受监管或真正关键的代码。

从历史上看，人工代码审查一直被认为是标准，但实证证据：https://link.springer.com/chapter/10.1007/978-3-642-36563-8_14 已显示其并不完美。全球的软件中经常出现安全漏洞。我们的审查流程能够审查更多代码并发现特别复杂的问题，从而有助于降低这些风险。

获得实质性审查意见的PR比例已从16%增长到54%：https://claude.com/blog/code-review，随着我们要求代理提供其发现有效的证明，我们对审查结果的信心也增加了。我们还确定，过去claude.ai事件背后大约三分之一的漏洞，本可以通过我们现在实施的自动化流程被发现：https://www.anthropic.com/institute/recursive-self-improvement。

我们并不是唯一发现这一点的组织。Intercom分享道：https://www.intercom.com/blog/ai-is-approving-our-pull-requests-heres-how-we-made-it-safe/ 它自动批准了19%的PR。部署次数翻倍，而因破坏性代码变更导致的停机时间减少了35%。CircleCI在构建Chunk时得出了类似结论，这是一款基于Claude的自主代理，解决CI/CD维护问题并在人工看到之前验证自身修复。该：https://claude.com/customers/circleci 方法将代理任务转化为完成的PR的速度翻倍。

在Anthropic打开PR时，多个代理会自动进行审查。每个审查代理都有特定的、狭窄的关注范围，并利用RAG获取额外的上下文信息和过往事件的记忆。

这比使用一个超大提示或超级安全代理更有效，原因有几个：

需要明确的是，代理不会不加检查地将代码合并到生产环境。我们按风险将代码库分层，并对自动化的部分做出慎重决策。整个代码库都有严格的人工审批流程。

人工责任仍然是由 Claude 审查和合并的代码的核心。每一次批准都会记录其背后的信号和推理，并且会有人对具有风险权重的样本进行复核。另一轮测试关注不变量，例如“用户 A 永远不能读取用户 B 的数据”，并触发额外的人工审查。我们还将代理扫描与 SAST 工具结合使用，这些工具会直接在 PR 上发布结果。

大多数扫描方法，无论是代理式还是确定性方法，都是基于消耗的。随着代码吞吐量的增加，成本也将增加，团队需要决定适合他们的覆盖水平。

在 Anthropic，我们接受随着代码速度增加成本会增长，但预计单位成本会下降。当前的模型在编程方面远胜几年前的所有模型，我们预计这种趋势将会继续。

持久原则：自动化审查是一种不同类型的风险，需要通过不同的方式控制（通过多个关卡和具有独立上下文窗口的代理）。人类仍然在循环中，但在生命周期中的位置可能因代码库的性质而不同。

Anthropic 保持了稳健的分阶段环境，在那里我们执行常见的安全最佳实践，例如重大发布时进行外部渗透测试，以及定期进行 DAST 扫描，以捕捉静态扫描未发现或无法发现的逻辑漏洞。

像其他软件开发生命周期阶段一样，AI 给安全团队带来了新的挑战和解决方案。一方面，较少的漏洞会到达这一阶段。另一方面，幸存的漏洞往往是最微妙且最难发现的。

再加上更大量的代码更频繁地发布，定期的动态测试似乎也不再那么动态。

好消息是，AI 模型在多步骤、跨组件推理方面表现更好，可以捕获更高比例的复杂漏洞。例如，在二月份，我们披露 Claude 发现并帮助修复了超过 500 个高严重性开源漏洞：https://www.anthropic.com/research/zero-days。

在Anthropic，我们正在我们的测试环境中实施持续的AI驱动的动态应用安全测试（DAST）扫描。这些扫描会查找系统级的漏洞，即两个或多个服务之间假设不正确的情况。今天有许多供应商提供这些功能。

持久原则：动态测试应与部署节奏相匹配。

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

我们的安全团队在这里实施了一些标准做法，例如公开的漏洞悬赏计划：https://hackerone.com/anthropic、红队模拟攻击，以及对我们的依赖项、密钥、供应链、云安全状态和容器进行定期漏洞扫描。

Claude在这些过程中扮演了重要角色，但我们将重点关注由于我们的AI原生软件开发生命周期（SDLC）而对监控工作所做的更大改进：警报分类和代码迁移。

当Anthropic触发警报时，Claude会开始行动：

这个代理无法自动部署修复。它是一个单一用途的系统账户代理，具有三项权限：可以撰写新文档、在公司频道发布信息，以及访问生产日志。

修复必须由另一个代理-人工审查系统提供。原因归结于身份、权限和严格边界的管理：在将代码推送到生产环境时，控制影响范围非常重要。分离代理至关重要，因为一个（或多个）代理对另一个代理起到检查作用。

这对于首席信息安全官（CISO）也是一个重要的经验教训，而这是我不得不通过教训学会的。在考虑代理的严格边界时，需要包括其对其他代理的访问权限。

在模型升级之后，事件响应代理主动通过 Slack 联系了另一个 Claude 实例。它让能够编写代码的代理去推进修复。这在设计时被设置为在人工审核环节被捕捉，但这次经历教会了我们应当在访问和操作上划定边界，而不是围绕模型的指令或我们认为模型能做的事情来划定。今天在 Anthropic，代理之间在 Slack 上的通信是常态，我们还会非常认真地考虑代理身份模型：https://claude.com/blog/agent-identity-access-model。

第二个重大变化是我们团队处理迁移的方式。每个安全工程团队都会经历这样一个时刻：他们意识到代码迁移是必要的，以修复公司运营方式中的某些系统性缺陷。过去，首席信息安全官（CISO）需要开始推动，并在多个季度请求每个部门一小部分工程资源来完成修复。

迁移的经济成本已经下降，跨公司协调的成本也随之降低。Claude 将迁移过程（数万行代码）在几天内自动化完成：https://claude.com/blog/ai-code-migration。

持久原则：为每个代理赋予单一目的身份，并仅提供其工作所需的最小权限。如果确实让代理进行协调，应让它们通过与人类相同的渠道进行交流。