基于GLM-5.3后训练的漏洞挖掘实践：从LoRA微调到部署全流程

智谱开源 GLM-5.3 之后，很多安全团队开始认真评估一个问题：能不能用后训练让开源代码模型参与漏洞挖掘。公开材料提到的 2436 个真实漏洞，让这个方向从“大模型能不能看懂代码”变成了“后训练能输出多少可验证、可修复的漏洞结论”。这个数字容易被误读成模型会自动扫描系统并直接给出可利用漏洞，实际场景并不是这样。更准确的理解是，模型通过后训练把代码分析能力对齐到“漏洞类型、触发位置、原因解释、修复建议”这套输出格式上，再由安全工程师结合静态工具和人工复核去确认。这篇文章会围绕 GLM-5.3 开源模型，梳理后训练漏洞挖掘的最小可复现流程，包括数据准备、LoRA 微调、推理验证、评估指标、部署方式和合规边界。方向限定在授权代码审计、SRC 合规测试和防御性安全研究，不涉及任何未授权扫描和攻击利用。

1. 先理解开源 GLM-5.3 和后训练之间的链路

1.1 开源模型给安全场景带来了什么变化

漏洞挖掘本质上是一个需要“上下文理解 + 模式识别 + 结果解释”的任务。传统静态分析工具擅长规则匹配，但面对业务逻辑漏洞、跨文件数据流、不规范的代码写法时，误报和漏报都很高。大模型的优势在于能结合代码语义、函数名、注释和调用关系做判断，劣势在于输出不可控，可能给出模棱两可的结论。

GLM-5.3 开源之后，安全团队可以直接把模型下载到内网私有部署。这个动作看起来简单，实际影响很大。敏感代码不需要上传到外部服务，评估结果可以复现，训练过程中的输入输出可以审计，模型版本可以锁定。这对安全场景尤其重要，因为很多待审计代码本身属于企业核心资产，不能因为一次分析就发送到公有 API。

从能力上看，开源代码模型已经具备较好的代码补全、代码解释和跨语言理解能力。但基座模型的目标是“预测下一段文本”，不是“按安全报告格式输出”。直接拿基座模型去分析漏洞，结果往往是一段自然语言描述，零散且无法批量处理。后训练要解决的就是这个问题：把模型从“会读代码”变成“会做结构化漏洞诊断”。

1.2 后训练不是让模型背漏洞字典，而是对齐输出格式和判断逻辑

后训练的概念需要先相对预训练做一个区分。预训练阶段，模型学习的是海量代码和文本中的统计规律，包括语法、命名习惯、常见 API 用法。后训练阶段，模型通过少量高质量样本，把已经学到的能力引导到特定任务上，比如“给定代码片段，输出 JSON 格式的漏洞诊断结果”。

所以后训练不是让模型记住“某个 CVE 对应某段代码”，而是让模型学会一套判断流程：先确认输入数据是否可控，再看数据是否进入危险函数，最后评估影响并给出修复建议。这个过程和人工审计很像，只不过模型把判断规则压缩进了参数里。

回到 2436 这个数字。公开材料里提到的真实漏洞，通常是在一个限定评测范围内得到的，比如某个代码仓库集合、某种漏洞类型集合、某段时间的提交记录。它能说明后训练模型在特定数据分布下有效，但不能无条件外推到所有项目。实际落地时要把这个数字理解为“评测口径下的阳性结果”，而不是“模型在任何代码库上都能挖出 2436 个漏洞”。

1.3 这项工作的工程边界与合规前提

漏洞挖掘领域很容易踩到合规问题。后训练模型本身没有主观意图，但使用模型的人必须对行为边界负责。只有具备明确授权的代码库、测试靶场、SRC 项目或众测平台范围内的目标，才能使用模型辅助挖掘。

下表整理了几类常见场景的合规判断。

需要特别强调，后训练模型的价值是“辅助发现和解释”，不是“自动攻击”。所有候选漏洞都应经过人工复核，修复后的代码还要通过回归测试验证。下面各节给出的流程，默认都建立在这个合规前提之上。

2. 环境准备和数据构建，决定后训练质量的上限

