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

把安全前移到计划、编码、测试、发布、监控和治理的每一层

摘要

Anthropic 的开发流程已经进入 AI 原生阶段。Claude 参与了大部分合并代码，代码生成速度显著提升之后，安全、审查和监控不能再按旧节奏运行。

这套方法的核心，是把安全控制嵌进软件开发生命周期本身：计划阶段引入安全上下文，编码阶段沉淀规则，CI 阶段让多个 reviewer agent 扩大覆盖，发布和监控阶段继续验证，治理阶段把经验写回流程。

AI 编程的工程化实践：Flutter AI Harness 的设计与落地

01 · 开发生命周期被压缩之后，安全也要跟着压缩

Anthropic 的软件开发已经不是传统节奏。Claude 参与了大部分合并代码，代码吞吐量上来以后，过去可以排队等待的环节都会变成新的瓶颈。

这不是单纯的代码生成问题。生成速度提高后，真正的压力会落到计划、审查、测试、发布、监控和治理上。如果这些环节仍然按人类手工时代的速度运行，开发效率会被安全流程重新卡住。

因此，安全团队要处理的不是“是否允许 AI 写代码”，而是如何让 AI 参与的软件开发生命周期仍然可控、可审查、可追踪、可回退。

要点：当 AI 负责大量合并代码，安全流程必须从单点审查变成贯穿生命周期的系统控制。

02 · 威胁模型：不只看代码漏洞，也要看 agent 行为

AI 原生开发的威胁模型比传统 SDLC 更宽。代码里仍然会出现常规漏洞，但风险不止于此。被接管或被诱导的 agent，可能滥用工具、凭证、上下文和网络出口。

Prompt injection 是重要风险之一。只要 agent 会读取不可信内容，攻击者就可能把指令藏在网页、 issue、文档或依赖信息里，试图改变 agent 的执行意图。

供应链风险也会放大。依赖、构建脚本、测试数据和生成代码都可能成为入口。AI 让变更速度变快，也意味着传统漏洞会以更高频率进入审查队列。

这类风险不能只靠提示词解决。有效控制要落在身份、权限、执行环境、网络出口、审查证据和人工审批上。

要点：AI 原生开发要同时防普通漏洞、agent 越权、prompt injection 和供应链污染。

03 · Plan：把安全上下文前移到设计阶段

计划阶段的关键，是让 Claude 在生成方案之前就拿到正确的安全上下文。Anthropic 把项目安全评审接入设计流程，让安全要求不再只出现在最后的审批节点。

PSR 会结合项目设计文档、组织知识库、历史安全审查记录和相关系统信息，帮助识别风险。它也会利用 MITRE ATT&CK 这类框架，把威胁建模提前到架构讨论里。

这样做的价值在于减少返工。安全团队不需要等到 PR 已经写完才指出方向性问题，工程师也不需要凭记忆猜哪些约束适用于当前系统。

AI 原生计划阶段不是让模型替代安全评审，而是让安全知识更早进入工程决策。

要点：计划阶段越早接入安全上下文，后续生成和审查越少依赖个人经验。

04 · Code：把规则写进生成过程，而不是事后提醒

编码阶段的目标，是让安全规则成为 Claude 工作环境的一部分。项目目录中的 CLAUDE.md 可以写入本项目特有的安全约束、架构习惯和禁止事项。

组织级技能则用来沉淀可复用经验。例如某类身份校验、输入处理、密钥管理或日志规范一旦被反复发现，就不应该只停留在某次 review 评论里，而应该写回共享技能。

在开 PR 前，开发者可以运行专门的安全审查命令，让 Claude 按已知风险模式再扫一遍。安全插件也可以在会话中持续提醒上下文，减少模型在长任务里偏离规则的概率。

这套做法把安全从“最后提醒”改成“生成时默认考虑”。它不会消除审查，但会让审查更集中在真正需要判断的地方。

要点：发现一类缺陷后，要把经验写回 CLAUDE.md、组织技能和安全插件，让下一次生成自动受约束。

