基于大语言模型的网络靶场故意脆弱容器化环境生成研究

《Computer Networks》：LLM-assisted generation of intentionally vulnerable containerized environments for cyber ranges

　　

摘要专业翻译 网络靶场是安全团队不可或缺的训练平台；然而，创建故意脆弱的环境仍然是一项劳动密集型工作。尽管Docker等现代虚拟化技术实现了“基础设施即代码”（Infrastructure as Code）方法，且大语言模型（Large Language Models，LLMs）显著降低了代码生成所需的工作量，创建可利用场景仍是一项挑战。这需要解析依赖关系、配置互联服务，并确保明确的利用前置条件，然而LLMs在实现这些场景方面的有效性在很大程度上仍未得到探索。本文对LLM辅助的故意脆弱容器化环境生成进行了系统性探索性研究。研究在零样本（zero-shot）条件下比较了不同的生成范式（服务型与Web应用型、基于包构建与基于源码构建、单容器与基于Compose的部署）。研究采用两阶段协议评估了六个LLM：第一阶段，选取具有最低平均加权错误得分（Weighted Error Score，WES）的模型；第二阶段，对22个漏洞（12个服务和10个Web应用）进行配对部署策略的深入分析，共计44次生成尝试和40个分析场景（4次因伦理拒绝除外）。 关键发现确立了清晰的可行性边界。尽管最先进的模型（如Gemini3-Pro、GPT-5.2）将构建失败率从81.5%降至51.9%，但其生成完全可用、可利用环境的能力仍然有限。具体而言，虽然功能正确性（构建/运行）根据策略不同可达37.5%–50.0%，但向可利用性的过渡是主要失败点，仅有5.0%（40个场景中的2个）被证明是可利用的。 研究引入了一种基于两个指标的面向修复的分析方法，用于评估修复不正确Dockerfile的影响变化和自动化挑战。该分析表明，策略选择显著影响修复负担：基于包的服务比基于源码的服务需要更高的结构性和自动化努力，而基于Compose的Web部署比捆绑配置产生更好的功能结果。此外，研究结果凸显了服务部署中的实际权衡：尽管构建复杂度更高，但基于源码的重建在漏洞保真度方面更优。这是因为发行版软件包通常包含下游安全补丁回移（security backports），即使版本标识符表明存在漏洞，这些补丁也会静默缓解漏洞。 最后，研究提供了构建、执行和利用错误的分类体系。所有实验数据，包括带注释的AI生成Dockerfile和提示词，均已公开。本研究确立了零样本LLM生成方法的潜力与当前局限，为未来工具增强方法的研究提供了基准。

论文解读

一、研究背景与问题

网络安全培训是提升企业整体安全态势最有效的方法之一。网络靶场（Cyber Range）为技术团队提供了模拟脆弱环境，使其能够在不对真实基础设施构成风险的情况下训练攻击技术。现代虚拟化技术，特别是Docker，使得“基础设施即代码”（Infrastructure as Code）范式能够创建此类场景。然而，场景创建仍然高度依赖人工：团队必须安装易受攻击的版本、解析依赖关系并配置利用前置条件，这一过程限制了规模化和可重复性。

大语言模型（LLMs）在代码生成任务中已展现出卓越性能。尽管近期有研究探索了基于LLM的Docker镜像生成，但该研究领域仍处于早期阶段。截至撰写时，尚无工作探索通过大语言模型自动实现故意脆弱的基础设施。这一研究空白在网络靶场领域尤为突出，因为脆弱环境不仅是运行中的应用程序，还需要特定配置和条件才能被利用。一个根本性挑战是LLMs难以可靠地将通用漏洞披露标识符（CVE）映射到对应的脆弱软件。例如，当被提示为CVE-2023-2636（影响AN_GradeBook WordPress插件）生成Dockerfile时，LLMs可能产生幻觉，为OpenSSH等无关应用生成Dockerfile。生成的输出常常在执行或利用阶段失败，这在网络靶场环境中至关重要，因为训练价值取决于可利用性。

二、研究内容与结论

本文对LLM生成故意脆弱环境的能力进行了系统性探索性研究，比较了不同生成范式（服务型与Web应用型、基于包构建与基于源码构建、单容器与基于Compose的部署），在零样本条件下评估了六个大语言模型。研究同时评估了功能正确性和可利用性，以及通过结构性和自动化维度评估修复工作量。

