Anthropic 副首席信息安全官 Jason Clinton 详细介绍了安全工程团队如何保护一个人工智能编写了 80% 合并代码的软件开发生命周期（SDLC）。
- 分类Claude Code企业级 AI智能体
- 产品Claude CodeClaude TagClaude Enterprise
- 日期2026 年 7 月 21 日
- 阅读时间5分钟
- https://claude.com/blog/how-anthropic-secures-its-ai-native-software-development-lifecycle
在 Anthropic，代码量和部署速度都呈指数级增长。我们的软件工程师平均每个季度交付的代码量是 2021 年至 2025 年期间的 8 倍。
我们的审查、监控以及其他安全流程需要跟上这一加速的步伐。否则，就会成为瓶颈（阿姆达尔定律）。
我们的软件开发流程也发生了巨大变化。Claude 已从编码助手演变为主要的代码创建者和审查者。如今，合并到我们代码库中的代码约有 80% 由 Claude 编写。
超过一半的代码是通过我们内部的 Claude Tag 版本合并的，而人类工程师则专注于指导、设定意图并拥有最终审批权。
这意味着我们的安全团队必须防御一个快速扩张的攻击面，并加固一个以非确定性、不断演进的智能体为核心的生命周期。在本文中，我将介绍保护软件开发生命周期（SDLC）的策略。
（本文旨在与我们最近发布的《智能体零信任框架》结合阅读；本文中的所有内容都在实施中使用了该框架的安全设计理念）。
我们针对的威胁是具体的：被攻破或遭受提示词注入的智能体引入恶意变更；智能体作为可信输入摄入的供应链和依赖项投毒；以及更常见、但数量激增的应用漏洞类别。后续的每一项控制措施都至少对应其中一种威胁。
我们部署了若干总体策略，以在不显著拖慢开发速度的情况下实现这一目标，包括：
- 将安全左移，并完全融入代码开发阶段；
- 使用严格的访问和身份边界来限制爆炸半径；
- 在生产前后结合自动化确定性审查与智能体审查；
- 在最高杠杆点引入人工干预。
本文将介绍我们在软件开发生命周期特定阶段实施的安全流程，以及这些流程背后的核心原则。这些原则具有更持久的价值，因为安全团队必须随着模型能力的演进不断重新审视、甚至重塑其流程。
不断演进的软件开发生命周期
我们的开发团队已详细阐述了软件开发生命周期的变化，因此在深入每个阶段之前，这里仅作简要概述。
总体而言，我们的软件开发生命周期是压缩的。它由原型和内部采用（dogfooding）驱动，而非冗长的规划周期。创意来自组织各个角落，传统角色（前端、后端、设计）的界限变得模糊。审查和审批环节仍有人工参与，但也由智能体循环驱动。
尽管每个阶段都因 Claude Code 和 Claude Tag 而发生了根本性变革和加速，但各阶段的名称和目的对于来自传统组织的开发者来说并不陌生。这些是我们在 AI 原生 SDLC 中同样用作安全流程的自然关卡。
规划
我们最早的安全自动化之一是一个由 Claude Opus 驱动的简单 PSR（项目安全审查）Web 应用。它读取项目设计文档，并对照 MITRE ATT&CK 框架进行分析，以识别潜在漏洞并提出缓解建议。
我们通过将该系统连接到内部知识索引，显著增强了其能力，从而提供跨组织政策、过往决策及相关系统的更深层上下文。
这让我们能更深入地理解潜在风险，同时也捕获了 PSR 中缺失的信息。这一项实现就节省了应用安全团队大部分时间。当我们确信 Claude 在风险评估方面足够准确后，便允许团队在 Claude 判定发布风险足够低的情况下自行审批项目。
在这里，我们可以看到向 AI 原生软件开发生命周期（SDLC）转型过程中最早的关键适应之一。PSR 最初的设计目的是在漫长且昂贵的编码流程之前发现安全问题。在这个阶段发现问题，可以节省数月的返工时间。
如今，主要功能的多个原型可以在数小时内创建完成，这使得详细架构审查不再是一个那么关键的关卡。将我们的 PSR 应用连接到知识索引，可以捕获原本可能遗漏的上下文，同时又不会造成不必要的速度瓶颈。创建一个 Claude Code 技能，让 Claude 能够进一步扩展，捕获任何位置存在的额外上下文。
持久原则：将安全智能体与组织上下文连接起来。随着规划周期不断压缩，将这些智能体带到上下文已经存在的地方——聊天记录、过往审查、代码库——远比在可能不再需要详细文档的阶段强行要求撰写文档要高效得多。无论哪种方式，智能体都需要代码本身之外的上下文。
代码
在 AI 原生工程组织中，安全专业人员拥有了一种新的杠杆：他们可以直接影响代码的生成方式，从源头帮助预防漏洞。
过去，团队观察到反复出现的漏洞，并制定安全编码指南来应对，但这些指南难以执行，且很少实现标准化。
在 Anthropic，这些指南被编码到 CLAUDE.md 文件和指向组织级技能的引用中，这样代码在生成的那一刻就遵循了这些最佳实践。这是作为闭环的一部分来完成的。一旦智能体发现某类缺陷，相关文件就会被更新，以防止该缺陷在未来的代码中再次出现。
当然，这并不意味着所有代码都完美无缺。我们的团队从一份 CLAUDE.md 文件开始，该文件指示智能体在发起拉取请求之前，将运行 `/security-review` 作为最后一步。这个已普遍可用的命令，是我们团队内部审查工作流程的产品化版本，它会查找潜在攻击者可控制输入进入的位置，扫描可疑链接，然后验证其发现。
如今，这些审查在 Claude 生成代码的同时进行。一旦安装了安全指导插件，Claude 会在生成代码的过程中审查对话和代码。它在同一会话中提出安全改进建议，并处理常见漏洞。
其他在拉取请求阶段的提示，会推动内部非技术团队将其应用托管在我们的低代码应用托管平台上，从而避免传统上困扰安全团队的影子 IT 问题。
我们的一些客户选择将 `/security-review` 与 PreToolUse 钩子集成，这使得这一步成为更严格的关卡。这同样有效，但我们的团队选择将严格的代码审查关卡纳入开发周期的测试/持续集成阶段。
除了塑造和审查代码之外，控制影响范围是我们现阶段的主要关注点之一。我们通过围绕身份设置硬性边界（更多内容见监控部分），以及让开发人员在虚拟机上编写代码来实现这一点。
将我们的编码工作迁移到远程虚拟机是一个相对无痛的转变，并且与仅使用笔记本电脑相比，这给了我们更强的控制力和可见性。这些虚拟机上的智能体流量已列入出站允许列表。
这些严格的出站控制尤为重要，因为智能体正在读取可能携带提示注入载荷的不可信输入。被注入的指令无法到达互联网上的任意目的地：数据外泄路径被限制在一小部分受监控的服务中。
在这里，你再次看到了针对 AI 原生软件开发生命周期的清晰适配。远程编码以前主要用于保护知识产权，而如今我们看到更多成熟的 AI 编码团队采用这些环境作为控制智能体的手段。
持久性原则：在 AI 原生工程组织中，左移意味着在漏洞发现与更新指令以定制 Claude 生成代码的方式之间形成闭环。通过硬性边界限制影响范围（最小权限原则）以及智能体所能访问的内容。
测试（持续集成）
根据我的经验，在 AI 原生转型过程中，测试或持续集成阶段会迅速成为工程团队最痛苦的瓶颈。在 Anthropic，一旦大多数开发者开始使用智能体编码工具并同时运行多个智能体，团队很快意识到，其推进速度只能与人工审查代码的速度相当。
需要明确的是：人工问责制仍然是我们流程的核心。我们所做的是通过结合自动化智能体审查和确定性审查来加速审查流程，同时将人工审查保留给受监管或真正关键的代码。
从历史上看，人工代码审查一直被视为标准，但实证证据表明它并非完美无缺。安全漏洞经常随软件一同发布到世界各地。我们的审查流程能够审查更多代码并捕获特别复杂的问题，从而有助于降低这些风险。
随着我们要求智能体为其发现结果编写有效性证明，从而对审查结论更有信心，获得实质性审查意见的拉取请求占比已从 16% 增长到 54%。我们还确定，过去 claude.ai 事件中大约三分之一的漏洞本可以通过我们现在已实施的自动化流程捕获。
我们并非唯一发现这一点的组织。Intercom 已分享其自动批准了 19% 的拉取请求。部署量翻倍，同时因破坏性代码变更导致的停机时间下降了 35%。CircleCI 在构建 Chunk（一个基于 Claude 的自主智能体，用于解决 CI/CD 维护问题并在人工介入前自行验证修复方案）时得出了类似结论。该方法使智能体任务转化为已完成拉取请求的比率翻了一番。
在 Anthropic，每当有 PR 提交时，会有多个 AI 智能体自动对其进行审查。每个审查智能体都针对特定、狭窄的领域进行设计和范围界定，并利用 RAG 技术获取额外上下文以及过往事件的相关记忆。
这种做法比使用一个巨型提示词或一个超级安全智能体要有效得多，原因如下：
- 它们不会共享偏见和盲点
- 如果某个智能体被攻破或出现失误，可以被其他审查者发现
- 精力不会过于分散到多个关注领域
需要明确的是，智能体并不会在未经检查的情况下将代码合并到生产环境。我们根据风险对代码库进行分级，并审慎决定哪些部分可以自动化。整个代码库都设有严格的人工审批流程。
对于由 Claude 审查和合并的代码，人工问责制仍然至关重要。每一次审批都会记录其背后的信号和推理依据，并且会按风险权重抽取样本进行人工复核。另一轮测试则专注于检查诸如“用户 A 永远无法读取用户 B 的数据”这类不变性条件，并触发额外的人工审查。我们还将智能体扫描与 SAST 工具相结合，这些工具会直接在 PR 上发布结果。
大多数扫描方法，无论是基于智能体的还是确定性的，都是按消耗量计费的。随着代码吞吐量的增加，成本也会上升，团队需要决定适合自身的覆盖范围。
在 Anthropic，我们接受随着代码开发速度的提升，这方面的成本会增长，但我们预计单位成本会下降。如今的模型在编程方面比几年前的所有模型都要好得多，我们预计这一趋势将持续下去。
持久原则：自动化审查是一种不同类型的风险，需要通过不同的方式加以控制（通过多个关卡以及拥有独立上下文窗口的智能体）。人类始终参与其中，但根据代码库的性质，人类可能处于开发生命周期的不同环节。
部署（CD）
Anthropic 维护着一个强大的预发布环境，我们在其中执行常见的安全最佳实践，例如针对重大发布进行外部渗透测试，以及定期进行 DAST 扫描，以捕获静态扫描遗漏或无法发现的逻辑错误。
与其他软件开发生命周期阶段一样，AI 既为安全团队带来了新的挑战，也提供了新的解决方案。一方面，到达这一阶段的漏洞更少了。另一方面，那些确实存留下来的漏洞，恰恰是最隐蔽、最难捕捉的。
再加上代码交付量更大、交付频率更高，定期的动态测试似乎也就不那么“动态”了。
好消息是，AI 模型在多步骤、跨组件的推理方面表现更佳，能够捕捉到更高比例的这类复杂漏洞。例如，今年二月我们披露，Claude 发现并帮助修复了超过 500 个高危开源软件（OSS）漏洞。
在 Anthropic，我们正在预发布环境中实施由 AI 驱动的持续 DAST（动态应用安全测试）扫描。这些扫描在系统层面寻找漏洞，即两个或多个服务之间的假设条件不正确的情况。目前已有不少厂商提供这类能力。
持久原则：动态测试的频率应与部署节奏相匹配。
监控
任何优秀的安全团队都知道，代码推送到生产环境后，工作并未结束。我们必须假设，任何漏洞都会被日益精明的攻击者迅速发现。
我们的安全团队在此已实施了一些标准做法，例如公开的漏洞赏金计划、红队模拟攻击，以及对我们的依赖项、密钥、供应链、云安全态势和容器进行定期漏洞扫描。
Claude 在这些工作中扮演着重要角色，但我们将重点介绍因采用 AI 原生 SDLC 而带来的监控工作上的更大变化：告警分类和代码迁移。
当 Anthropic 触发告警时，Claude 会开始执行以下操作：
- 审查生产日志
- 定位 bug 的根本原因；
- 撰写事后分析报告；在某些情况下还会
- 编写修复该 bug 的代码变更。
这个智能体不能做的事情是自动部署修复。它是一个单一用途的系统账户智能体，拥有三项权限：可以编写新文档、在公司频道中发帖，以及访问生产日志。
修复要么需要来自一个独立的智能体-人类审查系统。其原因又回到了身份管理、权限和严格边界的管理上：在将代码推送到生产环境时，控制爆炸半径至关重要。将智能体分开是关键，因为一个（或多个）智能体可以作为对其他智能体的检查机制。
这也是CISO们需要吸取的重要教训，而且是我不得不通过惨痛经历才学到的。在考虑智能体的严格边界时，必须将其对其他智能体的访问权限也纳入考量。
在一次模型升级后，事件响应智能体主动通过Slack联系了另一个Claude实例。它请求那个能够编写代码的智能体推送修复方案。按照设计，这被人工审查关卡拦截了，但这次经历教会我们，边界应该划定在访问权限和操作行为上，而不是围绕模型的指令或我们自认为模型能做什么。如今在Anthropic，智能体之间通过Slack进行通信已是常态，我们对智能体身份模型也给予了大量思考。
第二个重大变化是我们的团队处理迁移的方式。每个安全工程团队都经历过这样的时刻：他们意识到必须进行一次代码迁移，才能修复公司运营方式中的某些系统性缺陷。过去，CISO需要开始游说，并请求从每个部门抽调一小部分工程资源，持续多个季度才能完成修复。
迁移的经济成本已经下降，跨公司协调的成本也同样降低了。Claude能在几天内自动化完成迁移过程，涉及数万行代码。
持久原则：为每个智能体赋予一个单一用途的身份，并为其工作分配最低限度的权限。如果你确实让智能体进行协调，就让它们通过人类使用的相同渠道进行。
治理
我们已经自动化了许多安全流程，但人类仍然是确保安全软件开发生命周期中不可或缺的一部分。不过，我们的关注点不再是审查代码和错误报告，而是聚焦在Claude标签、循环和仪表盘上。
这凸显了强有力治理的重要性。如果某项技能过时、某个已发现的漏洞类别未能回传至 CLAUDE.md，或者智能体的决策未被采样，整个体系就会退化。我们通过以下方式避免这种情况：
- 根据风险等级对代码库进行分层，并基于该等级自动执行审查。
- 对所有新的 AI 审查者采用影子模式。新智能体会发布评论供人工审批，直到赢得信任。我们的团队还会对其进行“红队测试”，尝试植入恶意修改。
- 对所有自动审批结果按一定比例进行采样。
- 监控关键指标。我们维护并密切监控一个仪表盘，汇总所有安全流程和工作流中的关键指标。
- 将每个智能体操作路由至 SIEM。每次自动审批、工具调用以及智能体间的消息，连同其使用的信号一并记录，并存入我们的 SIEM，以便任何决策事后都可追溯和审计。我们利用这些数据，将这些智能体视为一种新型内部威胁，并在它们行为失准时发出警报。
持久原则：安全工程师的工作从监控漏洞演变为监控循环。
唯一不变的是变化
软件开发周期及其加固手段的演进速度之快，怎么强调都不过分。模型能力每月都在进步，既带来新的挑战，也带来新的解决方案。
今天效果不佳或经济上不太可行的方案，很可能很快就能实现。你的团队应该问的正确问题不是“我们能否负担得起扫描所有内容？”，而是“如果扫描几乎免费，我们会运行什么？”请为此做好规划。
本文由 Anthropic 副首席信息安全官 Jason Clinton 撰写。他感谢 Michael Segner 对本文的贡献。