在代码中查找漏洞：Cyber-JEV 预印本将 Jev 与自建模型对比

七位作者于 2026年11月初在 arXiv 上发布了预印本 Cyber-JEV。S80 它研究如何按“含有安全缺陷的风险”为源代码函数排序，让审查人员先从最可疑的函数入手。Jev 1.13 在其中作为作者自建的微调开放模型的对比基准。S80 对开发者而言，这项工作的价值主要在于：它展示了 Jev 在目标案例极少的任务中的表现，并提醒人们默认阈值未必合理。这是一篇尚未经过同行评审的预印本；本文依据其全文撰写。

作者构建了什么

基础是开放模型 Qwen3.5-4B，作者用 LoRA 对其进行微调，并加上了用于二分类的输出。S80 他们认为主要问题在数据上。干净的基准数据集只包含很少的漏洞函数，而大型补丁档案则只包含漏洞函数。两者混合后，模型可能学会识别函数的来源，而不是判断它是否有缺陷。S80

因此，作者从每个修复提交中构建一个小组：漏洞函数、它的修复版本，以及同一文件中最多两个未改动的函数。这样共得到 2,829 个小组，包含 10,099 个函数。S80 在每个小组内，模型学习把漏洞版本排在其他成员之前。作者认为，这样可以让整个代码仓库共有的影响相互抵消。S80

他们用一个数字说明这种做法的必要性。只用参考数据、按常规方式微调的模型，在 67.2% 的“漏洞版本与补丁”配对中给修复后的代码打了更高的分。S80 这个数字针对的是他们自己的基线变体，而不是 Jev。

Jev 1.13 表现如何

主要测试集包含来自 57 个开源项目的 7,270 个函数，其中 322 个存在漏洞，占 4.43%。S80 作者通过官方 API、使用与其他模型相同的提示词调用了 Jev 1.13。不过，预印本没有给出问题的具体措辞，也没有说明使用的是 Noul、Choice 还是 Score。S80

在函数排序上，Jev 的 AUROC 为 0.743，由五个模型组成的 Cyber-JEV 集成为 0.814。平均精度（average precision）分别为 0.101 和 0.197。S80 在误报率不超过 1% 的严格限制下，Jev 发现了 7 个漏洞，Cyber-JEV 发现了 33 个。S80

从实践角度看，最值得注意的是阈值数据。在默认阈值 p > 0.5 下，Jev 触发了 4,031 条警报，超过全部测试函数的一半。S80 在警报数量相同的情况下，Jev 漏掉了 39 个漏洞，Cyber-JEV 漏掉了 16 个。S80

作者还考察了“漏洞函数与修复函数”配对，检查模型是否给有缺陷的版本打更高的分。Jev 在 18.8% 的配对中（即 271 对中的 51 对）给两个版本打出了相同的概率。因此，它 50.7% 的成绩包含了每次平局计入的半分。去掉平局后，Jev 只在 41.3% 的配对中胜出，Cyber-JEV 为 47.6%。S80 两个数值都低于一半，可见在这项测试中，区分修复与缺陷对两个模型来说都很困难。

局限在哪里

作者说明，他们没有把该系统部署到 CI 中，没有在连续的版本发布上运行它，也没有用它寻找新的漏洞。测试配对来自历史修复，而非实时的 pull request。S80 预印本缺少在同一任务上与 CodeQL 或 Semgrep 等工具的直接比较，作者也没有就速度或准确率与这些工具作任何比较性结论。预印本没有提到公开代码或模型权重。S80

被测试的是 Jev 1.13。TypeSafe 文档目前列出的最新版本是 jev-1.14.0，自 2026年10月14日起可用。S01 新版本在这项任务中表现如何，预印本没有研究。

对开发者和网店的启示

代码安全审查并不是网店的常见任务，但这篇预印本的教训适用于所有目标案例稀少的场景。当目标案例只占 4.43% 时，0.5 的阈值标记了超过一半的函数。S80 以下建议是我们自己的看法，并非预印本的结论。请根据团队实际能审查的案例数量来设定阈值，并用自己的数据加以验证。相关背景可参阅指南confidence 与校准。

如果用 Jev 的结果来排序，就要考虑平局。两个案例得到相同概率时，它们之间的顺序必须由代码中的另一项标准决定，例如改动的大小或代码的年龄。

作者把他们的模型描述为在深入分析之前为改动函数排序的第一道环节。S80 我们关于评判级联的文章也描述了这种低成本第一道过滤的角色。对于源代码函数这样较长的输入，还需要考虑成本。输入 token 每百万收费 0.042 美元，输出免费。S01 借助价格与限制页面可以更方便地估算费用。