2.1 依赖与运行环境

训练一个代码漏洞分析模型，不需要特别高的工程门槛，但显存和依赖版本要先对齐。下面以 LoRA 微调为例，给出常见依赖组合。

pip install torch==2.3.0 transformers==4.44.2 peft==0.12.0 accelerate==0.33.0 datasets==2.19.0 trl==0.9.4 vllm==0.6.1

这里需要说明，版本号只是示例。落地前要结合 GLM-5.3 实际发布时的官方要求调整，尤其要注意transformers和peft的版本兼容，否则加载模型时可能出现未知参数报错。

硬件方面，LoRA 方式比较适合小团队起步。不同显存规模对应的选择如下。

学习环境和生产环境可以分开。学习环境目标是把流程跑通，24GB 显存足够。生产环境则需要考虑推理吞吐、并发、日志审计和故障恢复，不能只关注训练是否成功。

2.2 训练样本的结构化设计

训练样本质量直接决定后训练效果。推荐把每条样本设计成三段结构：指令、输入代码、输出诊断结果。输出结果统一使用 JSON，方便训练后的自动解析和批量评估。

下面是一条例子的 JSON 格式。

{ "instruction": "分析下面的 Python 代码片段，判断是否存在漏洞。如果存在，请输出漏洞类型、位置、原因和修复建议。", "input": "def query_user(name):\n sql = \"SELECT * FROM users WHERE name = '\" + name + \"'\"\n cursor.execute(sql)\n", "output": "{\n \"vulnerability_type\": \"SQL Injection\",\n \"line_range\": [2, 3],\n \"reason\": \"用户输入 name 直接拼接进 SQL 语句，攻击者可以通过闭合单引号改变查询语义。\",\n \"fix\": \"使用参数化查询，例如 cursor.execute('SELECT * FROM users WHERE name = %s', (name,))。\"\n}" }

输出格式有两个关键点。第一，字段固定，不能随意更换字段名，否则后续解析脚本要频繁适配。第二，reason 和 fix 必须具体，reason 要说明数据如何流入危险函数，fix 要给出可执行的修改方向。空洞的“注意输入校验”对训练没有帮助，反而会让模型学会输出套话。

2.3 用脚本把代码片段加工成训练集

数据来源建议从这几类材料中构建：公开 CVE 描述中的漏洞摘要、开源漏洞测试靶场的代码、企业内部已脱敏的历史漏洞样本、安全团队人工构造的“危险写法 + 修复写法”对照样本。

需要注意，从外部收集样本时，要遵守数据许可证和使用条款，不能把受版权限制的完整源码直接灌入训练集。更稳妥的做法是保留最小函数片段，并去掉非必要注释和业务信息。

下面是一个简单的数据加工脚本，用于把原始样本转换成 JSONL 文件。

import json def build_sample(code, vuln_type, line_range, reason, fix, language="Python"): instruction = f"分析下面的 {language} 代码片段，判断是否存在漏洞。如果存在，请输出漏洞类型、位置、原因和修复建议。" output = { "vulnerability_type": vuln_type, "line_range": line_range, "reason": reason, "fix": fix, } return { "instruction": instruction, "input": code, "output": json.dumps(output, ensure_ascii=False), } samples = [] # 每次添加样本时，确保 code 和 reason、fix 是一一对应的。 samples.append(build_sample( code="def query_user(name):\n sql = \"SELECT * FROM users WHERE name = '\" + name + \"'\"\n cursor.execute(sql)\n", vuln_type="SQL Injection", line_range=[2, 3], reason="用户输入直接拼接进 SQL 语句，改变了查询语义。", fix="改为参数化查询，避免拼接字符串。" )) with open("train.jsonl", "w", encoding="utf-8") as f: for sample in samples: f.write(json.dumps(sample, ensure_ascii=False) + "\n")

脚本本身不复杂，但这里有一个常见误区：把大量漏洞样本堆进去，却没有清理重复代码。如果同一个函数在训练集和测试集中同时出现，评估结果就会虚高。数据去重要按“代码片段哈希 + 函数名归一化”一起做，不能只按文本完全匹配去重。

