实证软件工程TerraProbe：一种用于检测LLM辅助Terraform中欺骗性修复的分层预言框架

###### 摘要  
Terraform基础设施即代码中的安全配置错误代表了云部署中一个已记录且日益增长的攻击面，大型语言模型正越来越多地被用作自动修复智能体。现有评估仍不充分：大多研究仅在目标静态分析发现消失时宣称修复成功，忽略了计划有效性、行为比较和安全意图对齐。本文提出TerraProbe，一个五层预言评估框架，应用于由三个模型（gemini-2.5-flash-lite、GPT-4o 和 Claude 3.5 Sonnet）在两条轨道（68 个真实世界 TerraDS 模块和 28 个受控注入缺陷模块）上生成的 288 次首轮 LLM 修复。使用卡方检验和 Fisher 精确检验对两条轨道进行统计比较，发现计划比较可达性存在显著差异（卡方=31.64，p<<0.001，Cohen’s h=1.36），并且 TerraDS 裁决案例中的欺骗性修复率在所有三个模型间无统计学差异（57.1%–71.4%，所有两两比较的 Fisher 精确检验 p>>0.10），这证实了在研究所条件下（首轮修复、最小无安全意图提示、三个前沿指令遵循模型），欺骗性修复模式是系统性的，而非特定于模型。本文分析了三种候选机制（训练分布偏差、检查规范差距和提示欠规格），以解释为何无论模型能力如何都会出现欺骗性修复。论文引入了欺骗性修复的形式化定义分类法，沿四个维度（机制、意图对齐、安全影响和检测难度）组织，评分者间信度 Kappa=0.78（Krippendorff 阿尔法=0.76）。IAM 权限级别分析确认，在所有九个 CKV2\_AWS\_11 欺骗性修复案例中，通配符 Resource 授权在修复后仍被保留，代表了未缓解的权限提升风险。提供了完整的复现包，包括提示、语料库、评估脚本和可复现 Docker 镜像。论文还提出了多层预言评估框架，将 TerraProbe 抽象为适用于任何 IaC 技术的领域通用评估设计。因此，TerraProbe 贡献的是一种评估方法论，而非另一个修复模型，从而将意图对齐的安全修复与通过扫描器的虚假成功区分开来。

###### 关键词：  
基础设施即代码、Terraform、安全配置错误、大型语言模型、多模型评估、自动程序修复、Checkov、评估框架、预言堆栈、欺骗性修复分类法、评分者间信度、IAM 权限分析、统计假设检验、云安全、可复现性

## 1 引言  
云基础设施越来越多地以代码形式存在。声明式基础设施即代码（IaC）重塑了组织配置、复制和审计其云环境的方式。由 HashiCorp 开发的 Terraform 是多云部署中主要的 IaC 语言。通过其 HashiCorp 配置语言（HCL），工程师将 AWS、Azure 和 GCP 资源描述为结构化文件，这些文件可由静态分析工具扫描[29]。Checkov[23] 针对精选的安全策略库评估 Terraform 模块，并输出二进制的确定性检查发现。

大型语言模型已成为 IaC 安全发现处理中的可行修复智能体。近期系统显示，LLM 在受控实验中能清除相当比例的针对性发现[7,8,9,10,18]。其吸引力直接：模型处理真实世界配置的语法多样性，无需为每条发现预设修复模板。然而，清除一条针对性发现并不等同于产生可信的修复。考虑这样一个模型：它重组了 IAM 策略，使得通配符 Resource 检查（Checkov CKV2\_AWS\_11）不再触发。发现被清除了，但检查原本意图禁止的通配符授权仍然存在：扫描器通过、terraform plan 通过，但不受限制的权限仍保留。这一案例贯穿我们的结果，是检查通过型修复与安全意图满足型修复之间差距的最清晰实例，也是本文所要解决的评估问题的核心锚点。