05 · 执行环境：缩小 agent 出错时的影响范围

AI 编码 agent 不能被当成普通本地脚本对待。它们会读上下文、调用工具、运行命令、访问网络，因此执行环境本身必须有边界。

Anthropic 使用隔离的远程 VM 和临时环境来运行相关工作，避免 agent 直接接触生产密钥或长期凭证。即使会话被诱导，沙箱里也不应该有值得窃取的高价值凭证。

网络出口同样要收紧。出站请求经过白名单和代理控制，可以减少数据被带到攻击者控制端点的机会。

这说明边界不应该依赖提示词。提示词可以表达意图，但真正的控制要由身份、凭证、网络和执行环境承担。

要点：agent 出错时的影响范围，主要由执行环境、凭证隔离和网络出口决定。

06 · Test / CI：用 reviewer agent 扩大审查覆盖

CI 阶段是 AI 原生安全的第二道关键防线。Anthropic 使用多个职责更窄的 reviewer agent，而不是指望一个通用审查者发现所有问题。

不同 reviewer 可以分别关注认证授权、数据暴露、依赖风险、危险 API、测试缺口和配置错误。窄职责让每个 agent 更容易保持判断稳定，也更容易解释为什么提出某条意见。

自动审查并不等于取消人工审批。关键代码、敏感路径和高风险变更仍然需要人类把关。AI 的价值在于提高覆盖率，减少低级问题进入人工队列。

这套结构把审查从单次人工阅读，扩展成自动化筛查、人类抽样和关键路径审批并行运行的流程。

要点：reviewer agent 扩大安全审查覆盖，但关键变更仍保留人工审批。

07 · Deploy / Monitor：发布后仍持续验证

发布阶段不能只依赖代码合并前的判断。Anthropic 仍然使用 staging、动态安全测试、红队、漏洞奖励和生产监控来发现上线后风险。

监控阶段的重点，是让 agent 参与过的动作留下足够清晰的记录。SIEM 需要能看到谁触发了什么、agent 调用了哪些工具、参数是什么、结果是什么。

告警出现后，Claude 可以帮助安全团队分诊、查日志、整理上下文、起草复盘和建议修复。它能缩短响应准备时间，但不能绕过受控上线流程。

换句话说，AI 可以加速调查和修复准备，但最后进入生产的动作仍然要经过权限、审查和发布机制。

要点：发布后仍要靠 staging、DAST、红队、漏洞奖励和 SIEM 形成持续验证。

08 · Governance：让快速开发仍然可审计

治理阶段要解决的是可追溯性。AI 生成代码越多，组织越需要知道哪些代码由谁发起、由哪个 agent 参与、经过哪些审查、最终由谁批准。

治理不是给每个步骤加更多表格，而是把策略、证据和责任写进系统。规则可以沉淀到组织技能和项目文件，审查记录可以进入正常的工程系统，风险接受仍然由有权限的人完成。

当发现误报、漏报或新的攻击模式时，流程本身要更新。AI 原生安全不是一次性设定，而是从运行结果中持续学习的机制。

这也是治理能跟上速度的原因：安全知识不只存在于少数专家脑子里，而会被写进工具、默认配置和自动审查链路。

要点：治理的核心是可追溯、可审计、可更新，而不是把审批层层加厚。

09 · 方向：安全也要变成 AI 原生系统

AI 原生开发会持续提高代码吞吐，安全系统也必须同步提高处理能力。否则安全不是保护层，而会变成新瓶颈。

Anthropic 的做法不是放弃人工判断，而是把人工判断放到更关键的位置：策略制定、风险接受、关键路径审批、事故复盘和流程校准。

Claude 和其他 agent 负责扩大覆盖、整理上下文、执行重复检查和加快分诊。人类负责决定边界、承担责任，并在高风险动作前做最终判断。

这套模式的目标，是让软件开发速度提高的同时，安全仍然有结构、有证据、有回退路径。

要点：AI 原生安全不是让 AI 取代安全团队，而是让安全团队用同样的速度管理 AI 参与的软件开发。