Topic starter
30/09/2026 5:00 pm
TL;DR: A Jev-based vulnerability scanner that classifies code in parallel cuts scan time to about 2 seconds and costs $0.042 per million input tokens, positioning fast first-pass vulnerability discovery as a cheaper way to cover more of the codebase, according to depthfirst. The governance shift is toward continuous, broad scanning before escalation to heavier reasoning or manual review.
NHIMG editorial: based on content published by depthfirst: Building a Faster, Cheaper Vulnerability Scanner With Jev
By the numbers:
- Input costs $0.042 per million tokens, five times less than Luna.
- Each call takes around a quarter of a second vs around 10 seconds for Luna.
Questions worth separating out
Q: What breaks when code scanning is too expensive to run continuously?
A: Teams stop scanning as often as they should, which creates blind spots across repositories, commits, and dependencies.
Q: When should organisations prioritise fast vulnerability triage over deep analysis?
A: Prioritise fast triage when the codebase is large, the release cadence is high, and the goal is to identify which areas deserve deeper scrutiny first.
Q: What are the signs that a code scanning programme is underperforming?
A: Look for long scan runtimes, high per-scan costs, uneven repository coverage, and backlog growth between code changes and security review.
Practitioner guidance
- Implement a two-stage code scanning pipeline Use a fast classifier to rank repositories and chunks for likely vulnerability density, then send the highest-risk areas to a deeper reasoning pass for validation and exploit detail.
- Measure scan coverage as a governance metric Track what percentage of repositories, commits, and dependency paths receive a security pass within your normal SDLC window, not just how many findings the tool produces.
- Separate detection from exploit explanation Require each finding to include attack pattern, untrusted input path, flawed logic, and likely impact so triage can prioritise risk instead of raw alerts.
What's in the full article
depthfirst's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact dfbench harness design used to break large codebases into security-critical chunks
- The question set used to classify vulnerability type, attack pattern, untrusted input flow, and impact
- The practical limitations of a 32,000-token context window in real scanning workflows
- Where an LLM agent could add reasoning depth beyond the Jev-based first pass
👉 Read depthfirst's analysis of a cheaper, faster vulnerability scanner built with Jev →
Jev vulnerability scanning: can cheaper coverage keep pace with attacks?
Explore further
30/09/2026 5:00 pm
Cheap first-pass scanning is becoming a governance requirement, not a convenience. When defenders cannot afford to scan every repository and commit frequently, security coverage becomes selective by default. That is the real control gap this article exposes: not weak detection theory, but insufficient economic feasibility. For practitioners, the question shifts from whether a scanner is accurate enough in isolation to whether it can sustain continuous coverage across the SDLC.
A question worth separating out:
Q: How should security teams balance automated scanning with human review of attack surface findings?
A: Security teams should use automation to collect and correlate evidence, then apply human analysis to separate noise from meaningful risk. Automated tools are good at breadth, but they often miss context, business impact, and chained exposures. Human review is what turns a long list of issues into an accurate picture of exploitable attack paths and practical mitigation priorities.
👉 Read our full editorial: Jev-based vulnerability scanning shifts code security toward cheap coverage
