💻 computer science

Does Fixing Break Security? An Empirical Study of Security Degradation in Iterative LLM-Driven Infrastructure-as-Code Repair

这项实证研究分析了 5,968 个迭代式 LLM 驱动的基础设施即代码（IaC）修复场景，结果表明，虽然在标准检测下安全回归发生率高达 13.8%，但更保守的严格模式分析显示，其退化率仅为 3.3% 的可辩护水平，这主要是由资源重构驱动的，并且可以通过在第三次迭代后停止修复来缓解。

原作者： Benjamin Agyekum, Fabio Santos

发布于 2026-08-14

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Benjamin Agyekum, Fabio Santos

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在用数字积木搭建一座宏伟而复杂的城堡。这不仅仅是一座普通的城堡，它是支撑互联网、你喜爱的应用程序和云服务的底层基础设施。在软件工程领域，这被称为基础设施即代码（Infrastructure-as-Code, IaC）。工程师不再是通过菜单点击按钮，而是编写文本文件（代码），精确地告诉计算机如何建造这些数字城堡。最近，我们开始使用被称为“大语言模型（LLM）”的超智能 AI 助手来为我们编写这些代码。这就像雇佣了一位能够秒级绘制蓝图的机器人建筑师。

但问题在于：机器人也会犯错。有时，它们绘制的蓝图会有安全漏洞——比如把前门大开，或者忘了锁上宝箱。为了解决这个问题，我们使用了一个“反馈循环”。我们运行一个安全扫描器（数字检查员）来检查机器人的工作，指出错误，并将坏消息传回给机器人。然后，机器人尝试修复代码并再次发送进行检查。这个循环不断重复，希望城堡随着每一轮迭代变得更加安全。核心问题在于：修复一个问题是否会意外破坏原本已经安全的其他部分？ 这就像是在修补船上的一个洞，却在不经意间把船体也捅出了一个洞。本文深入探讨了这一场景，旨在观察我们的 AI 助手究竟是在让事情变得更安全，还是仅仅在制造混乱。

机器人的建筑师困境：当修复破坏了修复

在这项研究中，研究人员 Benjamin Agyekum 和 Fabio Santos 决定通过分析一组大规模的 AI 修复尝试数据集来进行“侦探调查”。他们观察了近 6,000 个不同的场景，在这些场景中，AI 尝试构建或修复云基础设施代码。他们追踪了 5 轮修复过程，并监测了 30 项特定的安全检查（例如“数据是否加密？”或“访问权限是否已锁定？”）。

他们的主要发现带有一点转折：是的，修复确实可能破坏安全性，但情况并没有看起来那么可怕。

当他们使用“标准”计数方法观察原始数据时，发现有 13.8% 的情况下，AI 在试图修复某物时，破坏了一个原本正常的安全规则。这听起来很多，对吧？但研究人员意识到，这种计数方式有点复杂。因为代码通常涉及许多不同的部分（比如建筑物的多个数字锁），AI 可能会修好一把锁，却意外地改变了另一把锁的“状态”，即便实际的安全性并未受到威胁。

当他们切换到一种“严格”的计数方法——即只寻找那些明确、无可争议的安全恶化案例时——这个比例大幅下降至仅为 3.3%。这表明，大多数所谓的“破坏”只是由代码复杂性引起的测量误差，而非真正的安全灾难。

破坏的“原因”与“方式”

那么，当 AI 真的搞砸时，到底发生了什么？研究人员发现，罪魁祸首几乎总是资源重构（resource restructuring）。想象一下，机器人建筑师决定彻底重建一面墙，而不是仅仅修补一道裂缝。在这样做时，它可能会忘记把安全摄像头重新装回新墙上。在所有发生安全倒退的案例中，这种情况占了 79%。

他们还注意到关于 AI 模型“个性”的一个有趣现象。在使用标准计数法时，一个模型（Mistral）造成的破坏次数似乎比另一个模型（Gemini）多出 17 倍。然而，在采用严格计数法后，没有任何一个模型是专门制造破坏的。这意味着“表现较差”的模型并没有创造更多危险的漏洞，它只是创造了更复杂的代码结构，从而干扰了计数方法。

甜点位：何时停止修复

研究中最具实践意义的发现之一是关于何时停止。AI 会不断尝试改进代码，但它会停下来吗？研究表明，第 3 次迭代（即 AI 第三次尝试修复代码时）是“甜点位”（最佳时机）。

到第 3 次尝试时，代码的安全性约为 83.1%。
如果你继续进行第 4 或第 5 次尝试，安全性几乎没有提升（可能仅增加 0.3%），但你开始增加了再次破坏东西的风险。

这就像调收音机：调得太久，除了增加杂音外，并不能找到更清晰的电台。

曙光：自我修正