2.4 评测集按仓库隔离，避免数据泄漏

训练集、验证集、测试集不能随机打散后简单划分，因为同一仓库的不同文件之间可能存在重复代码。推荐按仓库级别隔离，保证测试集中的代码来自模型从未见过的项目。

在真实项目里，测试集最好取自两个来源：一个是开源漏洞靶场，另一个是当前团队近期修复过的一批历史漏洞。后者更能反映生产环境中的代码风格，但也更容易涉及敏感信息，使用前必须脱敏。

3. 基于 GLM-5.3 做后训练：先用 LoRA 跑通，再考虑全参微调

3.1 最小 LoRA 训练示例

LoRA 的核心思想是冻结原始模型参数，只训练少量低秩矩阵。对安全团队来说，最大的好处是显存占用低、训练速度快、方便在多个任务间切换。下面给出一个最小训练脚本示例。

import json from datasets import load_dataset from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model from trl import SFTTrainer model_path = "your_glm_5.3_dir" dataset = load_dataset("json", data_files="train.jsonl", split="train") eval_dataset = load_dataset("json", data_files="eval.jsonl", split="train") tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) if tokenizer.pad_token is None: tokenizer.pad_token = tokenizer.eos_token model = AutoModelForCausalLM.from_pretrained( model_path, torch_dtype="auto", device_map="auto", trust_remote_code=True, ) model.enable_input_require_grads() lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_config) training_args = TrainingArguments( output_dir="./glm53_vuln_lora", per_device_train_batch_size=1, gradient_accumulation_steps=8, learning_rate=2e-4, num_train_epochs=3, logging_steps=10, save_strategy="epoch", eval_strategy="epoch", fp16=True, ) trainer = SFTTrainer( model=model, args=training_args, train_dataset=dataset, eval_dataset=eval_dataset, tokenizer=tokenizer, max_seq_length=4096, dataset_text_field="text", ) trainer.train()

这个脚本依赖一个前提：数据集中有一个text字段，并且已经拼接好指令、输入和输出。SFTTrainer会直接对这个文本字段做 tokenize。如果你的原始数据是instruction、input、output三段，需要先写一个映射函数把它们拼成text字段。

还需要注意，trust_remote_code=True只应该在确定模型来源可信时使用。开源模型目录可能包含自定义代码，加载前要检查目录内容，避免引入不明执行逻辑。

3.2 训练参数的含义与调参顺序

很多团队第一次训练时最喜欢反复调整学习率，但效果往往不如先检查数据质量。参数调整应该按“数据质量 -> 序列长度 -> LoRA 秩 -> 学习率”这个顺序来。

LoRA 的秩不需要从一开始就调到 64。先使用r=16跑通流程，再看验证集损失。如果验证集表现不足，再逐步增大秩和训练数据量。全参微调虽然可能获得更好的上限效果，但对数据量、显存和训练稳定性要求更高，小团队不适合一上来就尝试。

3.3 训练结束后的模型合并与导出

LoRA 训练完成后，checkpoint 里只保存了增量参数，不能直接用于常见部署工具。推荐先合并 LoRA 权重，再导出完整的模型目录。

model = model.merge_and_unload() model.save_pretrained("./glm53_vuln_merged") tokenizer.save_pretrained("./glm53_vuln_merged")

合并后的模型目录可以直接用transformers加载，也可以交给vLLM部署。合并前要检查 checkpoint 对应的训练参数和数据版本，建议在模型目录下额外写入一个train_meta.json，记录训练集规模、漏洞类型分布、LoRA 参数和训练轮数。

{ "base_model": "glm-5.3", "train_samples": 12000, "eval_samples": 1500, "epochs": 3, "lora_rank": 16, "learning_rate": 0.0002, "data_version": "2025-06-authorized-only" }

这一步容易被忽略，但实际项目中非常有用。模型效果一旦回退，或者线上出现误报问题，train_meta.json能快速定位是数据问题还是训练参数问题。

4. 推理验证：让模型输出可解析的漏洞结论

4.1 Prompt 模板和推理脚本

