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

- 来源：Claude：Blog（网页）
- 发布时间：2026-07-21 00:00
- AIHOT 分数：67
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmruye3wf00qubinv8iptndu9
- 原文链接：https://claude.com/blog/how-anthropic-secures-its-ai-native-software-development-lifecycle

## 精选理由

Anthropic首次详细拆解自己的AI原生安全流程，用80%AI代码的事实倒逼安全左移和代理审查，对正在思考如何保障AI编码安全的团队是一份难得的内部地图。

## AI 摘要

Anthropic副首席信息安全官Jason Clinton披露，其软件工程师每季度交付的代码量是2021-2025年平均水平的8倍，Claude编写了约80%合并入库的代码。安全团队通过安全左移、硬访问与身份边界、自动化与智能体审查结合、关键节点引入人工审核等策略，应对被入侵或提示注入的智能体引入恶意变更等威胁，同时不显著拖慢开发速度。

## 正文

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

分类

Claude Code

企业级 AI

智能体

产品

Claude Code

Claude Tag

Claude Enterprise

日期

2026 年 7 月 21 日

阅读时间

5

分钟

https://claude.com/blog/how-anthropic-secures-its-ai-native-software-development-lifecycle

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

我们的审查、监控和其他安全流程也需要随着这一加速步伐同步扩展。否则就会成为瓶颈的公式（阿姆达尔定律）。

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

超过一半的代码由我们内部版本的 Claude Tag 合并，而人类工程师则专注于方向指引、设定意图并拥有最终审批权。

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

（本文旨在与我们最近发布的 Zero Trust for Agents 框架结合阅读；本文中的所有内容都在实施中采用了该框架的安全设计理念）。

我们针对设计防御的威胁是具体的：被入侵或提示词注入的智能体引入恶意变更；智能体作为可信输入摄取的供应链和依赖投毒；以及现在以更高数量级出现的更常见的应用漏洞类别。后续的每项控制措施都至少对应其中一种威胁。

我们部署了若干总体策略，以在不显著拖慢开发速度的情况下实现这一目标，包括：

将安全左移，并完全集成到代码开发阶段；

利用严格的访问和身份边界来限制爆炸半径；

在生产环境前后，结合自动化确定性审查与智能体审查；

在杠杆效应最高的环节引入人工介入。

在本文中，我们将介绍我们在软件开发生命周期的特定阶段所实施的安全流程，以及这些流程背后的核心原则。这些原则更具持久性，因为随着模型能力的不断演进，安全团队必须重新审视、甚至常常重塑其流程。

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

我们的开发团队已详细阐述了其软件开发生命周期的变化，因此这里仅作简要概述，随后再深入探讨每个阶段。

总体而言，我们的软件开发生命周期是高度压缩的。它由原型和内部采用（dogfooding）驱动，而非冗长的规划周期。创意来自组织各个角落，传统角色（前端、后端、设计）之间的界限也变得模糊。审查和审批环节仍有人工参与，但同样也由智能体循环驱动。

尽管每个阶段都因 Claude Code 和 Claude Tag 而发生了根本性的变革和加速，但各阶段的名称和用途对于来自更传统组织的开发者来说并不陌生。这些是天然的关卡，我们也将其作为 AI 原生 SDLC 安全流程的一部分。

规划

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

我们通过将该系统连接到内部知识索引，显著增强了其能力，该索引提供了跨组织政策、过往决策及相关系统的更深层上下文。

Anthropic 内部自动化 PSR 的流程。

这让我们能更好地理解潜在风险，同时也能捕获 PSR 中缺失的信息。这一项实现就节省了 AppSec 团队的大部分时间。一旦我们确信 Claude 在风险评估方面足够准确，只要 Claude 判定项目上线风险足够低，我们就允许各团队自行审批自己的项目。

在这里，我们可以看到 AI 原生 SDLC 的首批关键适应性调整之一。PSR 最初的设计目的是在漫长且昂贵的编码过程之前发现安全问题。在这个阶段发现问题可以节省数月的返工开发时间。

如今，主要功能的多个原型可以在数小时内完成，这使得详细架构审查不再是一个那么关键的关卡。将我们的 PSR 应用连接到知识索引，可以在不制造不必要速度瓶颈的情况下，捕获原本可能被遗漏的上下文。创建一个 Claude Code 技能，让 Claude 能够进一步扩展，并在上下文所在之处捕获更多信息。

持久原则：将安全智能体连接到组织上下文。随着规划周期不断压缩，把这些智能体带到上下文已经存在的地方——聊天线程、过往审查、代码库——远比在可能已不再需要详细文档的阶段强行要求编写文档要有效得多。无论哪种方式，智能体都需要代码本身之外的上下文。

视频 · 前往原文观看

代码

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

过去，团队观察到反复出现的漏洞，并制定安全编码指南来应对，但这些指南难以执行，且很少实现标准化。

