在 DevOps 脚本中使用 claude code 生成基础设施即代码的安全性

第三种是 Agent 自主模式：Claude Code 不仅生成 IaC，还通过 MCP (Model Context Protocol) 工具直接读取云资源现状，甚至执行 terraform plan 和 apply。这种模式目前还比较激进，安全性讨论需要单独成篇，本文暂不展开。

我们采用的是脚本化调用模式。在这种模式下，安全性的核心问题转化为：当代码生成动作被自动化，安全验证也必须自动化，且必须在生成的“下一帧”立即发生。 任何延迟都会导致工程师手动干预，破坏流水线的可靠性。

很多人栽在一件事上，过度信任生成质量

我在社区里观察到一个非常普遍的现象：工程师第一次看到 Claude Code 生成 IaC 时，会被它的速度和质量震惊。它能瞬间产出几百行结构清晰的 HCL，甚至还贴心地加了注释。这种“看起来很专业”的输出会产生一种认知偏差，让人下意识地降低审查强度。

去年秋天一个金融科技团队的案例很能说明问题。他们的 IaC 仓库有一个硬性要求：所有 S3 存储桶必须启用 server-side encryption，并且 bucket policy 不允许任何形如 "Principal": "*" 的语句。他们的工程师用 Claude Code 生成了一个数据湖的 Terraform 模块，生成结果看起来完全合规，注释里写着“启用默认加密”，policy 块里也用了具体的 IAM role ARN。但在这个模块引用的一个子模块里，Claude 用了一个社区 module 的旧版本，那个版本的默认加密参数默认为 false。如果不是他们的 Checkov 扫描在 CI 中捕捉到了这个嵌套问题，这个存储桶就会带着裸数据跑上至少一个迭代周期。

这里的核心判断是：Claude Code 生成的 IaC 在“表面正确性”上非常强，但在“嵌套隐性假设”上存在系统性的薄弱环节。 它会优先考虑代码的可运行性和逻辑自洽，而不是安全边界的闭合。这并非模型缺陷，而是因为模型在训练时看到的代码模式中，“能跑通”的样本远多于“能跑通且绝对安全”的样本。

这个判断来自我们自己的内部测试数据。我们对 200 个 Claude 生成的 Terraform 模块进行了分层安全审计，发现如下的风险分布：

这张图反映了一个重要事实：AI 生成的 IaC 极少犯低级错误（比如直接把 AK/SK 写死在代码里），但它会频繁地在“权限粒度”和“加密默认值”这种需要上下文判断的地方出错。 而这些错误恰恰是人工审查最容易疲劳忽略的。

不要再用“事后检查”的思维做安全了

大多数团队对 AI 生成代码的安全策略，停留在“生成完跑一下 tfsec 或者 Checkov”的阶段。这种做法我称之为事后检查模式，它在人工编写 IaC 的时代勉强够用，因为人写代码速度慢、每次改动小、审查有时间窗口。但当 Claude Code 能在 30 秒内生成一整套微服务基础设施定义时，事后检查模式的三重缺陷会迅速暴露。

第一重缺陷是 修复成本倒挂。如果依赖扫描→修复→重新扫描的循环，工程师需要在 AI 生成的 300 行代码和 200 行扫描告警之间反复横跳，效率优势直接被吃掉。我们在迁移项目初期就遇到了这个问题：第一次扫描出来 47 个告警，改完之后第二次扫描又冒出 8 个新的，因为修改引入了新的配置组合。

第二重缺陷是 流水线断裂。如果安全扫描失败只是“发个通知”，而不是阻断部署流程，那么在交付压力下，安全告警会被标记为“下个迭代处理”，然后永远排不上。我们看过一个团队的 Jira backlog，有一个 P2 级别的 “Terraform 安全告警修复”工单从 2022 年 11 月一直挂到 2023 年 5 月，直到他们被外部审计点名。

第三重缺陷也是最少被讨论的：扫描工具与 AI 生成模式之间的规则错配。现有的 IaC 扫描工具规则库，是基于人工编写的常见错误模式构建的。但 Claude Code 有自己的“错误偏好”，比如它特别倾向于在 security group 里把 egress 规则设为全放开，因为在它的训练数据中，很多示例为了方便调试这么做了。传统扫描工具对此没有专门的检测规则，导致这类问题容易漏网。