后训练完成后，模型已经见过结构化指令，但推理时仍然需要保持与训练一致的 Prompt 风格。下面是一个最小推理脚本。

from transformers import AutoModelForCausalLM, AutoTokenizer model_path = "./glm53_vuln_merged" tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_path, torch_dtype="auto", device_map="auto", trust_remote_code=True, ) prompt = """你是漏洞分析助手。请阅读下面的代码片段，判断是否存在漏洞。 如果存在，请按 JSON 格式输出，字段包括 vulnerability_type, line_range, reason, fix。 代码片段： ```python def get_user(request): uid = request.GET.get("uid") sql = "SELECT * FROM users WHERE id = " + uid cursor.execute(sql)

"""

inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate( **inputs, max_new_tokens=512, temperature=0.2, do_sample=False, ) response = tokenizer.decode( outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True, ) print(response)

推理阶段要把 `temperature` 设低，或者直接用贪心解码。漏洞分析需要稳定输出，不需要创造性。如果模型在同一个代码片段上多次推理给出不同结论，说明 Prompt 或模型状态不稳定，应先检查解码参数。 ### 4.2 输出解析与后处理 模型可能输出多余的说明文字，也可能在 JSON 前后加上引号或 markdown 代码块。解决方法是先提取 JSON 子串，再解析。 ```python import json import re def extract_json(text): match = re.search(r"\{[\s\S]*\}", text) if not match: raise ValueError("no json found in model output") return json.loads(match.group()) text = '模型输出：\n```json\n{"vulnerability_type": "SQL Injection", "line_range": [3, 4], "reason": "uid 拼接进了 SQL 语句。", "fix": "使用参数化查询。"}\n```' result = extract_json(text) print(result["vulnerability_type"])

这里有一个容易踩的坑：正则\{[\s\S]*\}是贪婪匹配，如果输出里包含多个 JSON 对象，会取到最外层那一串。更稳妥的做法是在训练数据里统一要求模型“只输出 JSON，不要添加说明文字”，同时推理时用max_new_tokens限制长度，避免模型越写越长。

4.3 评估指标：不能只看模型说发现了什么

模型输出的漏洞结论必须先经过结构化评估，再谈是否有效。常见指标如下。

位置命中率是最容易被高估的指标。模型说“第 3 行存在漏洞”，但人工确认后发现真正的问题是第 3 行调用的函数在第 8 行的实现有缺陷。这种结果不能算定位成功，只能算“相关行命中”。所以位置命中率要按“根因行命中”和“相关行命中”分开统计。

4.4 与静态分析工具交叉验证

后训练模型不应该替代 Semgrep、CodeQL 这类静态分析工具，而是应该和它们配合。推荐链路是：先由规则工具生成候选列表，再由模型对候选做代码语义判断，最后人工复核。

这样做的好处是双向的。规则工具能覆盖模型容易忽略的重复模式，模型能过滤掉规则工具的大量误报。同时，模型还能给规则告警补充原因和修复建议，让安全工程师不需要打开源码逐行阅读。

交叉验证时，要记录模型输出与工具结果一致、不一致的样本分别有多少。如果模型和工具都判定为漏洞，这个结论通常比较可靠。如果只有模型判定为漏洞，必须人工重点复核。

5. 常见问题与排查路径

5.1 训练 loss 不降或显存溢出

训练 loss 不降，首先检查数据而不是参数。常见情况是text字段拼接错误，或者指令和输出之间缺少合理的分隔符。可以先取一条样本，用 tokenizer 解码回文本，确认拼接后的内容是否通顺。

显存溢出更常见。可以先降低per_device_train_batch_size，把梯度累积步数调大，再尝试序列长度缩短到 2048。如果依然溢出，再考虑 4bit 量化加载。

5.2 模型只会输出模板，不分析代码

如果模型在推理时只输出“存在漏洞，请修复”之类的空话，通常是训练数据里真实分析样本太少，或者输出字段过于固定导致模型学会了套模板。解决办法是提高数据中 reason 的多样性，不要每一条都写成“用户输入未过滤”。更好的样本应该描述具体的数据流，比如“uid从request.GET取出后未经过类型校验，直接拼接到SQL语句中”。