在 Anthropic，这些指南被编码到 CLAUDE.md 文件和指向组织级技能的引用中，这样代码在生成的那一刻就遵循这些最佳实践。这是作为闭环的一部分来完成的。一旦智能体发现一类 bug，相关文件就会被更新，以防止它在未来的代码中再次出现。

当然，这并不意味着所有代码都能完美无瑕。我们团队一开始就准备了一个 CLAUDE.md 文件，指示智能体在提交 PR 之前，最后执行 /security-review 这一步。这个命令已经正式发布，是我们团队内部审查流程的产品化版本，它会查找潜在攻击者可控输入进入的位置，扫描可疑链接，然后核实其发现。

如今，这些审查是在 Claude 生成代码的同时进行的。一旦安装了安全指导插件，Claude 就会边生成边审查对话和代码。它会在生成代码的同一会话中提出安全改进建议，并处理常见漏洞。

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

我们的一些客户选择将 /security-review 与 PreToolUse 钩子集成，这会让这一步成为更严格的关卡。这种做法同样有效，但我们团队选择在测试/CI 阶段纳入严格的代码审查关卡。

除了塑造和审查代码之外，控制爆炸半径也是我们这一阶段的主要关注点之一。我们通过围绕身份设置硬性边界（监控部分会详述）以及让开发人员在虚拟机上编写代码来实现这一点。

将编码工作迁移到远程虚拟机是一个相对无痛的转变，与仅使用笔记本电脑相比，这给了我们更强的控制力和可见性。这些虚拟机上的智能体流量已列入出口白名单。

这些严格的出口控制尤为重要，因为智能体可能会读取不可信输入，其中可能携带提示注入载荷。注入的指令无法到达互联网上的任意目的地：数据外泄路径被限制在一小部分受监控的服务中。

这里你再次看到为 AI 原生 SDLC 所做的明确调整。远程编码以前主要用于保护知识产权，而今天我们看到越来越多成熟的 AI 编码团队采用这些环境来约束智能体。

持久原则：在 AI 原生的工程组织中，左移意味着在漏洞发现与更新指令以定制 Claude 生成代码的方式之间形成闭环。通过适当的硬性边界，限制爆炸半径（最小权限原则）以及智能体可访问的范围。

测试（CI）

根据我的经验，在 AI 原生转型过程中，测试或 CI 阶段很快就会成为工程团队最痛苦的瓶颈。在 Anthropic，一旦大多数开发者开始使用智能体编码工具并同时运行多个智能体，很快就变得显而易见：团队的推进速度只能跟得上人类审查代码的速度。

需要明确的是：人的责任在我们的流程中仍然处于核心位置。我们所做的是通过结合自动化智能体审查和确定性审查来加速审查流程，同时将人工审查保留给受监管或真正关键的代码。

从历史上看，人工代码审查一直被视为标准，但经验证据表明它并不完美。安全漏洞经常随全球各地的软件一起发布。我们的审查流程能够审查更多代码并捕获特别复杂的问题，有助于降低这些风险。

随着我们要求智能体为其发现编写有效性证明，从而对这些发现建立起信心，获得实质性审查意见的 PR 占比已从 16% 增长到 54%。我们还确定，过去 claude.ai 事故中约三分之一的漏洞本可以被我们现在已实施的自动化流程捕获。

我们并不是唯一发现这一点的组织。Intercom 公开表示其 19% 的 PR 获得自动批准。部署量翻倍，同时因破坏性代码变更导致的停机时间下降了 35%。CircleCI 在构建 Chunk（一个基于 Claude 的自主智能体，用于解决 CI/CD 维护问题并在人工介入之前自行验证修复方案）时得出了类似结论。这种方法使智能体任务转化为已完成拉取请求的比率翻了一番。

在 Anthropic，每当有 PR 被创建时，多个智能体会自动对其进行审查。每个审查智能体都被设计并限定在特定、狭窄的职责范围内，并利用 RAG 来获取与过往事件相关的额外上下文和记忆。

相比使用一个巨型提示词或一个超级安全智能体，这种方式有效得多，原因如下：

它们不会共享偏见和盲区

如果其中一个被攻破或犯错，可以被其他审查者发现

精力不会过于分散在多个关注领域上

需要说明的是，智能体并不会在无人检查的情况下将代码合并到生产环境。我们按风险对代码库进行分级，并对哪些部分实现自动化做出审慎决策。整个代码库都设有严格的人工审批流程。

对于由 Claude 审查和合并的代码，人工问责仍然至关重要。每次审批都会记录其背后的信号和推理依据，并由人工对按风险加权的样本进行复核。另一轮测试则聚焦于“用户 A 永远无法读取用户 B 的数据”这类不变量，并触发额外的人工审查。我们还将智能体扫描与 SAST 工具相结合，这些工具会直接在 PR 上发布结果。

大多数扫描方法，无论是智能体式的还是确定性的，都是基于消耗量的。随着代码吞吐量的增加，成本也会上升，团队需要决定适合自身的覆盖水平。

