技术摘要：开发者能否依赖 LLM 进行安全的 IaC 开发？

问题陈述

基础设施即代码（IaC）对于自动化基础设施管理至关重要，但经常受到“安全异味”（security smells）的困扰——这些是表明存在不良安全实践的重复模式，例如硬编码密钥、弱加密算法和无效的 IP 绑定。尽管已存在专门的工具（如 SLIC、SLAC）来检测这些问题，但其采用率仍然较低。与此同时，开发者正越来越多地采用大语言模型（LLM）进行编码辅助。本研究旨在解决一个关键差距：缺乏关于专有 LLM（特别是 GPT-4o 和 Gemini 2.0 Flash）在有效检测现有 IaC 脚本中的安全异味以及从零开始生成安全 IaC 方面的能力实证证据。作者强调了一个特定的风险，即 LLM 可能会生成功能性代码，但却在未发出警告的情况下，无意中包含了严重的漏洞（例如，硬编码密码、不带 TLS 的 HTTP），这可能会给开发者带来一种虚假的安全感。

研究方法

本研究采用了两阶段的实证方法，涉及两个不同的数据集：Stack Overflow (SO) 代码片段和真实的 GitHub 仓库。

1. 数据集与范围

• 工具： 研究重点关注 Ansible（命令式）和 Puppet（声明式），这是最广泛使用的 IaC 工具。
• 安全异味： 评估针对九种特定的安全异味（S1–S9），包括硬编码密钥、空密码、弱加密（SHA1/MD5）、默认管理员配置、不带 TLS 的 HTTP、缺失完整性检查、无效 IP 绑定（0.0.0.0）、可疑注释以及缺失默认情况语句（default case statements）。
• Stack Overflow 研究：
  • 数据： 通过关键词搜索（如“password”、“HTTP”、“TODO”）过滤了 2,569 个带有 Ansible 或 Puppet 标签的 SO 帖子。
  • 地面真值（Ground Truth）： 两名研究人员手动审查了代码片段，识别出 169 个不安全示例。评分者间信度很高（Cohen's kappa = 0.93）。
• GitHub 研究：
  • 数据： 从最先进的文献复现包和直接 GitHub 搜索中收集了共计 21,757 个文件。
  • 采样： 手动对 430 个文件（302 个来自文献，128 个来自搜索）的代表性子集进行了分类，揭示了 341 个具有安全异味的实例。
  • 合成场景： 基于这 341 个不安全模式，设计了 89 个独特的合成场景，用于测试代码生成能力。

2. 实验设计

研究在两种提示条件下评估 LLM：

1. 通用提示（General Prompt）： 一个标准的请求，要求模型从安全角度分析代码（例如，“作为一名安全专家，请分析代码……”）。
2. 引导提示（Guided Prompt）： 一种结构化的、分步骤的指令，要求模型识别工具、列出异味、精确审查代码/注释，并以特定的 CSV 格式输出结果。这旨在减少冗余和幻觉。

评估任务：

• 检测： 评估模型识别所提供代码片段中现有安全异味的能力。
• 修复建议： 分析模型是提供可操作的代码修复，还是仅提供通用的建议。
• 生成： 使用 89 个合成场景提示模型生成 IaC 脚本，衡量安全输出的比例以及针对不安全模式发出警告的频率。

关键结果

安全异味检测

• Stack Overflow（小型代码片段）：
  • 通用提示： GPT-4o 检测到了 80% 的异味；Gemini 检测到了 71%。
  • 引导提示： 性能提升至 88% (GPT-4o) 和 78% (Gemini)。
• GitHub（真实世界项目）：
  • 通用提示： 性能显著下降。GPT-4o 仅检测到 42%，Gemini 检测到 51% 的异味。
  • 引导提示： GPT-4o 的 F1 分数从 58% 上升到 89%；Gemini 的 F1 分数从 66% 上升到 74%。
  • 观察： 对于 Puppet（声明式）的检测率始终高于 Ansible（命令式/基于 YAML），这可能是由于 Puppet 严谨的结构有助于模式识别。
• 特定异味： 即使使用引导提示，“可疑注释”（S8）的检测也特别具有挑战性，而“不带 TLS 的 HTTP”（S5）则更容易被检测到。

安全代码生成

• 基准性能： 当在没有明确安全约束的情况下，提示模型为易产生漏洞的场景生成代码时，仅有 7% 的生成的脚本是完全安全的。
  • GPT-4o 有 75% 的输出和 Gemini 有 56% 的输出包含安全异味，且未发出任何警告。
• 显式安全指令： 即使明确提示“生成安全代码”：
  • GPT-4o 仅有 17% 的输出是完全安全的，Gemini 仅有 8%。
  • 很大一部分（GPT-4o 为 44%，Gemini 为 34%）仍然包含安全异味，且没有任何随附的警告。
• 修复建议： 虽然模型经常提供通用建议（93–96%），但它们很少提供明确的代码修复（GPT-4o: 15%, Gemini: 5%）。

意义与主张

论文声称，虽然 LLM 在检测 IaC 中的安全异味方面表现出潜力（特别是在受结构化提示引导时），但它们目前无法被可靠地作为安全 IaC 开发的独立工具。

• 提示敏感性： LLM 的有效性高度依赖于提示工程。通用提示往往无法检测出复杂、真实世界仓库中的一半以上的安全问题。
• 生成风险： 最关键的发现是安全代码生成的失败率极高。模型经常生成不安全的代码，却不标记这些漏洞，即使在被明确要求要保证安全时也是如此。这表明存在开发者接收到“虚假安全感”的风险。
• 上下文局限性： 与 Puppet 的声明式严谨性相比，LLM 在处理 Ansible 的灵活性方面更为困难，并且在处理简化片段（SO）时比处理大规模项目脚本（GitHub）的表现更好。

作者得出结论，需要进一步的研究来提高 LLM 在该领域的处理能力。他们强调，开发者不应仅仅依赖 LLM 来进行安全保障，且研究界必须开发更好的提示策略和工具来减轻这些风险。作者已发布了包括 89 个合成场景在内的复现包，以促进未来的研究。