本文针对迭代式大语言模型（LLM）驱动的 Infrastructure-as-Code（IaC）修复过程中的安全退化问题进行了实证研究。研究背景是：当前主流做法采用迭代反馈循环来改进 LLM 生成的 IaC 配置，例如使用 Checkov 和 terraform validate 等校验器将错误信号反馈给模型进行连续修复。已有工作通常报告累计最优指标，该指标在构造上非递减，因此忽略了每次迭代单独的安全轨迹。本文首次专门考察 IaC 场景下每次修复迭代后的安全回归现象，即某个先前通过的 CIS Benchmark 检查项在一次修复迭代后变为失败。研究方法为：基于 IaC-Eval 基准数据集，分析 5,968 个场景时间线（每个场景运行一种配置，最多进行 5 次修复迭代），涉及 15 种配置（6 种模型特定 RAG、9 种模型聚合非 RAG，各含 3 种温度设置），共产生 4,440 次迭代转换（两侧均有 Checkov 数据）。作者跟踪 30 个 CIS 检查项 ID，并从代码 diff 中分类根因，同时采用两种检测模式：标准模式（包含式）和严格模式（仅统计专属失败检查项）。主要结果如下：标准模式下，13.8% 的场景（24.8% 的转换）出现至少一次安全回归；严格模式下该比例降至 3.3% 的场景（5.2% 的转换），说明大多数表面上的回归实际上是多资源测量伪影。资源重构（79.0%）是主要根因。发生回归的转换表现出 2.6 倍更高的代码变更量（Cohen's d=0.90）和 4.9 倍更高的严格模式检查波动（d=1.49）。标准模式回归中，36.6% 会在平均 1.2 次迭代内自我纠正；第 3 次迭代是最佳停止点。结论表明，迭代 IaC 修复确实会引入安全回归，但保守且可辩护的比率约为场景的 3.3%。该研究为安全感知的反馈回路设计和可操作的迭代预算指南提供了动机。本文适合安全工程、DevSecOps 及 LLM 应用安全研究人员阅读，有助于理解自动化修复过程中安全与功能修复之间的权衡。