Examining Zero-Shot Vulnerability Repair with Large Language Models：用 TaoToken 统一 Key 跑通 Codex 零样本漏洞

1. 从论文复现说起零样本漏洞修复到底难在哪如果你正在做代码安全方向的研究或者想复现《Examining Zero-Shot Vulnerability Repair with Large Language Models》这篇论文的实验流程大概率会遇到一个很现实的问题论文里被测的 Codex、Jurassic-1 这些模型都是通过托管 API 访问的黑盒服务而你在本地写评测脚本时往往要同时对接好几个不同的接口地址、不同的鉴权方式、不同的请求格式。光是让脚本能稳定跑起来就要花掉不少时间。这篇论文的核心其实不复杂它想验证现成的代码大语言模型在零样本条件下——也就是不做任何微调、只靠提示词引导——能不能生成安全且功能正确的补丁。作者设计了合成场景、手工构造场景和真实历史漏洞三类测试用 CodeQL 和回归测试来判定修复是否成功。结论是简单场景下模型能修真实场景下还差得远。复现这套流程时真正卡人的不是算法而是工程链路。你需要一个统一的 API 通道让实验脚本用同一套 Key 和同一套请求格式去调用被测模型否则每换一个模型就要改一遍代码。这篇就围绕这个场景讲清楚怎么用 TaoToken 把 Codex 这类模型的调用统一起来交付可复制的config.toml和settings.json骨架、漏洞样本的提示模板以及一次零样本修复请求的完整验证动作。适合谁看正在做 LLM 安全评测的研究生、想复现漏洞修复实验的工程师、以及需要批量调用代码模型做提示工程对比的开发者。下面所有配置和命令都可以直接跟做。2. TaoToken 前置统一 Key 与 API 通道的准备在开始写实验脚本之前先把调用通道理顺。TaoToken 在这里扮演的角色是一个统一的模型接入层你用同一个 API Key就能通过兼容 OpenAI 风格的接口去请求不同的代码模型实验脚本里不需要为每个模型单独维护一套鉴权逻辑。你需要准备的东西只有两样第一一个可用的 API Key。登录官网后进入控制台在 API Keys 页面创建一个新的 Key复制保存好。这个 Key 就是后面config.toml和settings.json里要填的凭证。第二确认你要调用的模型名称。论文里 Codex 用的是code-cushman-001和code-davinci-001这类引擎标识你在实验脚本里需要把它们映射成当前可用的模型名。具体可用列表可以在模型对话页面或接入文档里查到建议先确认再写进配置。注意API Key 不要硬编码在会提交到 Git 的脚本里。建议用环境变量注入或者放在.gitignore覆盖的本地配置文件中。下面给的配置骨架会演示环境变量引用的写法。接入地址统一用https://taotoken.net/api请求路径遵循 OpenAI 兼容规范比如对话补全走/v1/chat/completions。这样你原来基于 OpenAI SDK 写的评测代码只需要改base_url和api_key两个地方就能跑通。3. 可复制配置config.toml 与 settings.json 骨架实验脚本的配置分两层config.toml放模型和请求参数settings.json放评测任务的元信息。这样拆分的好处是换模型只改 toml换数据集只改 json互不干扰。先看config.toml# config.toml —— 模型接入与采样参数 [api] base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY # 从环境变量读取避免明文 timeout_seconds 60 max_retries 3 [model] # 论文中被测的 Codex 引擎映射为当前可用模型名 name code-davinci-001 temperature 0.0 # 零样本修复优先确定性输出 top_p 1.0 max_tokens 512 stop [, \n\n\n] [prompt] # 提示模板文件路径 template_path ./prompts/vuln_repair.tmpl include_cwe true # 是否在提示中注入 CWE 编号 include_context_lines 20 # 漏洞点前后保留的上下文行数再看settings.json它描述一次评测任务的输入输出{ task_id: zeroshot-cwe787-run01, dataset: ./data/synthetic_cwe787.jsonl, cwe: CWE-787, language: c, output_dir: ./results/zeroshot-cwe787-run01, record_fields: [ task_id, sample_id, prompt_hash, model_name, temperature, raw_response, extracted_patch, compile_ok, codeql_ok, regression_ok ], evaluator: { compile_cmd: gcc -c {file} -o /dev/null, codeql_query: cpp/out-of-bounds-write, regression_suite: ./tests/cwe787 } }这两个文件配合使用的方式是脚本先读settings.json拿到任务上下文再读config.toml拿到模型参数然后逐条从dataset里取漏洞样本套用提示模板发起请求。环境变量这样设置export TAOTOKEN_API_KEY你的Key如果你用 Python 的tomllib3.11读取配置可以这样加载import tomllib, json, os with open(config.toml, rb) as f: cfg tomllib.load(f) with open(settings.json, r, encodingutf-8) as f: task json.load(f) api_key os.environ[cfg[api][api_key_env]] base_url cfg[api][base_url] model_name cfg[model][name]到这里配置骨架就搭好了。接下来是提示模板和实际请求。4. 漏洞样本提示模板与一次零样本修复请求论文里反复强调的一点是提示的构造方式直接决定模型输出质量。作者尝试了不同详细程度的注释、不同上下文线索发现提示对结果非常敏感。所以复现时提示模板要单独管理不能随手拼字符串。下面是一个针对 CWE-787越界写入的提示模板文件放在./prompts/vuln_repair.tmplYou are a security-focused code assistant. The following C function contains a potential {cwe} vulnerability. Fix the vulnerability with minimal changes. Return only the corrected function body. c {code_snippet}// Fix:这个模板的设计逻辑是先声明角色和安全目标再给出 CWE 编号让模型知道漏洞类型然后贴出漏洞代码片段最后用 // Fix: 作为补全触发点。stop 参数里加了 防止模型输出多余的 Markdown 围栏。 发起一次请求的 Python 脚本 python import os, json, tomllib, requests with open(config.toml, rb) as f: cfg tomllib.load(f) with open(settings.json, r, encodingutf-8) as f: task json.load(f) api_key os.environ[cfg[api][api_key_env]] base_url cfg[api][base_url] # 读取一条漏洞样本 with open(task[dataset], r, encodingutf-8) as f: sample json.loads(f.readline()) # 套用提示模板 with open(cfg[prompt][template_path], r, encodingutf-8) as f: tmpl f.read() prompt tmpl.format( cwetask[cwe], code_snippetsample[vulnerable_code] ) payload { model: cfg[model][name], messages: [{role: user, content: prompt}], temperature: cfg[model][temperature], top_p: cfg[model][top_p], max_tokens: cfg[model][max_tokens], stop: cfg[model][stop], } resp requests.post( f{base_url}/v1/chat/completions, headers{ Authorization: fBearer {api_key}, Content-Type: application/json, }, jsonpayload, timeoutcfg[api][timeout_seconds], ) resp.raise_for_status() result resp.json() patch result[choices][0][message][content] # 记录结果 record { task_id: task[task_id], sample_id: sample[id], model_name: cfg[model][name], temperature: cfg[model][temperature], raw_response: patch, } os.makedirs(task[output_dir], exist_okTrue) with open(f{task[output_dir]}/run.jsonl, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n) print(修复建议已生成长度:, len(patch))这段脚本跑通后你会得到一条 JSONL 记录里面包含模型返回的原始补丁文本。接下来就是验证环节。5. 验证请求与结果记录编译、CodeQL、回归测试论文的评测框架有三道关卡编译通过、安全工具通过、回归测试通过。复现时建议按同样顺序做任何一关失败都记录下来不要跳过。第一关编译检查。把模型返回的补丁写回源文件用gcc -c试编译gcc -c patched_sample.c -o /dev/null 2compile.log echo exit code: $?如果编译失败compile_ok记为false直接进入下一条样本不用再跑后续检查。第二关CodeQL 扫描。论文用的是 CodeQL 2.7.2查询库选cpp/out-of-bounds-writecodeql database create ./db --languagecpp --source-root./patched codeql database analyze ./db cpp/out-of-bounds-write \ --formatsarif-latest --outputcodeql_result.sarif如果 SARIF 结果里还有告警说明漏洞没修干净codeql_ok记为false。第三关回归测试。跑原有的测试套件确认修复没有破坏功能cd ./tests/cwe787 make test 21 | tee ../../regression.log三关都通过regression_ok记为true这条样本才算修复成功。把验证结果回填到记录里record.update({ compile_ok: compile_ok, codeql_ok: codeql_ok, regression_ok: regression_ok, })实测下来合成场景里 Codex 的修复成功率确实很高但真实历史漏洞样本上经常出现编译通过、CodeQL 也过了、回归测试却挂掉的情况。这跟论文的结论一致功能正确性才是真正的瓶颈。提示记录prompt_hash字段很有用。同一漏洞用不同提示模板跑出来的结果差异可能很大哈希能帮你回溯是哪版提示产生的补丁。6. 本篇常见错排查报错一401 Unauthorized。最常见的原因是环境变量没生效。检查echo $TAOTOKEN_API_KEY是否有输出以及config.toml里的api_key_env名字是否和实际环境变量名一致。另一个可能是 Key 复制时带了空格。报错二404 model not found。模型名写错了。论文里的code-cushman-001是历史引擎标识当前可用模型名需要以接入文档为准。把config.toml里的name换成文档里列出的名称再试。报错三请求超时。代码补全类请求的响应时间通常比普通对话长尤其是max_tokens设得大的时候。把timeout_seconds调到 90 或 120同时确认max_retries至少为 2。报错四返回内容为空或只有换行。多半是stop参数设得太激进模型刚输出一个换行就被截断了。检查stop列表去掉过于宽泛的终止符比如单独的\n。报错五CodeQL 建库失败。确认--source-root指向的是补丁写回后的目录而不是原始漏洞代码目录。另外 CodeQL 对 C 文件的编译命令有要求如果项目有自定义 Makefile需要用--command指定编译方式。报错六回归测试全挂。先确认测试套件本身在原始代码上能跑通。如果原始代码就挂那不是模型的问题。另外注意补丁写回时有没有破坏文件编码或行尾符。排障时如果拿不准是接入层还是模型层的问题可以先用模型对话页面手动发一条同样的提示对比返回结果。如果手动能通、脚本不通问题就在脚本的请求构造上。7. 把实验链路固定下来复现这类论文最耗时的部分从来不是读懂方法而是让评测脚本稳定地跑完几百条样本。把 API 通道统一之后你只需要维护一份config.toml换模型、换采样参数、换提示模板都在配置层完成脚本本身不用动。如果你接下来要跑更大规模的对比实验比如同时测多个模型在 CWE-787 和 CWE-89 上的表现建议把settings.json里的task_id和output_dir做成按模型名和参数自动生成避免结果文件互相覆盖。长期做编码类评测的话Coding Plan 的额度模型比按次调用更适合批量任务可以在控制台里看一下哪种计费方式匹配你的实验量。接入文档里有完整的请求参数说明和错误码对照表遇到本文没覆盖的报错可以直接查。模型对话页面适合做单条提示的快速验证正式跑批再用脚本。