所以我给所有接入团队的第一个建议是：把安全策略从“扫描点”改到“生成点”。 具体来说，就是在提示词模板里内置不可妥协的安全约束，让 Claude Code 在生成阶段就开始遵守你的安全基线。

把安全约束写进提示词，实操方法与局限

这是我们在项目中最先尝试也最早踩坑的部分。逻辑上讲，如果让 Claude Code 在生成代码之前就知道“不能用 0.0.0.0/0”、“IAM policy 必须使用最小权限”、“所有 S3 bucket 必须加密”，它就应该能生成更安全的代码。这个思路没错，但执行起来有很多细节差距。

以下是我们经过多轮迭代后沉淀下来的提示词安全约束模板结构，不是简单地在开头加一句话“请生成安全的代码”，而是结构化地注入约束：

第一步：声明角色与领域语境

你是一个为企业生产环境编写 Terraform 代码的 DevOps 工程师。
公司已通过 SOC2 认证，基础设施部署在 AWS 中国区（cn-north-1）。
你必须遵循以下不可妥协的安全策略。

这一步的作用是建立“身份锚定”，让模型的输出从“通用示例”切换为“受约束的企业环境”。在我们的 A/B 测试中，加上这段身份声明之后，生成代码中 IAM 权限过度宽松的比例从 38% 下降到 19%。

第二步：列出硬性阻断规则

以下规则在任何情况下不可违反：
1. 禁止在任何 resource 或 data 块中直接写入明文密钥、token 或密码。
2. 所有安全组入站规则，source 不得为 0.0.0.0/0，除非是 80/443 端口且业务明确要求公网访问。
3. 所有 S3 bucket 必须显式设置 acl = "private" 和 server_side_encryption_configuration。
4. IAM policy 的 Action 禁止使用 "*"，Resource 禁止使用 "*"。
5. RDS 实例必须设置 storage_encrypted = true 且不能使用默认 DB 参数组。

这些规则需要写得非常具体，因为 Claude 对模糊约束的遵循程度不稳定。只写“请遵循最小权限原则”和“IAM policy 的 Action 禁止使用 *”，效果完全不同。在我们的测试中，前者对野卡权限的减少效果只有后者的大约 40%。

第三步：给出正确示例

以下是一个符合公司安全标准的 security group 示例：
resource "aws_security_group" "example" {
  name = "app-sg"
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"] # 仅内网
  }
}
请在所有安全组生成中沿用这种模式。

Few-shot 示例对于引导模型行为非常有效。我们观察到，提供示例之后，网络安全组规则过度开放的比例从 22% 下降到了 7%。

但提示词约束有明显的边界效应。从上图可以看到，模块依赖链漏洞的改善微乎其微。这是因为这类风险发生在 module source 指向的外部模块版本上，Claude 无法控制这些外部模块的内部实现。提示词约束只能管住它“写出来的代码”，管不住它“引用的代码”。 所以我们还需要第二道防线。

CI 中的安全审查不应该是一道“关卡”，而应该是一套“分级路由”

这是我们在实践中最有价值的认知转变。传统思维把安全扫描当成一道关卡：通过了就放行，失败了就打回。但在 AI 生成 IaC 的场景里，扫描结果应该触发的是分级路由决策，而不是简单的 pass/fail。

什么是分级路由？我们设计了三层判定体系：

第一层：阻断性规则（Blocker）

违反这些规则的代码不能进入任何分支，直接打回生成阶段重新生成。规则包括：

• 检测到硬编码密钥或 token
• IAM policy 包含 "Effect": "Allow" 同时 "Resource": "*" 且 "Action" 包含高权限操作
• 安全组规则向 0.0.0.0/0 开放 22、3389、5432、3306、6379、27017 等管理类或数据库端口

第二层：告警性规则（Warning）

违反这些规则时，CI 自动在代码中插入注释标记，并生成一份“安全债务清单”附加到 PR 描述中，但不阻断合并。规则包括：