自动程序修复中的预言问题，由 Monperrus 形式化，指出满足测试套件的修复并不一定满足程序规约[34]。在 IaC 安全修复中，类似的风险是：检查通过的修复并不一定满足检查背后的安全意图。Pearce 等人确认，标记发现的消失不能等同于输出是安全的[28]。Hou 等人通过对 395 篇 LLM4SE 论文的系统性回顾确认，安全意图对齐是该领域研究最少的评估属性之一[42]。

本文认为，先前对 LLM 辅助 IaC 修复的评估存在三个相互叠加的弱点。第一，它们止步于目标发现的移除，即最弱的预言信号。第二，它们评估单个模型，无法区分模型特定行为与系统性 LLM 失效模式。第三，它们不应用假设检验或效应量度量，使得研究间比较无法进行。每个弱点都可以通过分层预言评估、多模型比较以及来自经验软件工程的统计标准方法来解决[37,38]。

核心贡献是方法论上的：TerraProbe 不是另一个 LLM 修复模型，而是一个用于检测虚假修复成功的预言框架——即那些目标扫描器发现已被清除，但潜在安全意图并未满足的修复。本文做出九项贡献。它引入了 TerraProbe，一个基于 Terraform 工具链的五层预言堆栈。它呈现了跨三个 LLM 的多模型比较。它对所有主要的跨轨道比较应用了卡方检验、Fisher 精确检验和 Cohen’s h 效应量。它考察了为何 LLM 会产生欺骗性修复的三种候选机制。它引入了欺骗性修复的形式化定义。它引入了一个四维欺骗性修复分类法，Kappa=0.78。它提供了每个欺骗性修复案例的 IAM 权限级别分析，将评估扩展到静态分析工具输出之外。它提出了用于领域通用 IaC 安全评估的 MLOE 框架。最后，它发布了完整的复现包。

核心结果在于浅层预言报告与分层预言揭示之间的分歧：跨主要模型，针对性 Checkov 移除成功率为 83.3%，但完整扫描仪清洁度仅为 10.4%，产生有效计划的比例为 39.6%，计划比较证据可及的比例为 38.5%。在经计划比较的真实世界（TerraDS）修复中，71.4% 是欺骗性修复——它们通过了所有自动预言但令标记的漏洞未动。83.3% 的表面成功率与这些深层信号之间的距离，是本文的核心证据，表明目标发现移除在结构上是不充分的成功标准。

在五层预言堆栈中，首轮 LLM 生成的 Terraform 修复以多大比例满足每个评估信号？损耗模式揭示了目标移除与可信修复之间的何种差距？计划比较结果和人工裁决结果在真实世界 Terraform 模块修复与受控注入缺陷模块修复之间有何差异？欺骗性修复模式是否在多个 LLM 间保持一致？

## 2 背景与相关工作

### 2.1 大规模基础设施即代码安全  
IaC 配置即软件。Drosos 等人通过 360 个 IaC 错误的实证研究确认了这一点：配置错误占错误的 27%，修复平均涉及 8 行代码变更[22]。在大规模层面，Rahman 和 Williams 对 Ansible 和 Chef 脚本中的安全异味进行了分类，将诸如 admin\_by\_default 和硬编码凭据等模式列为最高严重性类别[25]。Vo 等人发现，在调查的 Terraform 存储库中，84.5% 存在 admin\_by\_default 异味，确认了过度宽松的 IAM 策略是生产 IaC 中最普遍的安全缺陷之一[19]。NIST SSDF 要求在流水线多个阶段进行自动化分析[26]。Rahman 等人的结构性文献综述确认，配置层面的安全问题普遍存在，但在修复和验证层面仍被低估[29]。借鉴从业者调查，Guerriero 等人发现自动化质量检查的应用不一致，最大差距出现在部署验证阶段[30]。Minna 等人将这一证据扩展到 Kubernetes 清单，在 Helm Chart 安全性研究中观察到类似的配置错误模式跨越容器编排上下文[17]。

