Cisco Antares can find likely vulnerable files. It cannot decide whether to patch.

In its July 21 announcement, Cisco released Antares-350M and Antares-1B to help security analysts narrow a known vulnerability class to likely source files. Given a Common Weakness Enumeration (CWE) category description and read-only access to a repository snapshot, Antares explores the code and returns ranked file paths for human review.

That is a useful but bounded job. Antares can help answer, “Which files should we inspect?” It cannot establish whether a vulnerability is exploitable in a particular environment, decide whether a patch is necessary, generate a verified fix, or own the remediation decision. The practical evaluation is therefore an advisory-driven localization pilot alongside existing static analysis and human review, using both a known vulnerable repository snapshot and its patched counterpart.

Antares turns a known weakness category into file candidates

A CWE is a standard category for a software weakness, such as improper input validation or path traversal. Under the protocol in the Antares technical report, the model receives a generic CWE description and terminal access to an immutable repository snapshot. It does not receive the full advisory, a severity rating, file hints, or a prepared set of suspicious code.

The model can use up to 15 terminal commands to search and read the repository. It then submits ranked file paths or declares that it found no matching vulnerability. The terminal environment is read-only, so this process ends at localization: it does not change source code.

The released Antares command-line interface can run an analysis for a selected CWE or sweep a repository across selected CWE categories. According to the Antares-1B model page, it returns human-readable, JSON, and SARIF 2.1.0 output; SARIF is a standard format for exchanging static-analysis results. The candidates are file-level findings intended for analyst validation. Line-level localization, patch generation, and remediation are outside the current system’s scope.

Cisco calls the models open-weight because their learned parameters are available, but access still has conditions. The Hugging Face collection publicly lists Antares-350M and Antares-1B under Apache-2.0. Each model page requires users to share contact information, accept the access conditions, and submit a manually reviewed request before downloading its files. Both models are built from IBM Granite 4.0 checkpoints. Cisco’s announcement describes Antares-3B as coming soon; the technical report says the evaluated 3B model is retained internally and is not part of the current release.

VLoc Bench measures file localization when every Phase A repository is vulnerable

Cisco evaluated Antares on VLoc Bench, a public benchmark with 500 tasks drawn from 290 real-world repositories across six package ecosystems and 147 CWE categories. Each task pairs a known vulnerable snapshot with the implementation files changed by its security patch. The Apache-2.0 benchmark repository publishes the evaluation harness and describes a second, patched snapshot for each task.

The benchmark has two phases. Phase A gives the model the vulnerable snapshot and asks it to find the affected files. Phase B gives it the patched snapshot and expects it to report no matching vulnerability. The technical report evaluates Phase A only, even though the benchmark specifies both phases. Its results therefore provide no Antares true-negative rate or production false-positive estimate.

The primary measure is File F1, a score from 0 to 1 that combines file-level precision and recall. Precision asks how many submitted files match the patch-derived ground truth; recall asks how many ground-truth files the model submitted. The report calculates the score for each task, averages it across all 500 tasks, and then averages the results across three runs.

This setup tests whether a model can localize files when a vulnerability is already known to exist. It does not measure how often Antares would discover vulnerabilities in ordinary repositories, whether the weakness is reachable or exploitable in a buyer’s environment, whether it can identify the exact line, or whether a proposed patch is correct. It also says nothing about production remediation outcomes.

The reported scores support a narrow aid, not an automated verdict

Across three runs under the same harness, the technical report gives the unreleased Antares-3B a File F1 of 0.223, precision of 0.303, and recall of 0.221. Antares-1B scored 0.209, 0.262, and 0.224 on the same measures; Antares-350M scored 0.135, 0.136, and 0.178. GPT-5.5 with xhigh reasoning scored 0.229 File F1, 0.310 precision, and 0.221 recall. The separate 0.221 GPT-5.5 result on the live leaderboard uses the default reasoning setting.

Antares-1B had the highest recall among the systems in the report, but 0.224 remains modest in absolute terms. The benchmark page also says 190 of the 500 tasks were unsolved by every evaluated system. That is a finding about the current benchmark and model set, not a universal floor for vulnerability detection.

