LLM 迭代修复基础设施代码时的安全回退

摘要

该研究分析 LLM 驱动的基础设施即代码（IaC）修复是否会在后续迭代中重新引入安全问题。作者记录 5,968 条修复时间线，并使用 CIS 检查区分真正的安全回退与资源重构造成的测量假象。

结果说明“当前检查通过”不代表多轮修改后仍安全。修复 Agent 的验收对象应是整个时间线和最终基础设施状态，而不是单次补丁。

方法的独特价值

研究把修复过程建模为有状态序列，区分严格回退、资源删除重建和检查器映射变化。这比只比较初始与最终版本更能发现 Agent 在优化其他目标时破坏既有安全属性。

适用范围

方法适用于 Terraform 等声明式 IaC 和持续修复 Agent。它不能直接代表手工代码修复、所有云提供商或真实部署后的运行时状态。

方法与实施流程

1. 为初始 IaC 建立 CIS 安全检查基线。
2. 让 Agent 迭代修复不同问题并保存每个版本。
3. 在每一步重新运行安全检查。
4. 对资源重命名、删除重建和真实配置退化分别归因。
5. 用时间线级指标统计曾经修复后再次失败的控制。

质量控制

评测应固定检查器版本，保存资源身份映射，并验证最终计划或沙箱部署。修复系统需要设置不可回退断言，把已通过控制加入后续迭代的回归测试。

AI 生成 Ansible 代码的安全 smell 评测把对象从 Terraform 迭代修复扩展到 16 个模型生成的 Ansible 角色，以 CIS 规则比较默认提示与安全提示下的合规、功能和弱点分布。它提供的可证伪增量是：安全提示可能改变 smell 数量与类型，却不能仅凭合规率确认角色仍满足功能约束；验收应对同一任务运行功能测试、CIS 检查和跨轮回归。结果限于作者选择的 Ansible 任务、模型和静态规则，未证明生成配置在真实部署中安全，也不能直接与本文 5,968 条 Terraform 时间线的回退率合并。

局限与待验证问题

CIS 检查不能覆盖全部云风险，生成配置与真实部署仍有差异。结果来自作者实验，尚需跨模型、跨云和生产变更评审复现。

参考链接

• IaC 修复安全回退论文