另外要减少重复样本。如果训练集里同一个修复写法出现几百次，模型就会把这种写法变成模板记忆，而不是学会判断逻辑。

5.3 模型产生幻觉漏洞

幻觉是代码大模型在安全场景最危险的问题之一。模型可能看到“eval”就直接报代码执行漏洞，但实际上输入来自可信常量；也可能看到“os.system”就报命令注入，却没有确认参数是否可控。

缓解幻觉可以从两个层面入手。数据层面，训练集必须包含大量“看起来危险但实际安全”的负样本，让模型学会区分受控和非受控场景。推理层面，要求模型输出中带上“数据来源”和“危险函数调用路径”，没有调用路径的结果直接降级为低置信度。

注意：模型输出只能作为候选结论，不能直接触发工单或修复动作。没有经过人工复核的模型结果，不应该被当作已确认漏洞。

5.4 输出 JSON 解析失败或内容被截断

推理时如果max_new_tokens太小，模型输出会在 JSON 中途截断。可以先把这个值调整到 512 以上。如果代码片段较长，建议先做切片处理，确保每段代码在 100 到 200 行之间，而不是把整个文件一次性输入。

解析失败时，日志要保留原始输出。不要只记录“解析失败”而不记录模型原文本，否则后续很难判断是格式问题还是模型输出乱码。

6. 把后训练模型接入实际漏洞挖掘工作流

6.1 从代码提交到漏洞候选的推荐链路

在真实项目中，模型不是被单独调用，而是嵌入到代码审计流水线里。推荐链路如下。

1. 从代码仓库拿到本次变更涉及的 Diff 或新增文件。
2. 对变更代码做静态规则扫描，生成初步告警。
3. 把告警对应的代码片段交给后训练模型，让模型输出结构化诊断。
4. 把工具告警和模型输出合并成候选列表，按“高危 + 高置信”排序。
5. 安全工程师对候选列表逐条复核。
6. 确认后的漏洞进入缺陷管理系统，并自动关联修复工程师。

这里要注意，模型单次输入的代码片段不宜过长。推荐把“危险函数所在函数”作为分析单元，而不是整文件分析。这样可以降低显存占用，也能让模型把更多注意力放在可疑调用路径上。

6.2 SRC 和众测平台上的合规做法

在 SRC 或众测平台使用模型辅助挖掘时，平台规则必须优先于模型输出。通常要注意以下几点。

• 只测试平台明确授权的域名、应用和测试账号。
• 不扫描授权范围之外的资产。
• 报告中的验证步骤只用于说明影响，不包含自动化利用流程。
• 不保存平台业务数据到本地训练集。
• 模型输出出现疑似高危漏洞时，先人工确认再提交。

平台方关心的是有效的漏洞报告，而不是“模型发现了几千个漏洞”。如果提交结果里混入大量误报，反而会影响团队信誉。所以模型用于 SRC 场景时，建议把阈值调高，只提交有明确调用链、可验证影响、有修复建议的候选。

6.3 生产环境部署要点

模型训练完成后，需要以服务形式暴露给安全团队使用。使用vLLM部署可以提升吞吐，同时保持与 OpenAI 兼容的 API 格式。

vllm serve ./glm53_vuln_merged \ --served-model-name glm53-vuln \ --port 8000 \ --max-model-len 8192

调用接口时，可以把 Prompt 模板封装在服务端，这样使用方只需要传入代码片段。

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "glm53-vuln", "messages": [ {"role": "user", "content": "请分析代码片段是否存在漏洞。\n```python\nprint(eval(user_input))\n```"} ], "max_tokens": 512, "temperature": 0.2 }'

生产部署还要考虑三个安全细节。第一，模型服务端口只在内网开放，不能直接暴露到公网。第二，所有请求和响应都要记录审计日志，便于溯源。第三，模型服务账号使用独立的最小权限，不能让它有权限直接读取源码库，否则一旦服务被入侵，源码会连带泄露。

6.4 如何对待“2436 个真实漏洞”这个数字