这是故事中最令人欣慰的部分。研究人员发现，当 AI 意外破坏了一条安全规则时，它往往能实现自我修复！在约 36.6% 的情况下，下一轮修复就会纠正 AI 刚刚犯下的错误。这就像机器人建筑师意识到：“哎呀，我刚才把门拆错了，”然后在下一步又把它装了回去。

然而，他们也发现了“拉锯战”效应。大约有 28.5% 的时间，安全检查会出现反复——通过、失败、通过、失败——就像一个无法停下的钟摆。这种情况通常发生在复杂的访问控制方面，表明 AI 仍在摸索构建这些特定部分的最佳方式。

总结

本文告诉我们，虽然迭代式的 AI 修复是一个强大的工具，但我们需要谨慎对待衡量其成功的方式。

不要过度惊慌于每一个小故障： 大多数看似安全破坏的情况，其实只是令人困惑的测量误差，而非真正的危险。
警惕大规模重写： 如果 AI 开始拆除整个代码段来修复一个小 bug，那就是安全性最容易出现滑坡的时候。
三次为限： 让 AI 尝试三次来修复代码，然后就此收手。继续下去通常带来的风险大于收益。
使用正确的工具： 如果你想确保万无一失，请使用一种忽略复杂多部分错误的“严格”检查方法，但也要留意“标准”警报以防万一。

简而言之，AI 是一个得力的学徒，但它需要人类监督员来告诉它何时该停止拧扳手，否则它可能会因为用力过猛，把整个机器都拧坏。

技术摘要：修复是否会破坏安全性？关于迭代式 LLM 驱动的基础设施即代码（IaC）修复中安全性退化的实证研究

问题陈述

虽然迭代反馈循环——即通过 Checkov 和 terraform validate 等验证器将错误信号反馈给大语言模型（LLM）以进行连续修复尝试——已成为提高 LLM 生成的基础设施即代码（IaC）性能的主流范式，但先前的研究在很大程度上依赖于累积最佳指标（cumulative-best metrics）。这些指标报告的是所有迭代中达到的最高合规水平，由于其构造特性，这些数值是单调不减的。因此，IaC 领域从未有人考察过原始的逐迭代安全性轨迹。

本研究旨在探讨安全性回归（security regression）现象：即在旨在修复其他问题的修复迭代之后，原本通过安全检查（具体为 CIS 基准控制项）的配置出现了失败。与关注命令式语言和漏洞数量的通用代码修复研究（如 Shukla 等人 [25], Chen 等人 [7]）不同，本研究调查了 IaC 的独特挑战。IaC 是声明式的，且安全检查映射到资源层级的特定配置属性。一个关键的区别在于，单个 Checkov 检查 ID 可能适用于单个配置中的多个资源，这产生了一类多资源歧义性（multi-resource ambiguity），即一个检查 ID 可能同时对某些资源通过而对另一些资源失败。这种歧义性使得在 IaC 中定义“回归”比在通用代码中更为复杂。

研究方法

作者进行了一项大规模实证研究，分析了来自 IaC-Eval 基准测试的 5,968 个场景时间线。研究设计包括：

配置： 15 种不同的实验配置，包含两种模型特定的检索增强生成（RAG）设置（Gemini 和 Mistral）以及九种模型聚合的非 RAG 设置（零样本、少样本、思维链），每种设置运行了三种温度（0.1, 0.4, 0.7）。
流程： 每个场景最多经历 5 次修复迭代。流水线生成 Terraform 代码，进行验证，并将错误反馈给 LLM。
数据量： 分析涵盖了 4,440 个在修复前后均有 Checkow 数据可用的迭代转换。
追踪： 研究追踪了映射到 CIS AWS 基础基准控制项的 30 个独立 Checkov 检查 ID，涵盖六个安全类别（加密、访问控制、日志记录、网络、数据保护及其他）。
检测模式： 为了解决多资源歧义性，研究形式化了两种检测模式：
- 标准模式（包含性/Standard Inclusive）： 如果一个检查 ID 在迭代 $i$ 时出现在通过集合中，而在迭代 $i+1$ 时出现在失败集合中，则计为一次回归，无论该 ID 是否也同时通过了其他资源。
- 严格模式（排他性/Strict Exclusive）： 仅当一个检查 ID 在迭代 $i$ 时被排他性通过（无失败）且在迭代 $i+1$ 时被排他性失败（无通过）时，才计为一次回归。
根因分析： 代码差异（diffs）被划分为四个互斥类别：资源重构（Resource Restructuring）、配置漂移（Configuration Drift）、参数移除（Argument Removal）以及未分类。
统计分析： 研究利用了卡方检验、Mann-Whitney U 检验、Fisher 精确检验以及效应量度量（Cramér's V, Cohen's d），并针对多次比较进行了 Bonferroni 校正。