Static-analysis baselines scored lower on this particular task: Semgrep reached 0.086 File F1, Semgrep-CWE 0.052, CodeQL 0.023, and Horusec 0.020. Those figures do not establish that Antares is generally better than static analysis. VLoc Bench begins with a generic CWE description and rewards file localization under a constrained terminal harness, while static tools apply language-specific rules and data-flow analysis to different detection jobs. As our review of deterministic CodeQL and AI-assisted findings explains, the two approaches produce different evidence and should be evaluated separately before they influence a merge.

Small, concentrated repositories are the best starting point

Repository structure had more effect on the reported results than vulnerability severity. The report says pip and npm tasks produced File F1 scores 7–14 times higher than Maven tasks across models. Antares-1B reached 0.843 File F1 on repositories under 100 KB, but GPT-5.5 variants overtook Antares at 10 MB and above. When the ground truth covered five or more files, performance collapsed across systems.

These results make a small repository with a concentrated, already-documented vulnerability the sensible first pilot. They also give the pilot a deliberate second test: a larger repository or a fix that spans several implementation files. If Antares only identifies the first plausible foothold and misses the rest of the call path or validation chain, the evaluation should expose that limit before the model enters a live workflow.

Cisco reports that Antares-3B completed a full 500-task sweep in approximately 15 minutes on one H100 GPU with 16 parallel workers, an amortized average of under two seconds and less than $0.002 per task. Those figures describe that benchmark setup. They are not latency or cost promises for a laptop, a different inference stack, or a production repository.

Antares belongs between vulnerability context and source-code review

External vulnerability triage and repository localization answer different questions. CVE and asset triage connects advisories with products, deployed versions, exposure, known exploitation, and business ownership. Antares starts after a weakness category has been selected and narrows the repository files an analyst should inspect. Our earlier article on vulnerability triage and review queues covers that external evidence and ownership work; Antares does not replace it.

Static analysis remains useful beside Antares because it can apply repeatable rules, follow supported data flows, and identify findings without first assuming that every repository contains the target weakness. Antares contributes a different signal: a model-generated ranking based on iterative repository exploration. Analysts can compare those candidates and the terminal trace with scanner findings, the advisory, the actual code path, tests, and the known fix.

Open weights can also support local or air-gapped operation, but only when both the weights and inference endpoint are hosted inside the organization’s environment. The CLI can send task instructions, file paths, source selected during inspection, and related context to its configured inference endpoint. Hosting weights locally does not prove that the surrounding endpoint, telemetry, tools, or trace storage has no external egress.

A useful pilot tests the vulnerable and patched snapshots with the same CWE

Start with one advisory whose CWE mapping, vulnerable commit, patched commit, and changed implementation files are already known. Run Antares against an immutable copy of the vulnerable snapshot, using the same CWE description that will drive the real workflow. Compare its ranked files and terminal trace with the patch-derived ground truth and with the files surfaced by existing static analysis.

Measure analyst time to reach a validated code path, the ground-truth files Antares missed, and the extra files analysts had to dismiss. Those measures reveal whether localization speeds review without hiding incomplete coverage behind one aggregate score. Keep scanner output and Antares output separate so reviewers can see which tool produced each candidate.

Then run the same CWE input against the patched snapshot. Because the technical report did not evaluate Phase B, a clean result should be treated as local pilot evidence, not as confirmation of a published Antares true-negative rate. Finish with one larger or multi-file case to test the conditions where the report found the sharpest degradation.

The operating decision is limited: use Antares if it consistently helps analysts reach the right files faster within the repositories and CWE categories you tested. Do not let its candidate list trigger a patch, merge, exception, or remediation action without verification. A security owner still has to confirm that the code is affected, determine exposure and urgency, review the proposed change, and own the production decision.

BaristaLabs can help you test one advisory-driven localization workflow against known vulnerable and patched snapshots, existing static-analysis evidence, analyst time, and your source-code boundary. Plan a focused evaluation before model-generated candidates influence a security gate.