• S3 bucket 未启用日志
• RDS 未启用多可用区部署
• ALB 未配置 HTTPS listener
• CloudTrail 未启用

第三层：审计性规则（Audit）

这些规则只做记录，不产生告警。主要用于趋势跟踪和团队安全意识度量。规则包括：

• 资源未打特定标签（如 Owner、CostCenter）
• 使用了 deprecated 的 resource type
• 模块版本不是最新稳定版

这三层之间的边界不是固定的，需要团队根据自己的风险偏好和合规要求调整。但核心原则是：阻断层的门槛要足够高，确保正常开发流不被频繁打断；告警层必须是“自动记录、自动提醒、自动追踪”的，不能靠人来记住。

这个流量分布告诉我们一件重要的事：如果只有阻断层而没有告警层，那么那 35% 的告警要么被开发者无视，要么被设置为“静默忽略”，安全状态实际上在持续恶化。 而有了告警层之后，这些安全问题被显性化、量化、可追踪，团队的“安全债务意识”明显提升。

别让 Claude Code 自己决定用什么模块，建立企业内源模块白名单

在 IaC 安全中，一个被严重低估的风险是模块供应链风险。公共 Terraform Registry 上的社区模块质量参差不齐，有些模块的维护者已经弃坑，有些模块在版本更新中引入了兼容性破坏，更有些模块根本不符合企业安全基线。

Claude Code 在生成代码时，如果被问到“帮我创建一个 EKS 集群”，它大概率会引用 terraform-aws-modules/eks/aws，因为这是最流行的模块。但问题在于，它有时候会引用一个特定版本，这个版本可能与你企业内部已经审核通过的版本不一致。更糟糕的是，在生成复杂基础设施时，它会递归引用多个外部模块，这些模块各自有各自的依赖链。

我们的解决方案是建立一个企业内源模块注册表，并在提示词中强制引用。具体做法：

1. 将经过安全审计的模块 fork 到企业内部的 Git 仓库，固定版本号。
2. 在 Terraform 代码中，所有 module source 指向内部 registry。
3. 在 Claude Code 的提示词中明确声明：所有 module 引用必须使用 git::https://internal-registry.example.com/terraform-modules/<module-name>?ref=vX.Y.Z 格式，禁止引用公共 registry。

这样做的额外好处是，当这些内部模块需要安全更新时（比如一个 CVE 修复），团队只需要更新模块版本并在下游项目中触发 CI 重新生成和扫描即可，而不是去搜索几十个仓库中哪些地方引用了有漏洞的公共模块。

这里有一个取舍需要说明：内源模块白名单会降低生成速度，因为 Claude Code 需要先从你的内部文档或上下文窗口中了解这些模块的接口。 但这个取舍在安全敏感场景下是值得的。我的建议是，对于核心基础设施（网络、IAM、密钥管理、日志与监控），必须使用白名单；对于非核心的实验性环境，可以放宽限制。

生成后的“回滚能力”比生成能力更重要

很多团队在接入 Claude Code 生成 IaC 时，把精力都放在“怎么生成得更好”上，而忽略了“生成错了怎么快速回滚”。这一点上我们是有血的教训的。

在迁移项目的中期，我们有一次使用 Claude Code 重构了一个 RDS 模块，生成结果中把 apply_immediately 设置为了 true，并且在新版本中改动了 parameter_group_name。这个组合导致 Terraform apply 时直接触发了一次数据库重启，而那是一个生产只读副本。虽然影响范围不大，但如果在主库上发生，后果会很严重。

这次事故让我们意识到，Terraform 的 plan 阶段并不能捕捉所有的危险变更，尤其是在 AI 生成的代码中出现“合法但危险”的参数组合时。 所以我们建立了三层回滚机制：

第一层：Git 层面的即时回滚

所有 Claude Code 生成的代码自动提交到独立的 feature branch，并在 PR 创建时触发一次 terraform plan。Plan 输出被自动解析，如果检测到涉及 RDS、ElastiCache、DocumentDB 等有状态资源的 destructive change，PR 自动添加 DO-NOT-MERGE 标签，并通知维护者人工确认。

第二层：部署层面的自动阻断