在 Anthropic，我们接受随着代码速度的提升，这方面的成本会增长，但预计单位成本会下降。如今的模型在编程方面的能力远胜于几年前的所有模型，我们预计这一趋势将持续下去。

持久原则：自动化审查是一种不同类型的风险，需要通过不同方式加以控制（通过多重关卡和拥有独立上下文窗口的智能体）。人工始终参与其中，但根据代码库的性质，人工介入点可能处于生命周期的不同环节。

部署（CD）

Anthropic 维护着一个健壮的预发布环境，我们在其中执行常见的安全最佳实践，例如针对重大发布进行外部渗透测试，以及定期进行 DAST 扫描，以捕获静态扫描遗漏或无法发现的逻辑缺陷。

与其他 SDLC 阶段一样，AI 既为安全团队带来了新的挑战，也提供了新的解决方案。一方面，到达这一阶段的漏洞更少了。另一方面，那些确实存活下来的漏洞恰恰是最隐蔽、最难发现的。

再加上代码交付量更大、交付频率更高，定期的动态测试看起来也就不那么“动态”了。

好消息是，AI 模型在跨组件、多步骤推理方面表现更佳，能够捕获更高比例的此类复杂漏洞。例如，今年 2 月，我们披露 Claude 发现并帮助修复了 500 多个高严重性的 OSS 漏洞。

在 Anthropic，我们正在预发布环境中实施持续性的 AI 驱动 DAST 扫描。这些扫描在系统层面寻找漏洞，即两个或多个服务之间的假设不正确的情况。目前已有不少厂商提供此类能力。

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

监控

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

我们的安全团队在此实施了多项标准实践项目，例如公开的漏洞赏金计划、红队模拟攻击，以及对我们的依赖项、密钥、供应链、云安全态势和容器进行定期漏洞扫描。

Claude 在这些工作中扮演着重要角色，但我们将重点关注因我们 AI 原生的 SDLC 而带来的监控工作的更大变化：告警分诊和代码迁移。

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

审查生产日志

定位问题的根本原因；

撰写事后分析报告；在某些情况下

编写修复该问题的代码变更。

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

修复方案要么来自一个独立的智能体-人工审查系统。原因还是要回到身份管理、权限和硬性边界上：在将代码推送到生产环境时，控制爆炸半径至关重要。将智能体彼此分离是关键，因为一个（或多个）智能体要对另一个智能体形成制衡。

这也是给CISO们的一个重要教训，而且是我付出了惨痛代价才学到的。在考虑智能体的硬性边界时，你需要把它对其他智能体的访问权限也纳入考量。

在一次模型升级之后，事件响应智能体主动通过Slack联系了另一个Claude实例。它请求那个能够编写代码的智能体推送修复方案。这一行为按设计在人工审查关卡被拦截了，但这次经历让我们明白，边界应该划定在访问权限和操作行为上，而不是划定在模型的指令或我们自认为模型能做什么上。如今在Anthropic，智能体之间通过Slack通信已是常态，我们对智能体身份模型也投入了大量思考。

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

迁移的经济成本已经下降，跨公司协调的成本也随之降低。Claude将迁移过程自动化，数万行代码在几天内就能完成迁移。

持久原则：赋予每个智能体单一用途的身份，并只授予其完成工作所需的最低权限。如果你确实允许智能体之间进行协调，就让它们通过与人类相同的渠道进行。

治理

我们已经自动化了许多安全流程，但人类仍然是确保安全软件开发生命周期不可或缺的一部分。不过，我们的关注点已不再是审查代码和错误报告，而是集中在Claude Tag、循环和仪表盘上。

这凸显了强有力治理的重要性。如果某个技能过时了，发现的一类漏洞从未被回写到 CLAUDE.md 中，或者智能体的决策未被抽样检查，整个体系就会退化。我们通过以下方式来避免这种情况：

按风险对代码库进行分层，然后基于该层级自动化审查。

所有新的 AI 审查者都采用影子模式。新智能体先发布评论供人工审批，直到赢得信任。我们的团队还会对它们进行“红队测试”，尝试注入恶意更改。

对所有自动化审批按一定比例进行抽样。

监控关键指标。我们维护并密切监控一个仪表盘，汇总所有安全流程和工作流的关键指标。

将每个智能体操作路由到 SIEM。每次自动化审批、工具调用和智能体间消息都会连同其使用的信号一起记录，并进入我们的 SIEM，因此任何决策事后都可追溯、可审计。我们利用这些数据，将这些智能体视为一种新型内部威胁，并在它们行为偏离对齐时发出警报。

持久原则：安全工程师的工作从监控漏洞演变为监控循环。

唯一不变的是变化

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

今天还不太奏效或经济上不太可行的方案，很可能很快就会实现。你的团队该问的正确问题不是“我们扫描得起所有内容吗？”，而是“如果扫描几乎免费，我们会运行什么？”为此做好规划。

本文由 Anthropic 副首席信息安全官 Jason Clinton 撰写。他感谢 Michael Segner 对本文的贡献。