### 2.2 自动程序修复与预言问题  
自动程序修复（APR）一直以测试通过的补丁作为其首要正确性标准。Monperrus 全面调查了该领域并形式化了预言问题：测试通过的修复不一定满足程序规约，过度拟合测试预言是一种有记录的失效模式，会产生看似合理但错误的补丁[34]。在 ICSE 2023 上，Xia 等人显示 LLM 在 Defects4J 上优于基于模板的 APR 系统[16]，Sobania 等人报告 ChatGPT 首次尝试即正确修复了 40 个 Defects4J 错误中的 19 个[36]。Chen 等人的 HumanEval 基准将功能正确性确立为 LLM 代码评估标准[27]，但功能正确性基准惩罚的是错误功能，而非错误的安全意图。与 IaC 修复的直接类比是：一个目标发现移除率（pass@1）是针对单个弱预言进行评估的。现有的 APR 基准均未明确惩罚那些通过预言但违反预言旨在编码的安全规约的修复。这一差距激发了第五章中形式化定义和分类法的动机。

### 2.3 LLM 辅助的 IaC 安全修复  
Low 等人构建了一个两遍 GPT-4 流水线，减少了 84.7% 的 Checkov 警报，但 20.4% 的表面成功未通过模式验证或未解决实际的配置错误[1]。Diaz-de-Arcaya 等人将修复扩展到 Ansible，使用受限 LLM 生成[10]。Reyes 等人对 6149 个 Terraform 脚本进行了微调，但仅报告了 BLEU 和 ROUGE 指标，无法检测欺骗性修复[18]。Apuri 等人构建了一个自主多智能体架构，实现了 96.8% 的漂移检测，但未进行计划级评估[20]。Davidson 等人发布了 Multi-IaC-Eval，一个跨多个云提供商的系统性基准[6]。Sallou 等人的 Detect-Repair-Verify 框架增加了部分 L3 评估，但止步于计划比较[7]。GenSIaC 关注生成而非修复[8]。TerraFormer[5] 同样针对自动 Terraform 生成而非修复。没有先前研究对组间比较应用假设检验、在计划比较级别评估超过一个模型、或进行人工裁决以将预期修复与欺骗性修复分开。先前工作中的系统性差距不是一个数据问题——TerraDS[2] 提供了足够的真实世界语料——而是方法论问题：预言堆栈太浅，无法捕捉本研究记录的这种失效模式。

### 2.4 LLM 在安全敏感代码生成中的行为  
关于 LLM 辅助代码生成的工作已记录了一个一致的模式：模型优化的是语法正确性和检查满足性，而非语义安全属性。Pearce 等人通过受控实验证明，GitHub Copilot 在 40% 的生成函数中引入了高严重性 CWE 违规，即使在明确的安全敏感上下文中也是如此[28]。核心发现是，在公共存储库上训练的模型学会生成匹配这些语料库表面统计模式的代码。这些模式绝大多数语法有效，但通常安全性不足。Nazzal 等人表明，提示优化可以降低生成代码中的漏洞率[21]。然而，优化的提示无法消除源于训练分布差距而非提示清晰度的漏洞。Nahar 等人将这一分析扩展到基于 LLM 的安全代码审查，发现模型系统性地遗漏了那些需要跨检查级规约与策略级意图之间差距进行推理的安全属性[43]。SecurityEval 基准[44] 通过测试生成的代码是否避免 CWE 列出的漏洞处理了一个相关问题。SecurityEval 将漏洞缺失视为一个二值标准，类似于 LLM 辅助 IaC 修复中的目标发现移除标准，并未区分语法缺失与语义安全。Wei 等人严格评估了七个 LLM，发现 pass@k 指标表现出高模型间方差[45]。这激励了本文的多模型设计以及我们研究中发现的欺骗性修复概率的系统性（而非特定于模型）性质。