研究采用两阶段实证协议：第一阶段为模型选择试点，第二阶段为确认性策略比较。第一阶段评估了六个模型（ChatGPT、Bing、Gemini、Gemini3-Pro及两个GPT-5.2变体），共54个脆弱场景；第二阶段使用选定模型对22个漏洞（12个服务和10个Web应用）进行配对策略比较，共44次生成尝试，其中40个场景进入分析（4次因伦理拒绝）。总计98次生成尝试，产出94个Docker制品。研究为每个第二阶段场景开发了概念验证利用（proof-of-concept exploits）以验证可利用性，并系统分析错误以识别生成失败的根本原因。

研究的关键发现包括：最先进模型将构建失败率从81.5%降至51.9%，但生成完全可利用环境的能力仍然有限。功能正确性（构建/运行）根据策略不同可达37.5%–50.0%，但向可利用性的过渡是主要失败点，仅有5.0%（40个场景中的2个）被证明可利用。研究引入的面向修复的分析表明，策略选择显著影响修复负担：基于包的服务需要更高的结构性和自动化努力，而基于Compose的Web部署比捆绑配置产生更好的功能结果。研究还发现，尽管构建复杂度更高，基于源码的重建在漏洞保真度方面更优，因为发行版软件包常包含下游安全补丁回移，即使版本标识符表明存在漏洞，这些补丁也会静默缓解漏洞。

三、关键技术方法

研究采用的主要技术方法包括：第一，两阶段实证协议设计，第一阶段使用加权错误得分（Weighted Error Score，WES）作为复合指标进行模型选择，该指标综合功能结果和错误严重程度；第二，零样本、单次生成、无工具的提示策略，提示词明确提供目标应用名称、脆弱版本和部署指令，但不包含CVE描述、利用前置条件或参考配置；第三，配对部署策略比较，对服务采用基于包与基于源码两种构建方式，对Web应用采用捆绑与Compose两种部署方式；第四，面向修复的分析框架，基于结构影响和自动化挑战两个维度评估修复工作量；第五，概念验证利用验证方法，使用Exploit-DB和VulnHub的公开利用代码验证环境可利用性。样本队列来源包括Exploit-DB和VulnHub仓库，从中选取具有已知脆弱版本和公开利用的CVE，按应用类型（服务与Web应用）进行分层随机抽样。

四、研究结果

4.1 模型选择与功能结果。 第一阶段通过WES指标在六个模型中筛选出表现最优的模型进入第二阶段。第二阶段中，构建失败率从早期模型的81.5%降至最先进模型的51.9%，功能正确性（构建/运行）根据部署策略不同达到37.5%–50.0%。

4.2 可利用性结果。 对40个分析场景进行概念验证利用验证，仅有2个场景（5.0%）被证明完全可利用。从运行服务到可利用环境的过渡是主要失败点，而非构建或运行阶段。

4.3 错误分类体系。 研究提供了构建、执行和利用错误的分类体系（taxonomy），系统识别了各阶段失败的根本原因。

4.4 修复分析。 基于结构影响和自动化挑战两个维度的修复分析表明，策略选择显著影响修复负担：基于包的服务比基于源码的服务需要更高的结构性和自动化努力；基于Compose的Web部署比捆绑配置产生更好的功能结果。

4.5 漏洞保真度权衡。 研究结果凸显了服务部署中的实际权衡：尽管基于源码的重建构建复杂度更高，但在漏洞保真度方面更优。发行版软件包中的下游安全补丁回移会静默缓解漏洞，即使版本标识符表明存在漏洞。

五、讨论与结论

讨论部分指出，研究确立的零样本、单次生成、无工具设置建立了受控参考基线，避免将基于提示词的生成与工具选择、细化策略和执行反馈循环混淆。这一基线为未来检索增强、工具增强和智能体增强流水线的比较提供了参照。研究提出七条实用指南，涵盖部署策略选择、利用验证、依赖解析、修复升级和制品版本控制等方面，每条指南均与评估中的具体发现相关联。

研究结论部分指出，本研究确立了零样本LLM生成方法在故意脆弱容器化环境生成方面的潜力与当前局限。尽管最先进模型在功能正确性方面有所改善，但从运行服务到可利用环境的过渡仍是主要瓶颈。研究提供的错误分类体系、修复分析框架和公开数据集为未来工具增强方法的研究建立了基准。未来研究方向包括检索与生成的结合、智能体增强流水线，以及多漏洞链式场景的生成。

研究的意义在于：首次系统评估了LLM在生成故意脆弱环境方面的能力边界，为网络靶场自动化场景生成提供了实证依据；引入的修复导向分析框架和错误分类体系为后续研究提供了方法论基础；公开的实验数据和制品支持可复现性和可扩展性研究。