核心贡献

首次大规模实证研究： 这是首个分析迭代式 LLM 驱动 IaC 修复中逐迭代安全性轨迹的研究，通过超越累积最佳指标来检测安全性回归。
回归分类法： 作者推导出了回归根因的分类法，识别出资源重构是主要原因（在标准模式下占 79.0%）。
检测模式区分： 本文形式化了 标准模式与严格模式 的区别，证明了检测模式的选择会从根本上改变对模型性能和风险分布的结论。
安全性-正确性权衡量化： 研究量化了代码变更与安全性退化之间的关系，表明回归转换涉及显著更高的代码变更量（code churn）和检查波动性（check volatility）。
行动指南： 研究提供了关于迭代预算和配置选择的具体指导，确定了迭代 3 是最佳停止点，并强调了反馈循环的自我修正能力。

关键结果

RQ1：回归频率

标准模式： 13.8% 的场景（24.8% 的转换）表现出至少一次安全性回归。
严格模式： 当过滤掉歧义的、排他性的失败后，回归率降至 3.3% 的场景（5.2% 的转换）。
解读： 标准模式与严格模式之间的差距表明，大约 76% 的表观回归是多资源测量伪影，而非真实的排他性失败。

RQ2：易受攻击的安全控制项

标准模式： 访问控制占据主导地位（38.5%），由 IAM 相关检查（如 CKV_AWS_356, CKV_AWS_111）驱动。
严格模式： 排名发生反转。网络（42.6%）和加密（21.6%）成为主要的风险，而访问控制降至 9.2%。
含义： 访问控制的回归主要是多资源歧义性的产物（例如，一个 IAM 角色通过而另一个失败），而网络和加密的回归则代表了真实的排他性失败。

RQ3：配置因素

模型差距（RAG 配置）： 在标准模式下，Mistral 的回归率比 Gemini 高出 17 倍。然而，这一差距在 RAG 配置的严格模式下完全消失，在严格模式下，RAG+Gemini 和 RAG+Mistral 均未产生任何严格模式场景回归（分别为 0/1,297 和 0/929）。这证实了之前的差距是由于多资源歧义性而非排他性检查失败造成的。
RAG 效应： 与非 RAG 策略相比，RAG 在标准模式下似乎具有更高的回归率，但在严格模式下（相对于非 RAG 策略）具有更低的（零）回归率。这表明 RAG 生成了更全面的多资源结构（增加了标准计数），但为单个安全属性提供了更好的落地依据（减少了排他性失败）。
温度： 温度具有统计学意义上的影响，但在实际应用中微乎其微（Cramér's V = 0.049）。

RQ4：安全性-正确性权衡

代码变更量（Code Churn）： 与非回归转换相比，回归转换涉及 2.6 倍更多的代码变更（行数变化）和更低的文本相似度。
检查波动性（Check Volatility）： 这是回归最强的预测因子。回归转换显示出 4.9 倍更高的严格模式检查波动性（Cohen's d = 1.49）。
语法修复： 紧随语法修复之后的转换在标准模式下具有 21% 更高的回归风险。
“干净”的时间线： 具有反直觉的结果，全程保持有效语法的场景（“干净”的时间线）其回归率（20.8%）高于那些挣扎于语法错误的场景（12.1%）。

其他发现

自我修正： 36.6% 的标准模式回归会在平均 1.2 次迭代内实现自我修正，这表明反馈循环通常能捕捉到自身的错误。
震荡： 28.5% 的场景表现出检查震荡（通过、失败、再次通过），特别是在 IAM 配置中。
最佳停止点： 迭代 3 被确定为最佳停止点，它在保持 83.1% 的通过率（与峰值仅差 0.3 个百分点）的同时，将回归风险控制在可控范围内。

意义与主张

本文声称提供了第一个关于迭代式 IaC 修复引入安全性回归的实证证据，尽管其严重程度取决于检测方法。作者断言，虽然“保守且可辩护的真实排他性回归率”约为 3.3%，但这一现象是不容忽视的，并且完全被先前工作中使用的累积最佳指标所掩盖。

研究强调，资源重构是导致退化的主要驱动力，而非仅仅是提示策略或温度本身。研究结果为设计具备安全性感知能力的反馈循环提供了动力，此类循环应：

区分多资源伪影与排他性失败。
实现“安全性锚定（security anchoring）”，以防止模型在仅需微调时重新生成整个资源块。
采用约 3 次迭代的迭代预算，以平衡合规增益与回归风险。
利用检查波动性作为停止或标记修复循环的实时信号。

作者总结道，虽然迭代式修复提高了整体合规性，但它引入了一种特定类型的安全性退化，这种退化需要新的检测方法论和操作保障，特别是考虑到 IaC 的声明式和多资源特性。