AI Security

外观

红队工程与防御验证 · C2 Payload、语料与测试 Harness更新 2026-09-01约 5 分钟证据：中等 来源：arXiv:2608.15092v1

LLM 代码编辑中的安全漂移评测 ​

摘要 ​

WeSCE 研究 LLM 在没有显式安全要求的功能编辑中，程序安全属性如何变化。该基准含 400 个约 200 行、可执行的真实代码衍生程序，覆盖新增功能、删除功能、修复缺陷和重构。它不把程序简单标成“安全/有漏洞”，而是聚合静态分析、动态模糊测试和复杂度信号，比较编辑前后的总体风险、最严重风险和漏洞分布。

八个模型都更常降低而非提高风险，但完整清除仍有限。Opus 4.6 的最坏风险降低率为 329/400（82.25%），完整清除为 205/400（51.25%）；GLM-4-32B 分别为 235/400（58.75%）和 126/400（31.50%）。这些结果说明，功能任务完成不能替代安全回归，也不能把平均风险下降解释为程序已经安全。

核心创新与差异 ​

原研究贡献。 WeSCE 将弱安全约束定义为“任务只说明功能目标，不提醒模型修复或保留安全属性”，并用连续风险表示描述编辑前后变化。指标同时覆盖平均风险漂移、最坏风险漂移、漏洞分布总变差距离、风险降低率和完整清除率。

本站分析。 既有安全代码评测基准多测试从零生成、漏洞检测或显式修复。WeSCE 的独立对象是代码转换：功能编辑可能删除一种漏洞、保留最严重漏洞，或引入另一种风险。首个失效控制是开发流程把功能测试通过当成变更可接受条件，却没有对编辑前后安全属性做独立回归。

威胁模型与失效控制 ​

该研究不需要恶意提示词。开发者把正常的新增、删除、修复或重构任务交给 LLM，任务没有列出安全要求。模型提交功能可执行的变更，但安全属性可能改善、保持不变或退化。

  1. Harness 保存编辑前程序和安全信号。
  2. 模型只接收功能性编辑请求。
  3. 编辑结果先通过执行和任务检查。
  4. Harness 对前后版本运行相同的静态、动态和结构分析。
  5. 评测计算风险方向、最坏严重度和漏洞分布变化。

最先失效的是变更门禁缺少安全回归，而不是模型越过运行时权限。

实验设计与实际过程 ​

WeSCE 从 GitHub 与 Real-Vuln-Benchmark 衍生 400 个程序，四类任务各 100 个。程序经过可执行性检查，并用 CodeBERT 相似度和人工复核去重。作者测试 Opus 4.6、GPT-5.4、Sonnet 4、DeepSeek-V4-Flash、Kimi K2.5、Haiku 4.5、Doubao-1.5-pro 与 GLM-4-32B。

静态分析使用 CodeQL 与 Bandit；动态分析使用 Atheris，每个程序固定 90 秒模糊测试预算。40 个随机程序的人工复核估计检测精确率为 94.6%、召回率为 97.2%。主指标以 LogSumExp 聚合不同严重度信号，并用平均敏感和最坏情况敏感两种参数计算方向性漂移。

作者还用 40 个种子交叉组合 Claude Code、Cursor/DeepSeek-V4 的生成流水线，以及 Claude、DeepSeek 的评估设置，检查生成器与评估器同源是否影响结果。

关键结果与实际影响 ​

  • Opus 4.6 的最坏风险降低率、平均风险降低率和完整清除率分别为 329/400（82.25%）、330/400（82.50%）和 205/400（51.25%）。
  • GPT-5.4 的对应结果为 320/400（80.00%）、319/400（79.75%）和 202/400（50.50%）。
  • GLM-4-32B 的对应结果为 235/400（58.75%）、234/400（58.50%）和 126/400（31.50%）。
  • Opus 4.6 的新增功能任务完整清除为 34/100，重构为 80/100；GLM-4-32B 的最坏风险降低率从新增功能的 46/100 上升到重构的 82/100。
  • 即使表现最佳的 Opus 4.6，也有 195/400 个程序保留非忽略风险，说明风险下降与漏洞清除不是同一指标。
  • 强模型的漏洞分布变化更大：Opus 4.6 的平均总变差距离为 0.629，GLM-4-32B 为 0.455；该指标只表示变化幅度，必须与风险方向一起解释。

论文展示一个重构案例：代码结构变得更现代，但对外部表达式的危险 eval 仍保留。该案例说明，结构变化和功能成功都不能证明安全根因已经消除。

相邻研究补充了基线、训练轨迹和多轮审查三个可证伪变量。Compared to What?在工具链和规模匹配的人类代码基线下，报告 LLM 生成 IaC 的漏洞密度高出 3.21–3.87 倍，说明只比较模型之间的绝对告警数会误读差距；结果仍受所选 IaC 样本、扫描器和人类基线限制。SWE-Prime发现成功编码轨迹也包含冗余或风险步骤，并用多粒度筛选避免训练时照搬这些行为；该工作没有公开可核验工件，不能证明筛选能消除真实漏洞。MCR-Bench在多轮代码审查中观察到低显著缺陷漏检、跨轮状态错位和长程记忆失败，说明单轮静态审查不能代表持续评审能力。三项结果都来自单篇论文且无独立复现，应与功能测试、静态/动态分析和留出仓库共同使用。

防护措施与验证方法 ​

  • 在功能测试之外，固定编辑前后的静态分析、动态模糊测试和安全单元测试。
  • 分别报告总体风险、最坏严重度、漏洞分布和完整清除率；不能只给一个平均分。
  • 对新增功能和删除功能设置更严格的安全回归，因为它们在论文中低于修复和重构任务。
  • 评估器应与生成器解耦，并抽样人工复核工具误报和漏报。
  • 安全门禁应核对具体 CWE 和可达路径；复杂度下降或代码重排不等于漏洞消失。
  • 对较大仓库保存跨模块调用图、依赖变化和环境配置，补足小规模程序基准未覆盖的风险。

局限与待验证问题 ​

  • 程序约 200 行，明显小于真实多模块仓库；跨文件状态、构建系统和依赖风险没有覆盖。
  • Atheris 主要发现输入驱动崩溃和部分运行时问题，难以发现业务逻辑、部署环境和并发漏洞。
  • 连续风险依赖工具信号、严重度权重和聚合参数，不是程序安全性的形式证明。
  • 弱安全提示符合常见功能任务，但无法分离预训练安全知识、模型能力和编辑策略的因果贡献。
  • 论文没有证明所有编辑结果都满足原功能语义，也没有给出生产代码审查中的开发者采纳率。
  • 本站未运行 400 个程序或 90 秒模糊测试，结果均来自作者实验。

参考链接 ​