Vulnerability localization is one of those tasks that looks easy until you try to automate it. You have a CVE description and a codebase. You need to find which specific source files contain the bug. A good human investigator reads the CVE, searches for relevant code patterns, examines candidates, updates their hypothesis, narrows down. General-purpose LLMs fail at this reliably: they generate confident-sounding file paths that have nothing to do with the actual vulnerability.
Cisco’s security research team released Antares last week — two open-weight models (350M and 1B parameters, with a 3B announced as upcoming) that encode the investigation workflow explicitly rather than treating localization as a single-pass generation task. The approach: start from the CVE description, search for relevant code patterns, read candidate files, incorporate the new evidence, narrow toward the most likely locations. The output is a ranked list of source files with the exploration trace visible for analyst review — so you can see why the model landed where it did, not just what it concluded.
That workflow structure is what lets a 350M-parameter model outperform much larger general models on this specific task. Cisco evaluated Antares on a new benchmark — 500 vulnerability localization tasks built from real vulnerability advisories, which they’re also releasing — and both models outperform “many powerful closed- and open-weight models in this critical security task at a fraction of the cost and runtime.” The benchmark itself is a useful contribution independent of the models. The security field has been short on narrow, task-specific evaluations; most current benchmarks reward broad generalization and give no signal about task-specific depth.
The open-weight release matters for security work in a direct way that isn’t true for most other use cases. Vulnerability analysis typically involves sensitive proprietary code — internal systems, infrastructure logic, code with legal or competitive sensitivity. You often can’t send it to a third-party API. Antares-350M fits on a single consumer GPU with headroom to spare and would run adequately on CPU for offline batch analysis. That matches what security teams at smaller organizations, public-sector agencies, and compliance-constrained enterprises actually need: a self-hosted CVE-to-file analyzer, not an enterprise AI contract.
This lands at a meaningful moment. A cross-model comparative study published this week examined automation scripts generated by ChatGPT, Copilot, and Gemini using identical prompts. Every script contained exploitable vulnerabilities. Nine of the 17 identified vulnerability classes appeared in output from all three models; the weighted CVSS scores differed by less than 10% across platforms. The study’s key finding: the risk isn’t tied to any particular model — it’s a property of the task category. Switching tools doesn’t fix it.
If AI tooling is generating code with systematic security issues, and that code ships to production at scale, then the volume of code requiring security review grows in proportion to AI adoption. Vulnerability localization is one step in that review pipeline, and Antares makes it substantially cheaper and more accessible.
The broader design argument is worth noticing. Foundation model development has trended hard toward scale and generalization — bigger, broader, one-model-for-everything. Antares argues in the other direction for tasks where the structure is well-defined and the evaluation criterion is measurable. Vulnerability localization has a specific input format (CVE + codebase) and an objectively scorable output (did you rank the right file?). Those properties make it a good candidate for a model trained with an explicit workflow, rather than a general model prompted to improvise. The same logic probably applies to a wider set of narrow, high-stakes tasks than the current tooling ecosystem reflects.
The 3B model will be worth watching. At that size, with the same structured workflow, it should handle more complex repository structures and less precisely specified CVEs. But the 350M result is already the interesting proof: you don’t need scale if you have task-appropriate structure.