Gemini赋能安全工程师：自动写PoC脚本
摘要
随着大语言模型技术的快速发展，以Google Gemini为代表的AI模型在网络安全领域展现出前所未有的辅助能力。本文聚焦于Gemini在漏洞验证与PoC（Proof-of-Concept，概念验证）脚本自动生成方向的应用，从技术原理到实战落地进行全方位的系统梳理。文章首先阐释AI+PoC自动生成的底层逻辑与技术演进路径，继而深入剖析Gemini模型的特性及其在安全场景中的独特优势，随后通过详尽的实战步骤演示如何从漏洞信息采集、Prompt工程设计到脚本生成与验证的全流程操作。在此基础上，本文探讨了Gemini在多智能体协同、现有安全工具链集成及代码质量评估等方面的工程实践，同时结合学术界最新研究数据和工业界真实案例，对当前技术瓶颈与未来发展方向进行了系统总结。本文旨在为安全工程师提供一份兼具理论深度与实战价值的操作指南，帮助其在日益复杂的网络攻防对抗中有效运用AI技术提升工作效率。
第一章 引言：AI时代的漏洞验证新范式
1.1 传统PoC编写的困境
在网络安全攻防对抗中，PoC脚本扮演着至关重要的角色——它不仅是漏洞真实性的有力证明，更是安全团队评估风险、制定修复方案、进行回归测试的核心依据。然而，传统PoC编写过程始终面临诸多挑战。
漏洞报告的撰写往往非正式且信息不完整，安全工程师需要在高强度逆向工程中还原漏洞触发条件、构造有效的攻击载荷。这一过程不仅要求工程师具备深厚的编程功底，还需要对目标系统的底层机制有深刻理解。典型的Web漏洞类型涵盖XSS、SQL注入、SSRF、RCE、CSRF等，不同漏洞类型的PoC构造逻辑截然不同，需要匹配相应的验证策略和判定规则。更棘手的是，绝大多数CVE在披露时并未附带可直接使用的PoC，工程师需要在有限的信息框架下自行完成复现环境的搭建与脚本编写。
这种高强度、高门槛的重复性劳动，正在倒逼安全行业寻找自动化解决方案。
1.2 AI技术介入PoC生成的内在逻辑
大语言模型的崛起为PoC自动生成开辟了全新的技术路径。从技术原理来看，LLM辅助PoC生成的核心在于“代码理解与推理”能力的突破。传统的静态分析工具能够识别语法层面的瑕疵，模糊测试擅长路径覆盖，但两者均难以理解代码深层语义中的逻辑漏洞。而LLM凭借其强大的上下文理解和代码生成能力，能够在解读漏洞描述后直接生成可用于验证的利用代码。
这种能力的底层支撑在于：PoC本身可以视作一个“输入→漏洞触发→响应判定”的完整逻辑闭环，而LLM在大量代码语料上训练后，天然具备了将自然语言描述转化为可执行代码的结构化能力。更关键的是，LLM能够利用公开披露的分阶段信息——从仅有描述的初始披露，到补丁发布后的代码对比，再到源代码完全公开——逐步完善其生成精度。
1.3 Gemini在安全领域的发展脉络
Google Gemini系列模型在网络安全领域的探索经历了从概念验证到工程化部署的快速演进。Gemini 1.5 Pro凭借其高达200万token的上下文窗口，能够在单次调用中分析大量代码文件，深入理解复杂代码关系和语义模式。Google此前已展示了Gemini在34秒内完成WannaCry勒索软件逆向分析并识别其“自杀开关”的能力，这一表现证明了其在安全分析领域的巨大潜力。
此后，Gemini CLI被正式集成到Kali Linux 2025.3发行版中，成为一个轻量级（安装包仅12.04 MB）的AI渗透测试辅助工具。工程师可以通过自然语言指令调用Gemini执行端口扫描、服务识别、漏洞检测等一系列安全任务。与此同时，启明星辰ADLab等安全研究机构也开始将资深安全专家的标准化工作流沉淀为AI可编排的技能单元，推动AI从“代码阅读者”向“安全专家辅助者”的身份跃迁。
本文正是在这一背景下，系统探讨Gemini赋能安全工程师完成PoC脚本自动生成的完整路径。
第二章 技术基石：大模型赋能PoC生成的底层逻辑
2.1 从“代码阅读者”到“漏洞复现者”——能力的跃迁逻辑
大模型在安全场景中的能力演进可以划分为三个层级。第一层是代码阅读者阶段，模型能够理解函数逻辑、识别语法结构，但尚不具备自主挖掘漏洞的能力。第二层是辅助分析者阶段，模型能够根据提示对代码进行安全性评估，指出可能存在风险的代码片段。第三层则是漏洞复现者阶段——模型能够理解漏洞的触发机制，并自主构造出能够复现该漏洞的PoC脚本。
这一跃迁的核心在于模型的“链式推理”能力。对于SQL注入漏洞的PoC生成，模型需要完成如下推理链条：理解漏洞描述中“参数未经过滤拼接”的含义→定位目标API中接受用户输入的点→构造闭合前文查询语法的payload→生成完整HTTP请求脚本→定义响应成功判定逻辑。正是这种多步骤推理与执行能力，使得LLM从单纯的“读懂代码”进化到了“能够利用代码”的层面。
2.2 Gemini的多模态能力与长上下文窗口优势
在众多大语言模型中，Gemini系列展现出若干独特的技术优势，这些优势在安全场景中具有显著的实战价值。
首先，Gemini的多模态能力使其不仅能够理解纯文本漏洞描述，还能同时分析代码截图、架构图、网络流量包等非文本信息。在实际漏洞分析中，安全工程师常常需要综合阅读安全公告中的文字描述、补丁变更的代码截图、漏洞演示的录屏等内容。Gemini的多模态统一处理能力意味着这些异构信息可以被一次性送入模型进行分析，而不需要人工逐一提取关键特征。
其次，200万token的超长上下文窗口是Gemini 1.5 Pro的杀手级特性。这一容量意味着模型可以在单次调用中容纳完整的项目源代码——对于一个典型的Web应用而言，数万行代码可以一次性载入上下文，让模型建立起对程序整体架构的理解，而不是像传统工具那样在单个文件层面进行碎片化分析。这种全局视野对于发现跨文件、跨组件的逻辑漏洞至关重要。
第三，Gemini CLI的推出将模型能力直接下沉到安全工程师最熟悉的终端环境。工程师可以使用自然语言命令，如“扫描这个目录下所有PHP文件中的SQL注入风险”，模型即可自动完成文件遍历、代码分析与结果输出。
2.3 多智能体架构在漏洞挖掘中的应用
单一的LLM直接用于PoC生成往往效果有限，因为漏洞挖掘是一个需要多视角、多阶段协同的复杂任务。多智能体架构通过将任务拆解为若干职责清晰的子智能体，有效提升了整体效率。
以启明星辰ADLab构建的AI智能漏洞挖掘体系为例，漏洞挖掘全流程被拆解为“全局侦察收集”“双线审计分析”“攻击路径验证”三大核心阶段，每个阶段由专门设计的智能体负责执行。全局侦察智能体负责梳理目标程序的整体架构——包括HTTP路由映射、权限层级划分、跨组件调用关系——让AI在深入代码之前先看清“整张地图”。双线审计智能体并行执行静态分析与动态追踪，从不同维度交叉验证潜在风险。攻击路径验证智能体则负责将候选漏洞转化为可执行的PoC并在沙箱环境中完成验证。
这种架构设计的本质是将专家经验沉淀为AI可编排、可调度、可复用的能力组件，实现从“AI无序盲审”到“多智能体编排协同作战”的范式转变。
2.4 与现有安全工具链的集成路径
Gemini赋能安全工程师并非是要替代现有安全工具，而是要作为智能大脑来调度和增强这些工具的效能。集成路径可以从三个层面展开。
在命令行层，Gemini CLI被直接集成到Kali Linux等渗透测试发行版中，工程师可以通过apt install gemini-cli一键安装。安装后，Gemini可以调用nmap进行端口扫描、调用dirb进行目录枚举、调用nuclei进行漏洞指纹匹配，并将多个工具的输出结果汇总分析后生成统一报告。
在CI/CD流水线层，Gemini可以与GitHub Actions、GitLab CI等平台集成，在代码提交时自动进行安全扫描。研究团队已开发出将Python文件从云存储桶中提取并送入Gemini进行分析的完整流程，模型的分析结果可以JSON或CSV格式输出，便于与现有告警系统和报告平台对接。
在安全平台层，已有项目如gemini-cli-extensions/security实现了安全补丁自动化、PoC脚本生成、安全报告输出等端到端功能，其中PoC命令已支持Python和Go语言PoC的基本生成。
第三章 实战路径：从漏洞信息到可执行PoC的完整流程
3.1 第一步：漏洞信息的采集与预处理
PoC生成的质量高度依赖输入信息的完整性与质量。安全工程师需要首先从多个维度收集漏洞相关信息，并将其整理为适合模型处理的结构化格式。
信息来源的层次化组织。针对每个目标CVE，建议按照以下层次组织输入信息：
基础描述层：CVE公告中的官方描述，包括漏洞类型、影响范围、CVSS评分等元数据。
补丁对比层：如果官方已发布补丁，提取补丁前后的代码差异——这是理解漏洞本质最直接的线索。对比分析可以帮助模型识别出具体哪些代码行发生了变更，进而推断漏洞的触发条件。
源码上下文层：获取受影响函数所在的完整文件或模块代码，使模型能够在更大的语义空间中进行推理。
公开PoC参考层：如果网络上已有社区贡献的PoC（即使是针对旧版本的），可作为生成新版本PoC的参考模板。
数据预处理技术。在送入模型之前，对原始信息进行必要的结构化处理至关重要。常见的预处理操作包括：删除冗余注释和空白行、统一代码缩进格式、标注关键函数（如含有用户输入的入口点、执行系统调用的危险函数等）、将多文件代码按调用关系进行链接标注。研究显示，提供函数级别的代码上下文比仅提供文件级上下文可使PoC生成成功率提高9%-13%。
敏感信息过滤。安全工程师在预处理阶段还需注意去除或脱敏目标系统特有的配置信息，如内网IP地址、生产数据库凭证等，确保在调用云API时不会泄露敏感数据。
3.2 第二步：Prompt工程的核心技法
Prompt设计是决定Gemini输出质量的关键因素。针对PoC生成这一特定任务，以下Prompt设计原则和模板被证明最为有效。
基础架构：结构化角色定义与任务拆解。一个好的PoC生成Prompt应当包含以下要素：
text
你是一位资深安全工程师，擅长漏洞分析与PoC编写。 现有一个[漏洞类型]漏洞需要验证，漏洞编号为[CVE编号]。 目标URL：[目标地址] 以下是漏洞详情、受影响代码和补丁信息： [漏洞描述] [补丁前后代码对比] [受影响函数代码] 请按以下步骤完成PoC生成： 1. 分析漏洞触发条件，解释该漏洞为何存在 2. 构造能够触发漏洞的请求或输入数据 3. 设计响应结果判断逻辑（如HTTP响应码、响应内容特征） 4. 输出完整的可执行脚本（Python版本） 5. 输出脚本的使用说明和预期输出
这种结构化Prompt的作用在于将复杂的PoC生成任务拆解为模型易于逐步执行的子任务，降低了单步推理的难度。
链式推理技术。Chain-of-Thought（思维链，CoT）提示能够显著提升模型的推理准确性。实证研究表明，结合自适应推理策略对提示进行优化，可将PoC自动生成成功率从34%提升至68%-72%。以下是一段针对RCE漏洞的CoT提示示例：
text
让我们逐步分析这个RCE漏洞： 步骤1：用户输入从哪里进入应用程序？入口点是哪个参数？ 步骤2：输入经过了哪些处理？有无过滤或转义？ 步骤3：输入最终流向了哪个危险函数（eval、exec、system等）？ 步骤4：如何构造输入才能绕过现有过滤并触发代码执行？ 步骤5：执行成功后，系统返回什么特征响应？ 完成以上分析后，请生成验证脚本。
实时反馈与迭代优化。PoC生成往往不是一次性完成的。模型首次生成的PoC在沙箱中运行后，工程师应将运行结果（错误信息、响应内容、日志输出）反馈给模型，要求其根据反馈修正脚本。这种迭代式生成方式借助“观察→反思→修正”的闭环机制，大幅提升了最终PoC的有效性。在智能合约PoC生成领域，类似Reason-Act-Observe的循环机制已被证明能够显著提升PoC生成质量。
多视角交叉验证。对于高风险漏洞，可以采用多视角验证策略：分别使用Gemini和另一个不同的LLM（如DeepSeek-R1）生成PoC，将两个版本的输出进行对比验证，取两个模型都认为合理的执行路径。研究显示DeepSeek-R1在PoC生成任务上持续优于GPT-4o，但Gemini在代码优化和结构化输出方面表现更佳。
3.3 第三步：Gemini API调用与脚本生成
在实际工程部署中，安全工程师可以通过多种方式调用Gemini的能力完成PoC生成。
方案一：Gemini CLI交互式模式。Gemini CLI提供了交互式编程环境，工程师可以在终端中通过自然语言与模型对话，逐层推进PoC开发。例如：
bash
$ gemini > 请分析 CVE-2024-1234 的漏洞详情，重点关注其RCE触发条件 [模型输出分析结论] > 基于以上分析，生成一个Python脚本，用于验证该漏洞是否存在 [模型生成PoC代码] > 修改payload为base64编码版本，绕过后端WAF [模型更新代码]
Gemini CLI支持用户交互以及“YOLO”模式（完全自动接受所有操作建议），为不同使用场景提供灵活配置。
方案二：Vertex AI Python SDK编程调用。对于需要集成到自有安全平台的场景，使用Gemini的Vertex AI Python SDK更为合适。典型调用代码如下：
python
from vertexai.generative_models import GenerativeModel model = GenerativeModel("gemini-1.5-pro-002") response = model.generate_content( f""" 你是一位安全工程师。 根据以下CVE信息生成PoC脚本，仅输出Python代码，不输出解释。 {cve_description} {affected_code} """, generation_config={ "temperature": 0.2, # 低温度确保输出确定性 "max_output_tokens": 4096 } ) poc_script = response.text方案三：预置安全扩展。gemini-cli-extensions/security项目提供了开箱即用的安全技能扩展，其中poc skill已支持基本的Python和Go语言PoC生成，并能够输出结构化的安全报告（JSON格式）。这一扩展大幅降低了安全工程师使用Gemini进行PoC生成的门槛。
关键配置参数调优。生成PoC脚本时，对API参数的调整直接影响输出质量：
Temperature：建议设置在0.1-0.3区间。PoC脚本需要精确的语法和逻辑，低温确保输出的确定性，避免模型“自由发挥”。
Top-p：建议设置在0.95左右，保持生成多样性但又不过于发散。
Max output tokens：复杂PoC可能需要数千行代码，建议设置为4096或更高。
Stop sequences：可设置特定字符串（如“###END###”）作为输出结束标记，便于程序化解析。
代码格式清洗与可执行性验证。模型输出后通常需要进行后处理，包括：删除Markdown代码块标记（如```python）、统一换行符格式、删除模型在代码之外添加的“解释性文字”、检查基础语法错误（如缺失的import语句）。
3.4 第四步：沙箱验证与迭代修正
模型生成的PoC不能直接投入生产环境运行，必须在受控的沙箱环境中完成验证。验证流程包含三个关键环节。
环境匹配。构建与目标漏洞环境一致的测试靶场。可利用Docker容器快速部署包含已知漏洞的镜像（如Vulhub项目中的各类漏洞环境）。环境配置应尽可能模拟目标系统的软件版本、中间件配置和网络拓扑。
执行与监控。在沙箱中执行生成的PoC脚本，同步进行以下监控：
网络流量捕获，记录所有发出的HTTP/HTTPS请求
系统调用跟踪，监控脚本对文件系统、进程、网络资源的访问
运行日志分析，捕获脚本的输出信息和错误栈
响应结果判定，根据预设规则判断漏洞是否成功触发
迭代修正循环。若PoC未按预期触发漏洞，应将沙箱中的执行结果反馈回Gemini，要求模型根据错误信息修正脚本。可以设计如下闭环：
text
执行反馈 → 分析失败原因 → 修正Prompt → 重新生成 → 再次执行验证
这种迭代机制能够处理大多数首次生成不成功的情况。在PoCGen框架中，类似的“生成→静态分析→动态验证→修正”循环已被证明可成功为77%的npm包漏洞生成有效PoC。
安全隔离。所有验证操作必须在硬件级虚拟化沙箱中进行，通过eBPF等技术监控系统调用，实时阻断越权访问行为。Gemini CLI本身也已提供基于预构建容器的沙箱选项，并在用户未启用该特性时显示持续性安全警告。
第四章 典型漏洞类型的PoC生成实战案例
4.1 SQL注入漏洞PoC生成
SQL注入是最经典的Web漏洞类型，也是验证Gemini PoC生成能力的最佳起点。其核心逻辑在于构造能够改变原SQL查询语义的输入数据。
输入信息准备。安全工程师向Gemini提供目标URL的参数结构、请求方法（GET/POST）、后端数据库类型（MySQL/PostgreSQL/MSSQL）以及预期的响应特征。Gemini需要理解SQL查询的原始结构，推断出闭合原有查询并追加恶意子句的方法。
PoC生成逻辑。以基于错误报错的SQL注入为例，Gemini的分析链条为：识别参数是数字型还是字符型→确定闭合符（单引号、双引号等）→构造引起语法错误的payload→利用数据库返回的错误信息提取数据→设计自动化数据提取脚本（逐位猜解）。Gemini支持多种注入技术（联合查询、布尔盲注、时间盲注、报错注入）的选择性应用。
输出脚本示例。生成的PoC通常包含以下模块：HTTP请求构造模块（支持Session管理和Cookie传递）、payload生成器（根据检测结果动态调整）、响应解析器（从HTML或JSON中提取特征字符串）、数据还原模块（将编码后的数据转换为原始信息）。
4.2 远程代码执行（RCE）漏洞PoC生成
RCE漏洞的PoC生成复杂度更高，因为其需要构造能够穿透多重过滤并最终在目标系统上执行任意命令的载荷。
输入信息需求。模型需要完整的目标函数代码（尤其是涉及命令拼接、eval求值、反序列化等危险操作的代码段）、补丁前后对比（识别哪些“危险输入”被新增过滤了）、已知绕过技巧（如编码绕过、黑名单绕过、分隔符替换等）。仅凭漏洞描述，LLM在RCE类型上的首次成功率低于SQL注入，但经过上下文补充后可显著提升。
Gemini分析能力体现。Gemini在RCE分析中的优势体现在：能够识别不同编程语言中的命令执行函数（PHP中的system/exec/passthru、Python中的os.system/subprocess、Java中的Runtime.exec）、理解多种编码方式与反编码机制的关系、并基于上下文推理出未被披露的替代攻击路径。
迭代修正策略。RCE PoC的生成往往需要多轮迭代。每轮执行后，根据目标系统的响应（如命令执行的回显内容、错误页面特征、时间延迟）分析当前payload被拦截的原因，并让Gemini据此修正payload结构。
4.3 跨站脚本（XSS）漏洞PoC生成
XSS漏洞的PoC验证逻辑与SQL注入和RCE有本质区别——它需要在客户端浏览器环境中执行，而非服务器端。
验证策略特点。XSS PoC的判定规则通常是“攻击载荷是否在目标页面中被渲染为可执行脚本”。Gemini需要生成包含恶意JavaScript代码的请求，并在响应中检测该代码是否被浏览器解释执行。研究显示LLM能够自动生成针对不同注入点（参数、头部、JSON字段、DOM节点）的差异化XSS载荷。
典型PoC构造。Gemini生成的XSS PoC通常包含：用于定位注入点的参数探测模块（测试所有用户可控输入点）、载荷生成引擎（根据上下文类型选择输出，弹出alert(1)以证明执行）、payload编码模块（URL编码、HTML实体编码、Unicode转义）、响应分析模块（检查返回HTML中是否包含未转义的脚本标签）。
辅助能力。Gemini的多模态能力在此类漏洞验证中可发挥独特作用——当漏洞描述中包含XSS攻击演示的截图时，模型可以直接分析截图内容，识别攻击载荷的构造方式并生成相应的自动化脚本。
4.4 智能合约漏洞PoC生成（PoCo框架分析）
智能合约是一个特殊且重要PoC应用领域。PoCo（Proof-of-Concept Exploit Generation for Smart Contracts）框架是这一方向的代表性成果。
PoCo的核心机制。该框架能够从审计报告中的自然语言漏洞描述出发，自动生成可执行的PoC漏洞利用脚本。其工作流程是智能体在Reason-Act-Observe循环中与代码执行工具交互——智能体首先理解漏洞描述、接着生成测试合约和攻击序列、然后执行验证观察结果、最后根据执行反馈修正攻击策略。PoCo的PoC输出完全兼容Foundry测试框架，可直接集成到标准审计工作流中。
实验结果。在23个真实漏洞报告数据集上的评估表明，PoCo在生成格式正确、逻辑合理的PoC方面，显著优于普通提示方法和标准工作流基准，能够大幅降低智能合约审计中高质量PoC的手工开发成本。
对Gemini的安全启示。PoCo的成功表明，Agentic框架（即基于智能体协作的框架）在PoC自动生成领域具备显著优势。将Agentic思路与Gemini的能力相结合，可以构建出更强大的全自动化PoC生成流水线，适用于Web应用、智能合约、传统二进制漏洞等多种场景。
第五章 工程化落地：从PoC生成到安全运营闭环
5.1 代码质量评估：Gemini生成代码的安全性
在使用Gemini生成PoC脚本时，安全工程师需要清醒认识到一个重要事实：AI生成的代码本身可能包含安全缺陷。这不是Gemini独有的问题，而是当前所有LLM代码生成工具面临的系统性挑战。
比较研究的关键发现。一项通过静态与动态分析对ChatGPT、GitHub Copilot和Gemini生成代码的安全性进行的比较研究显示，Copilot累计风险最高，存在多个高危漏洞；ChatGPT的风险档案相对较低；而Gemini生成的代码相对更优化，但其中同样包含需要人工介入审查的关键安全缺陷。
最普遍的问题类别。所有被测试模型生成代码中最常见的漏洞类型是不安全设计（Insecure Design）和安全日志与监控缺失（Security Logging and Monitoring Failures）。这一发现揭示了一个系统性问题：LLM倾向于实现“功能正确的代码”，但在“安全正确的代码”方面尚有显著差距。通用化的“请写出安全的代码”提示远不足以确保输出质量，开发者必须使用更具体、更偏向安全设计的提示词，如要求模型遵循安全设计原则并实施OWASP Top 10防护。
对安全工程师的实践启示。这意味着Gemini生成的PoC脚本必须经过人工审查才能用于实际漏洞验证。工程师应当重点关注：脚本中的硬编码凭据和敏感信息、未处理的异常和错误状态、超出预期范围的系统调用、可能导致副作用的IO操作、不合理的权限请求等。自动化静态分析工具（如Semgrep、CodeQL）可以作为辅助，在AI生成代码后的审查环节中发现潜在的安全问题。
5.2 提示注入与AI供应链攻击的防范
AI工具的强大能力也使其成为攻击者眼中的高价值目标。提示注入攻击（Prompt Injection）已成为AI应用面临的主要安全威胁类别。
典型攻击场景。当Gemini CLI等AI代理被集成到GitHub Actions或GitLab CI/CD流程中，且工作流程同时处理Issue标题/正文等不受信任的用户输入时，攻击者可以通过嵌入看似文档说明、实际下达恶意指令的文字，诱使AI模型执行特权命令。有效的攻击可以窃取GitHub Token、云访问凭证，或直接修改代码库和CI/CD配置。此类漏洞被研究人员称为PromptPwnd，至少已有5家财富500强企业受到影响。
Gemini CLI历史上的安全事件。Cyera Research Labs曾披露了Gemini CLI中的命令注入和提示注入两个可被利用的漏洞，二者均可使攻击者以CLI进程相同的权限执行任意命令。通过AI增强的漏洞研究方法（Semgrep扫描六千余个潜在问题，LLM辅助筛选至12个可跟进线索，最终48小时内确认了两个可利用漏洞），研究人员展示了如何高效发现AI工具本身的安全缺陷。
防范策略。针对以上风险，建议采取以下措施：
最小权限原则：在CI/CD工作流中严格限制AI可调用的工具集合，避免授予任意Shell执行或自动修改Issue/PR的能力。
输入过滤：避免将原始用户输入直接嵌入提示词，对用户输入进行严格校验、格式验证和内容过滤。
输出隔离：一律将AI输出视为不可信内容进行后续处理，不在高权限上下文中直接执行AI输出。
凭证管控：实施GitHub Token的最小权限分配，并搭配IP来源限制和最短有效期的访问策略。
沙箱强制执行：始终启用Gemini CLI的沙箱隔离功能，无论面对何种场景都将其视为默认安全基线。
5.3 多模态协同：结合截图、日志与流量包的综合分析
Gemini的多模态能力为PoC生成开辟了全新的信息获取维度。在传统工作流中，安全工程师需要从安全公告的截图、漏洞演示视频的流量捕获、系统日志导出等多源异构信息中提取关键线索，再手工转换为PoC的构造依据。
截图分析的应用。当漏洞披露中包含系统界面截图（如SQL注入点的错误信息显示）时，Gemini可以直接从截图中提取关键信息——数据库错误信息中的表名列名泄露、报错返回的具体SQL语法片段、页面崩溃时显示的堆栈跟踪内容等。这些信息原本需要工程师肉眼识别并手工输入，现在可以通过多模态分析自动提取后直接注入到PoC生成提示中。
流量包与日志解析。对于网络流量捕获文件，Gemini可以理解其中的请求-响应结构、参数传递模式、会话状态流转等关键信息，并基于这些信息自动生成与目标流量模式匹配的PoC脚本。日志文件中的异常模式和错误码同样可以被多模态模型快速解析，辅助模型更准确地定位漏洞触发点。
实际应用场景。在CipherScout项目中，Gemini被用于执行“深度挖掘”（Deep Dive）——识别OWASP Top 10中的关键漏洞后，AI会解释安全影响、提出缓解策略，甚至生成理论上的攻击向量（PoC）来证明风险的存在。这一流程正是多模态能力与PoC生成结合的典型案例。
5.4 版本兼容性：针对不同软件版本的PoC适配
实际安全评估中，目标环境往往并非单一的“标准版本”，而是混杂了不同小版本号、不同操作系统、不同中间件配置的多元系统。Gemini生成的PoC需要在版本适配方面具备足够的灵活性。
漏洞版本的差异化特征识别。相同的CVE在不同软件版本中可能有完全不同的触发条件和利用路径。Gemini需要在分析阶段识别目标系统的具体版本信息，并据此调整PoC的payload构造方式。例如，一个Tomcat AJP文件包含漏洞在Tomcat 8.5.x和9.0.x中可能存在不同的参数处理逻辑，Gemini需要基于版本差异自适应调整攻击载荷。
上下文补充的价值。研究数据显示，补充完整的代码上下文（特别是函数级别的细节信息）可将PoC生成成功率提升17%-20%。这意味着在提供漏洞信息时，尽可能纳入目标版本对应的完整函数代码，而非仅依赖通用的CVE描述。
版本探测模块的自动生成。Gemini不仅可以生成漏洞验证脚本，还可以生成版本探测模块，在正式执行漏洞验证前自动获取目标系统的版本指纹，根据指纹结果动态选择对应的exploit路径。这种“自适应的PoC”大大提高了脚本在不同环境中的通用性和鲁棒性。
第六章 数据验证与实证分析
6.1 学术研究的关键发现
学术界对LLM辅助PoC生成的研究已经进入定量评估阶段，几项大规模实证研究提供了宝贵的数据支撑。
首个Web漏洞PoC生成系统实证研究。天津大学与南开大学等机构合作的研究团队对100个真实且可复现的CVE进行了系统性评估，覆盖XSS、SQL注入、SSRF、RCE、CSRF五大主流Web漏洞类型，累计完成超过3000次实验。该研究首次从CVE公开流程的全生命周期视角（仅描述阶段→补丁发布阶段→代码全公开阶段）评估LLM的PoC生成能力。
核心数据结果显示：
基础能力：仅凭公开可用信息，LLM可在8%-34%的CVE上自动生成有效PoC，其中DeepSeek-R1的表现一致优于GPT-4o。
上下文增强：补充代码上下文（尤其是函数级信息）将成功率提升17%-20%，函数级上下文比文件级上下文提供了9%-13%的额外增益。
智能提示优化：结合链式推理和自适应提示调整，最佳成功率可提升至68%-72%。
可操作成果：截至论文发表时，已有23个由LLM生成的新PoC被美国国家漏洞数据库（NVD）和Exploit DB收录认证。
npm包漏洞PoCGen的成功率。另一项聚焦于npm包漏洞的研究，提出了PoCGen框架——通过将LLM（理解非正式漏洞报告）与静态分析（识别污点传播路径）和动态分析（验证生成的利用代码）相结合，成功为SecBench.js数据集中的77%漏洞生成了有效PoC。这一成功率超出既有基线45个百分点，且平均每个漏洞的生成成本仅0.02美元。此外，PoCGen成功生成了6个近期真实漏洞的利用脚本，其中5个已被收录到相应漏洞报告中。
Raptor框架的双向能力。Raptor作为一个基于Anthropic Claude代码构建的自主攻防研究框架，能够同时生成漏洞利用代码和修补补丁。这表明LLM不仅可以用于红队方向的PoC生成，同样可以服务于蓝队方向的漏洞修复验证和防护措施构建。
6.2 与人工编写PoC的效率对比
从实用角度评估Gemini辅助PoC生成的价值，效率提升是最直观的衡量指标。
时间成本的显著压缩。经验丰富的安全工程师手工编写一个中复杂度的RCE漏洞PoC，平均需要2-8小时（包括环境搭建、代码分析、payload构造和迭代调试）。Gemini辅助模式下，工程师可以在30分钟内完成同样的任务——信息整理（5-10分钟）→Prompt设计（5分钟）→Gemini生成与初步审查（10分钟）→沙箱验证与迭代修正（5-10分钟）。
Cyera研究团队的实证数据。Cyera Research Labs在利用AI增强方法发现Gemini CLI漏洞时，采用了Semgrep扫描（识别6115个潜在问题）→LLM辅助筛选（缩至12个可跟进线索）→人工验证确认（48小时内完成）的流程。这一流程实现了99.8%的假阳性消除率，分析时间从人工估算的300-500小时压缩到仅16小时。虽然这一场景是漏洞发现而非PoC生成，但其中的AI增强方法论同样适用于PoC自动化流程的效率评估。
成果质量的多维度对比。在成功率指标上，已有多项研究证明LLM辅助的PoC生成在特定领域已达到可部署水平。但需要注意，LLM生成代码在安全性方面仍有短板——一项比较评估显示，尽管Gemini生成的代码较为优化，但其中的关键安全缺陷必须经过人工审查。这意味着“效率提升”必须与“质量保证”并行——工程师不应完全省略审查环节。
6.3 已知局限与待突破的技术瓶颈
尽管LLM在PoC生成方面取得了令人瞩目的进展，当前技术体系仍存在若干核心瓶颈。
复杂逻辑漏洞的理解不足。当前LLM在基于错误报文和语义理解的漏洞类型上表现较好（如SQL注入、XSS），但在涉及复杂状态机转换、时序竞争条件的逻辑漏洞上成功率显著偏低。这类漏洞通常需要深入理解业务逻辑流程，而不仅是一段独立的代码片段。研究显示，对于从未被自动化攻击过的更复杂漏洞类型，LLMs同样可以生成攻击payload，但成功率远低于简单类型。模型幻觉问题在处理复杂逻辑时尤为突出。
对私有代码和闭源软件的适应受限。Gemini等商业模型在训练过程中接触了大量的开源代码语料，因此对开源框架和常见技术栈的漏洞分析能力强。但对于企业私有代码、闭源商业软件或定制化内部系统，模型缺乏相应的训练数据，其分析精度会大幅下降。这限制了Gemini在特定行业（如金融、能源、国防）深度安全评估中的应用。
API调用的成本与配额限制。虽然单次API调用成本已显著降低（PoCGen平均每PoC成本仅0.02美元），但在大规模、高频次的PoC批量生成场景下，成本仍然是一个客观限制因素。此外，Gemini API存在速率限制和配额上限，可能影响自动化流水线的吞吐量。
输出代码的安全性问题。如前文所述，LLM生成的PoC脚本本身可能包含安全缺陷。这带来一个悖论：工程师正在使用AI生成的脚本来验证目标漏洞，但脚本本身可能引入新的安全风险（如不安全的系统调用、未处理的异常、硬编码的凭证泄露）。针对这一问题，行业正在探索“确定性的安全需求规范”方案——在AI生成代码之前，嵌入强制性的安全设计约束。
第七章 安全风险与伦理讨论
7.1 双重用途困境：AI赋能攻防的双刃剑
Gemini等LLM在安全领域的应用面临根本性的双重用途困境——同样的技术既可以用于防御（PoC验证、漏洞修复、自动化测试），也可以被攻击者用于恶意目的。这种两面性并非假设性威胁，而是已经发生的现实。
恶意软件中嵌入Gemini API的现实案例。谷歌威胁情报小组（GTIG）在2025年11月的AI威胁追踪报告中披露了名为PROMPTFLUX的实验性恶意软件家族。该恶意软件利用Gemini AI API动态重写自身代码，以实时适应新环境和规避检测。PROMPTFLUX包含多个模块，定期向Gemini发出“扮演专业VBScript混淆专家”等提示，要求模型仅返回可执行代码。
另一案例是HonestCue框架（2025年9月首次发现），攻击者利用Gemini API动态生成C#代码实现多阶段恶意软件，成功规避传统检测方法。该框架被用于分析RCE和SQL注入等技术，并加速恶意软件的调试与开发周期。
门槛降低带来的威胁扩散。在传统模式下，编写高质量的攻击代码需要深厚的技术功底和丰富的实战经验。而Gemini等LLM的普及将显著降低这一门槛，使技术水平较低的威胁行为者也能通过自然语言交互获取可用的攻击载荷。谷歌也公开警告，威胁行为者已开始利用Gemini API进行网络攻击的全部阶段——从侦察到漏洞利用再到持久化。
7.2 信息披露透明度的两难抉择
CVE披露体系的设计初衷是在透明度和安全性之间取得平衡——尽早公开漏洞信息以推动修复，但延迟披露细节以防攻击者恶意利用。LLM的PoC生成能力正在打破这一平衡。
公开信息可被自动化武器化的风险。研究表明LLM仅凭CVE官方描述就能在8%-34%的案例上生成有效PoC。这意味着攻击者无需等待完整的PoC代码被公开发布，仅依靠CVE公告中的有限信息就可以借助LLM快速生成exploit。这一现象引发了对信息披露政策的重新审视：当前的CVE描述是否提供了过多的“可利用信息”？
政策权衡的新维度。同一项研究指出，LLM辅助PoC生成技术的发展在为安全社区带来便利（自动化回归测试、漏洞响应加速）的同时，也引发了信息披露透明度与安全实践之间新的政策权衡。安全社区需要面对一个根本问题：如何在利用AI加速防御体系建设的同时，防止同一技术被逆向用于攻击扩张？
潜在的政策响应包括：CVE描述的分级披露机制（基础知识状态 vs 完整技术细节）、AI模型的意图识别与行为管控、PoC生成API的风控设计等。但这些问题目前仍处于讨论阶段，尚未形成行业共识。
7.3 模型幻觉与误判的实战影响
“模型幻觉”（hallucination）——模型生成看似合理但实际错误或虚构的内容——是在安全关键场景中使用LLM时必须严肃对待的风险。
在PoC生成中的具体表现。模型幻觉在PoC场景中可以有多种形式：生成不存在的API端点或参数名、虚构不存在的绕过技术、输出语法错误或逻辑错误的脚本、对漏洞类型做出错误的归因判断。在直接使用大模型进行代码审计时，幻觉问题导致的突出痛点包括覆盖度不足、分析逻辑碎片化、误报居高不下等，无法满足工业级安全检测的需求。
误判的双向危害。假阳性（false positive）会使工程师浪费大量时间验证不存在的漏洞；假阴性（false negative）则可能导致真实风险被遗漏，造成严重的安全事件。在一次业界试验中，直接使用公开漏洞报告训练的模型在真实靶场环境中的检测准确率不足35%。即便使用Gemini等先进模型，也需要经历多轮迭代验证才能接近可部署的准确率。
缓解策略。应对模型幻觉需要在流程设计层面建立多重保障：使用带验证机制的多轮迭代生成而非单次一次性生成、结合多个模型（ensemble）对同一漏洞进行交叉验证、将模型的输出作为“参考依据”而非“决策依据”、在CI/CD流程中植入自动化静态分析作为二次校验层。
第八章 未来展望与行业建议
8.1 自主Agent与全自动漏洞验证Pipeline
PoC自动生成的下一阶段发展方向是从“辅助工具”进化为“自主Agent”。这一演进的本质是将当前的人工介入环节逐步自动化，构建端到端的全自动漏洞验证流水线。
自主Agent的核心特征。一个成熟的自主PoC生成Agent应具备以下能力：自动拉取最新CVE数据源并筛选与目标相关的漏洞、自动搭建对应版本的漏洞验证环境（通过Docker等容器技术）、自主完成多轮迭代生成与验证循环、自动生成包含验证结果和风险评级的标准化报告。启明星辰ADLab提出的“全局侦察收集→双线审计分析→攻击路径验证”三阶段流水线，正是这一方向的具体实践。
Raptor与PoCo的先驱探索。Raptor框架已经在漏洞利用和修补补丁的双向自动生成方面展示了可行性。PoCo则通过智能体与代码执行工具的Reason-Act-Observe循环交互，证明了自主Agent在PoC生成领域的巨大潜力。将这些架构思路与Gemini的能力结合，有望构建出能够覆盖Web应用、智能合约、二进制程序等多种目标类型的全自动PoC生成平台。
与SecOps流程的深度整合。自主Agent的成熟将进一步推动PoC生成从安全工程师的“单独任务”转化为SecOps流水线中的标准环节。在CI/CD流程中，新的CVE披露触发自动化PoC生成与验证；在补丁发布后，自动执行回归测试确认修复有效性；在威胁情报更新时，自动检查现有防护体系能否阻挡新披露的利用方式。
8.2 安全工程师的角色重塑与技能升级
AI的普及不会让安全工程师被替代，但会深刻重塑其工作方式和能力模型。
从“手工劳动者”到“AI编排者”。安全工程师的核心价值将逐渐从“亲自动手编写PoC”转向“设计AI可理解的标准化工作流”和“对AI输出进行决策性把关”。工程师需要掌握的技能从具体的编程技巧扩展到：如何设计高质量的Prompt以引导LLM产出符合预期的输出、如何构建有效的验证与反馈机制以迭代优化生成结果、如何将多个智能体编排为协同工作的统一安全分析流水线。
专家经验的AI化沉淀。安全审计领域长期存在一个困境：资深安全专家的判断力和“嗅觉”——那种能闻到危险代码味道的能力——高度依赖个人经验，难以通过传统自动化工具复刻。通过Skills技能单元化思路，专家的分析思维链路和漏洞研判方法可以被沉淀为智能体可编排、可调度、可复用的能力组件。安全工程师将扮演“经验编码者”的角色，将个人的专家知识转化为AI可执行的规则链。
提示工程成为核心技能。在AI辅助的安全工作中，提示工程（prompt engineering）的重要性将不亚于传统的代码审计能力。工程师需要掌握如何将复杂的漏洞分析任务拆解为模型易于理解的子任务序列、如何设计链式推理提示以引导模型完成多步推演、如何构造引导模型回避幻觉和保持输出聚焦的约束条件。
8.3 行业标准化与测评体系构建
LLM辅助PoC生成技术正在快速发展，但行业层面的标准化和测评体系仍处于早期阶段，亟需各方共同推进。
基准评测集的开放需求。当前学术界的研究已经构建了包含100个真实CVE的高质量基准，以及覆盖CoT链式推理、上下文注入与实时反馈的多样化Prompt集合。但这些资源尚未形成广泛采用的行业标准。安全社区需要建立更大规模、覆盖更多漏洞类型、定期更新的公共基准评测集，以便对不同模型和方案的PoC生成能力进行客观比较。
安全可控的技术标准。中国正在推进人工智能代码生成服务的安全技术要求国家标准，涵盖IDE服务形态下的文件系统访问管控、命令执行拦截、智能体自主行为的人工介入与鉴权要求等内容。这些技术标准为Gemini等AI工具在安全敏感环境中的部署提供了合规性框架。对于PoC生成这一特殊场景，还需要针对性地制定模型输出安全要求（代码中禁止包含恶意载荷、硬编码凭证等）、生成代码的审计与追溯规范等专项标准。
跨厂商的互操作性。不同的AI模型和框架（Gemini、GPT系列、Claude系列、DeepSeek等）在PoC生成任务上的表现存在差异。DeepSeek-R1在成功率上持续优于GPT-4o，而Gemini在代码优化和结构化输出方面表现更佳。行业需要建立跨厂商的互操作性协议，使安全团队能够灵活地在不同模型之间切换和组合，而非被锁定在单一技术栈上。
第九章 结语
从“AI能否帮忙写PoC”的疑问，到“如何在实战中用AI写好PoC”的探索，这一进程正在以超出预期的速度演进。
Gemini赋能安全工程师自动编写PoC脚本，其核心价值不在于完全替代人工，而在于将安全工程师从重复性强、技术含量相对较低的编码劳动中解放出来，使其能够将精力和创造力投入到更复杂、更需要人类直觉与经验的深度漏洞挖掘和安全架构设计中去。正如Gemini CLI的设计理念所强调的——AI不是替代人的批判性思维和直觉，而是作为增强人类能力的“力量倍增器”。
与此同时，我们必须清醒认识到这项技术的局限性和风险。模型幻觉可能将工程师引入错误的分析方向，提示注入攻击可能反噬AI工具本身，而双重用途困境意味着同样的技术既可用于加速防御也可能被用于扩张攻击。安全工程师在使用Gemini生成PoC时，应当始终保持“Trust but Verify”的态度——将AI视为强大但不可完全信赖的助手，对其输出进行严格审查和多维度验证。
对于希望在AI时代保持竞争力的安全工程师而言，掌握Gemini等LLM的PoC生成能力已不再是“可选项”，而是与传统的代码审计、逆向工程、漏洞挖掘能力并驾齐驱的必备技能。正如Kali Linux将Gemini CLI纳入官方发行版所表明的信号——AI辅助安全分析正在从实验室走向工业实践，从辅助工具进化为核心能力。
未来的PoC编写，将是安全工程师的设计思维与AI的推理能力深度协作的过程。工程师定义“要验证什么”，AI辅助实现“如何验证”；工程师把关“验证结果是否可靠”，AI负责“快速生成和迭代”。人机协同的新范式，正在重新定义安全工程师的工作方式和价值边界。拥抱这一变化，不仅意味着技术能力的更新，更意味着一种思维方式的转变——从“亲力亲为的执行者”转变为“AI协同的设计者与把关者”。