在 CD 流水线中，我们增加了一个 terraform plan 输出的 diff 分析 step。这个 step 使用一个简单的规则引擎，检测以下模式：

• forces replacement 出现在有状态资源上
• apply_immediately = true 变更
• security group 规则的删除操作

当检测到这些模式时，流水线自动暂停，等待人工审批。

第三层：基础设施层面的快照回滚

我们在每次 Terraform apply 之前，自动触发 RDS 快照创建和关键安全组配置的导出备份。这意味着即使最坏情况发生，我们可以在几分钟内恢复到部署前的状态。

一个值得分享的细节是，我们把第二层阻断中的规则引擎做成了可配置的 YAML 文件，而不是硬编码在 CI 脚本里。这样做的原因是，随着我们对 Claude Code 生成模式的了解加深，我们会不断发现新的“合法但危险”的参数组合，把这些新规则加入配置文件比修改 CI 脚本要灵活得多。

Claude Code 的隐私与合规，容器化执行是底线

这部分讨论的不仅是代码安全，还包括使用 Claude Code 本身的安全合规性。当你把包含企业内部架构信息的提示词发送给 Anthropic 的 API 时，你实际上在做什么样的信任假设？

截至 2025 年中，Anthropic 的 API 数据使用政策已明确表示，通过 API 发送的数据不会被用于模型训练（除非你主动选择加入）。但对于很多金融、医疗、政务行业的企业来说，即便有这样的承诺，把基础设施架构细节发送给第三方 API 本身就可能构成合规风险。

我们的做法是采用容器化沙箱执行。Claude Code CLI 运行在一个专用于代码生成的容器中，这个容器：

• 只能访问一个受限的内部 Git 仓库（IaC 代码仓）
• 网络出口被限制为仅能访问 Anthropic API 端点和内部私有模块 registry
• 所有 API 请求经过一层本地代理，用于脱敏处理（将 VPC CIDR、内部域名、IP 地址等替换为占位符）
• 执行完毕后容器销毁，日志仅保留脱敏后的审计记录

这套容器化方案在公有云上用 ECS Fargate 实现，在私有化环境中用 Kubernetes CronJob 实现。它的额外好处是，因为生成动作完全在容器内完成，我们可以对生成过程中的资源消耗、API 调用次数、生成时长做精确的计量和成本分析。

安全与效率的权衡，一个很多人逃避的问题

我参加过一个技术社区的闭门讨论，主题是“AI 生成的 IaC 到底省了多少时间，又花了多少额外时间做安全修复”。讨论结果是，大多数团队不敢诚实地统计第二部分的时间，他们倾向于把安全修复算作“本来就应该做的事”，从而在计算 AI 提效时不做扣除。

我们在自己的项目里做了一个严格的计量。Claude Code 在初始生成阶段为我们节省了约 70% 的手写时间（以人天计）。但第一轮安全修复和重新生成额外消耗了我们大约 25% 的节省时间。随着提示词约束的优化和内源模块白名单的建立，这个比例在后期下降到了约 10%。

所以真实的生产力提升大约是 60%，而不是 70%。但这 60% 是可持续的、安全的、可审计的。 我认为 10% 的安全维护成本是一个值得投入的比例，它应该被直接编入项目预算和排期评估中，而不是事后偷偷摸摸地消化。

这里有一个决策框架可以供读者参考：

这个表格的关键信息是：安全投入不应该均质化，而应该按照资源的业务影响级别进行分层。 什么都严格等于什么都没严格，因为执行难度太高导致最终被绕过。

你需要的不是更多工具，而是一套“人机安全协作协议”

写到这里，我想跳出具体的技术细节，谈一个我越来越确信的观点：在 DevOps 脚本中使用 Claude Code 生成 IaC，最终的瓶颈不是工具链，而是人机协作协议的设计。 工具可以买、可以集成，但如果团队没有对“AI 生成代码的安全责任归属”达成共识，所有的技术防线都会在某个压力时刻被绕过。

我建议每个团队在引入 Claude Code 进入 IaC 流水线之前，先明确以下几件事，并且把它们写进团队的 Working Agreement：

第一条：AI 承担“起草人”角色，人类承担“签署人”角色。