“2436 个真实漏洞”是一个有吸引力的结论，但也必须接受严格审视。复现这个数字需要明确很多前提：评测数据集包含哪些仓库，漏洞定义由谁确认，是否排除了重复告警，是否只统计可修复漏洞，是否包含误报回滚。这些口径不同，最终数字会差很多。

实际团队使用模型时，更合理的目标不是复现某个公开数字，而是建立自己的评测基线。可以先收集 50 到 100 个历史漏洞样本，评估模型在本团队代码风格上的表现，再决定是否接入正式审计流程。记录数据版本、模型版本、评测脚本和人工复核结果，才能让效果持续可比。

注意：不要只验证模型能发现漏洞，还要记录它漏掉了哪些漏洞、产生了多少误报。漏报决定安全风险，误报决定人力成本。

7. 最佳实践清单与下一步扩展

7.1 训练前检查清单

启动训练之前，建议逐项核对下面的清单。

• [ ] 数据来源是否全部获得授权，是否包含敏感信息
• [ ] 训练集、验证集、测试集是否按仓库隔离，是否存在哈希重复
• [ ] 每条样本的 output 是否为合法 JSON，字段是否一致
• [ ] 正样本和负样本比例是否合理，负样本占比是否不低于 20%
• [ ] 训练样本解码后是否通顺，指令和分隔符是否正确
• [ ] 显存、依赖版本、LoRA 参数是否已经确认
• [ ] 是否已经保存一份“训练数据快照”，用于后续复现

其中负样本最容易被忽略。如果训练集里全是漏洞代码，模型会倾向于把任何代码都判定为有漏洞，最终误报率高到无法接受。安全场景宁可漏报少一点，也不希望误报淹没整个工单系统。

7.2 上线前检查清单

模型上线前，不能只看训练 loss 和少量示例输出。建议至少完成以下检查。

• [ ] 在完全未见过的仓库上完成评估，而不是只在训练集上验证
• [ ] 统计误报率和漏报率，并和当前静态工具基线做对比
• [ ] 人工复核至少 50 条模型输出，确认 reason 和 fix 可读且正确
• [ ] 确认模型服务只在内网可用，端口未暴露
• [ ] 确认审计日志能记录每次分析的模型版本、输入摘要和输出结果
• [ ] 明确模型输出的使用规则：候选结论必须经过人工复核才能进入修复流程
• [ ] 准备回滚方案：保留上一个模型版本，新版本效果不佳时能快速切回

上线后还要设置定期评估。代码仓库会变化，模型输出质量也会因为代码风格变化而波动。建议每季度用固定评测集跑一次基线，发现效果下降时优先检查评测集和数据版本是否一致。

7.3 下一步：从单条分析到漏洞修复助手

当前流程的核心是“单段代码 -> 结构化诊断”。扩展方向大致有三个。

第一个方向是多轮对话。模型输出修复建议后，修复工程师可以继续追问“如果使用参数化查询后，现有 ORM 是否会受影响”。这要求模型具备多轮上下文理解能力，后训练数据也要从单条问答扩展成对话树。

第二个方向是检索增强生成。把企业内部的编码规范、历史漏洞报告、依赖库版本信息放到向量库里，模型在分析代码时可以检索相关上下文，减少因为缺少项目背景而产生的误判。

第三个方向是自动化验证。模型输出修复建议后，由工具自动生成补丁并在隔离环境执行测试，最后把测试结果反馈给模型，形成“分析 -> 修复 -> 验证 -> 再分析”的闭环。

这三个方向都会引入新的工程复杂度，但也更接近真实的安全审计工作流。对团队来说，不必一开始就追求全自动。先把“模型 + 静态工具 + 人工复核”这条最小链路稳定下来，把误报率和漏报率记录清楚，再逐步增加自动化和多轮能力，是更稳妥的路径。

开源 GLM-5.3 的意义不只是提供了一个更强的代码基座，而是让安全团队第一次可以基于可控的模型权重，去构建属于自己的漏洞分析能力。2436 这个数字可以作为起点，但真正有价值的是围绕它建立的评测流程、数据规范、训练脚本和部署体系。把这些基础设施沉淀下来，后续无论是换模型、换数据还是换安全场景，都能快速复用。