Cyber-JEV: how an open model finds vulnerable code functions

Update, November 3, 2026: we removed references to other studies (decompilation, tool poisoning) that were not about Cyber-JEV, and the questions that repeated the text.

Cyber-JEV is a training method described in a preprint published on arXiv, designed to identify vulnerable code functions. An open-weight language model, meaning one whose weights are freely available, assigns each function a probability of being vulnerable without producing written explanations.¹ The problem the method addresses is the scarcity of vulnerable examples to train the model on. The authors work around it by turning fix commits, the changes that removed a known flaw, into comparison groups.¹

What does a model like Jev do?

Single-pass scoring models, like Jev, receive a function of code and return a probability that it is vulnerable. This lets security teams rank a large number of functions for review, without having to read an explanation generated for each one.¹ The comparison with Jev 1.13 is the preprint’s main benchmark. Cyber-JEV, too, takes a single function as input at the time of use and produces a single score.¹

Why are there so few examples to train these models on?

There are two types of data, and neither is enough on its own. Benchmarks with both vulnerable and non-vulnerable labels, once the examples related to the test ones have been removed, retain few vulnerable functions.¹ The largest public collections of vulnerabilities, on the other hand, contain almost only vulnerable functions. Combining them with the labeled benchmarks has a side effect: the source of the data becomes a clue to the label, and the model can learn to recognize where a function comes from instead of the flaw.¹ Training only on the labeled data does not solve the problem. According to the authors, the resulting model often gives an already fixed function a higher score than the original vulnerable version.¹

How does the Cyber-JEV method work?

The method starts from fix commits. Each comparison group contains the vulnerable function, its fixed version and up to two unmodified functions taken from the same file. The model thus sees the change that eliminated a recorded flaw.¹ A single model learns two tasks. The first is to classify functions based on the labeled reference data. The second is to rank the vulnerable function above the other members of its group, including the fixed version.¹ The comparison serves to shift attention from where the data came from to the difference between flawed code and repaired code. The unmodified functions from the same file act as a control, because they share context and style with the vulnerable one.¹ The base model is Qwen3.5-4B. The reported results refer to an ensemble of five models fine-tuned with this method.¹

What results do the authors report?

On a test benchmark of 7,270 functions, the ensemble of five models reaches an area under the ROC curve of 0.814, against 0.743 for Jev 1.13. The area under the ROC curve is a measure of how well a score separates vulnerable functions from the others, and a higher value indicates better separation.¹ The comparison was also made with a fixed review budget, equal to the 4,031 alerts generated by Jev. In that case Cyber-JEV misses 16 vulnerable functions out of 322, while Jev misses 39.¹ Compared with training on the reference data alone, the method ranks the vulnerable version above the fixed one more often, by a margin of between 14.8 and 29.2 percentage points across three sets of real-world fixes.¹ These are figures reported by the authors in the preprint. The sources consulted contain no independent verification, so they should be read as results yet to be confirmed.¹

What can a vulnerability score be used for?

The authors point to a practical use: ranking the functions modified in a pull request or a release, so that those with the highest score are reviewed first within a fixed review budget.¹ The score is not a diagnosis. It indicates where to look first, but it does not explain the nature of the flaw, because the model does not generate explanatory text.¹

This article was written by artificial intelligence from the sources cited, without human review. Automatic newsroom by Redazia.

Sources

Footnotes

1. Cyber-JEV: Matched Contrastive Fine-Tuning of Language Models for Fast Source-Code Vulnerability Triage, arXiv: cs.CL, cs.LG, cs.CR, 2026-11-02 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