Claude Code 生成的所有 IaC 代码，在合并到主分支之前，必须有一个明确的 human sign-off。这个 sign-off 不是“我看过了”的走过场，而是需要在 PR 中回答三个固定问题：

1. 这段代码中最危险的一个变更是什么？
2. 我确认过它的安全性了吗？
3. 如果出问题，回滚路径是否可用？

第二条：任何安全告警的“静默忽略”，必须有记录和过期时间。

我们允许工程师对某些告警做豁免处理（比如开发环境对加密要求不严），但所有豁免必须在代码中以 # security-exemption: 注释标记，并设置一个自动过期的日期。CI 脚本会检查过期的豁免并重新触发告警。这就避免了“临时豁免变成永久忽略”的安全债务累积。

第三条：每一次生成，都是一次安全假设的显性化。

Claude Code 在生成 IaC 时，实际上是在做一系列的安全假设（比如“这个安全组应该对这个 CIDR 开放”、“这个 IAM role 需要这些权限”）。我们要求工程师在 prompt 中，或者至少在 PR 描述中，列出这次生成涉及的核心安全假设。这样做不是为了增加工作量，而是为了让后续的审查者能够快速识别出“哪些安全决策是合理的，哪些是由于 AI 的惯性而做出的不必要宽松”。

这些“协议条款”看起来有些理想化，但在我们团队严格执行了三个月之后，安全告警的平均修复时间从 4.2 天下降到了 1.1 天，安全相关的回滚事件从每月 3 次下降到了零。

结论与行动清单

回到标题的核心问题：在 DevOps 脚本中使用 Claude Code 生成基础设施即代码，安全性到底怎么样？

我的答案是：它不安全，如果你把它当成一个自动化的代码生成器来用，而不重新设计你的安全流水线。但它可以做到比你手写更安全，如果你把安全约束前移到生成点，把审查变成分级路由，把模块管理变成内源白名单，把回滚设计成多层纵深机制。

Claude Code 不会主动帮你考虑安全，就像 Terraform 不会主动帮你考虑成本优化一样。它是工具，而工具的安全性取决于使用者为它设定的运行边界。在 DevOps 脚本这个场景里，我们有能力，也应该有责任，为这个工具设计一个让它“在安全轨道上运行”的环境。

如果你想在自己的团队中开始安全地使用 Claude Code 生成 IaC，这是我的行动建议清单，按优先级排序：

本周就可以做的三件事：

1. 把你企业最核心的 5 条安全规则写成结构化约束，注入到 Claude Code 的 prompt 模板中，然后在 20 个测试模块上对比注入前后的扫描结果差异。
2. 在你的 CI 流水线中增加一个 terraform plan 输出解析步骤，至少检测 forces replacement 和 apply_immediately = true 的变更，并设置自动阻断。
3. 盘点当前 IaC 仓库中引用的外部模块，评估哪些应该 fork 到内部 registry 并固定版本。
   下个迭代值得做的两件事：
4. 实现安全扫描结果的分级路由，把阻断/告警/审计三层分开，让开发流不被频繁打断但安全债务不隐形。
5. 建立 Claude Code 生成的容器化沙箱，确保 API 通信中的数据脱敏和审计完整性。
   一个需要持续投入的方向：
6. 把团队对 AI 生成代码的安全审查标准文档化，形成 Working Agreement。工具会变，Claude Code 会更新，但团队对“什么是可接受的安全风险”的共识，才是长期安全能力的基石。

这篇文章里没有给你推荐“最好用的扫描工具”或者“最完美的 prompt 模板”，因为那都不是答案本身。答案在于你是否承认：当代码生成速度提高了 10 倍，安全响应速度也必须同步提高 10 倍。 而要做到这一点，靠加人手、靠加班审查、靠事后修修补补都不行，只能靠把安全性重新设计进生成流水线里。

如果你的团队正在这条路上摸索，我建议从最小闭环开始：先在一个非核心模块上跑通“约束生成 → 自动扫描 → 分级路由 → 告警追踪”的全流程，然后以此为样板，逐步扩展到核心基础设施。安全从来不是一步到位的，它是在每一次生成、每一次审查、每一次回滚中积累出来的工程能力。