Building a Faster, Cheaper Vulnerability Scanner With Jev
Introduction
Scanning code for vulnerabilities is becoming an essential part of the SDLC. However, this can be costly for both humans and tokens. Organizations either do not scan as frequently as they should or leave large parts of the codebase unchecked.
We experimented with Jev to build an effective vulnerability scanner that can perform close to GPT-5.6 Luna at an even cheaper cost.
We think this line of work is important as hacking is becoming an efficiency game. An attacker can put all their efforts into finding one vulnerability with a high payoff. A defender must continuously cover every repository and commit. We believe in supporting defenders in rethinking their security in a world with autonomous attacks [1][2][3].
We obsess over cost-effective vulnerability discovery research at depthfirst because we build for a world where defenders can protect their code continuously and proactively when autonomous attacks are common.
How we achieved this
In the past weeks, a new architecture called Jev has received a lot of attention. Jev is a classifier. Give it some context, a question, and a list of options, and it outputs a probability for each option. Unlike an LLM, it outputs probabilities instead of answering the question by generating a sequence of tokens.
You can ask Jev, “does this code have a vulnerability,” provide relevant context, then receive its probability for true.

Classifying a vulnerability type such as Common Weakness Enumeration (CWE) works similarly. We can ask Jev one true or false question per CWE. Because each question is independent, we can ask them all in parallel and cache the shared context.

This saves both time and money. Input costs $0.042 per million tokens, five times less than Luna, and output is free. Each call takes around a quarter of a second vs around 10 seconds for Luna. The downside is that its context window is 32,000 tokens, compared to Luna at 1 million tokens.
As part of our research, we built a vulnerability scanner around Jev to see how it would perform on dfbench. This is a new harness that works around its 32k context limit by breaking the entire scan into classification tasks:
- Find code likely to contain a vulnerability. First, split the repository into small chunks. Then, show Jev each chunk and ask it which ones are security critical or likely to contain a vulnerability given the task. The chunks with the highest probability become context for the next parts.
- Determine if there is vulnerability. Jev scans each chunk in parallel with the context from the first step, locating potential vulnerabilities.
- Classify the vulnerability and its details. Jev is then asked a series of questions to get the vulnerability type, attack pattern classification, pathway of untrusted input (code locations), then locates where attacker-controlled input enters the code, where it causes harm, the flawed check or logic that allows it, and the likely security impact.
The result is a vulnerability, its location, and how an attacker can exploit it.
Since the scanner is parallelizable and each call is quick, the full scan takes only around 2 seconds with Jev compared to at least 3 minutes with most other models.

Limitations
Our Jev-based scanner only answers the questions we thought to ask. We must include relevant vulnerability finding questions in our harness, and Jev answers them. However, coupling Jev with an LLM agent might lead to better performance as it can notice things that we didn’t anticipate when building our harness.
Our Jev-based scanner goes deep but can be expanded further. Jev is very efficient at covering a full codebase scanning for vulnerabilities. But, many vulnerabilities that are exploited require connecting different parts, which needs stronger reasoning. LLMs are much better at this. Jev can still help in this process by providing the LLMs relevant context.
Findings may not have enough context. Jev can classify the vulnerability type and attack pattern, but a security team might want more details on what the actual vulnerability is and how it can be exploited. LLMs can be used to enrich Jev’s outputs to provide this.
Continuing the work
Our Jev-based scanner shows a lot of promise as an extremely cheap first pass for vulnerability discovery and validation. Because it is extremely fast, costs cents per scan, and can be used in places that were previously too expensive or inconvenient to cover.
For example, you might use it to scan every package in a large dependency tree, or equip defenders with a cheap way to triage before escalating to a more expensive model.
We’re excited to keep building vulnerability scanners that are cheaper and more capable, so defenders can stay ahead of attackers no matter how fast they move.
References
[1] Anthropic, “Disrupting an AI-orchestrated cyber espionage campaign,” 2025.
[2] Hugging Face, “Security incident disclosure, July 2026,” 2026.
[3] Unit 42, “Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks,” 2026.