Security teams often know that a vulnerability exists before they know exactly where to look for it inside a large software repository. An advisory may identify the weakness category, affected product or related CVE, but developers may still need to search through hundreds or thousands of files before finding the code that deserves attention.
Cisco is trying to narrow that gap with Antares, a new family of compact AI models built specifically for vulnerability localisation.
The company has released two open-weight models, Antares-350M and Antares-1B, through Hugging Face under the Apache 2.0 licence. Cisco is also developing a larger three-billion-parameter version.
Unlike general-purpose coding assistants, Antares is not intended to write applications, generate patches or automatically repair security defects. Its job is more focused: given information about a known weakness, it searches a software repository and identifies the files most likely to contain the relevant code.
Finding Where to Look Before Trying to Fix Anything
When a new vulnerability is disclosed, the first challenge is often not understanding the advisory. It is connecting that advisory to the actual implementation inside the organisation's codebase.
A security bulletin may mention a Common Weakness Enumeration category such as prototype pollution, type confusion, improper access control or insecure memory handling. However, that description does not always reveal which source files are responsible.
Antares is designed to support this early investigation stage.
The model receives a CWE identifier and a general description of the weakness. It then explores the repository through a terminal-style interface, using familiar commands such as grep, find and cat.
The model can inspect filenames and source content, reconsider its search strategy and continue narrowing down the likely locations before returning a list of candidate file paths.
This makes Antares closer to an AI-assisted investigator than an automated vulnerability scanner.
Antares Does Not Confirm That a Vulnerability Exists
The distinction between localisation and detection is important.
Antares does not return a definitive statement that a particular file is vulnerable. It identifies files that may be relevant to the supplied weakness category.
The model also does not currently identify the exact affected lines, explain the vulnerable logic or generate a secure replacement.
Its output is therefore a shortlist for human review rather than a final security finding.
A developer or application-security specialist must still inspect the suggested files, understand the surrounding behaviour and determine whether the suspected weakness is genuinely present.
This limitation should be viewed as part of the product's design rather than an accidental omission. Cisco is positioning Antares as a tool for reducing search time, not replacing professional security analysis.
A Narrower Model for a Narrower Security Task
Large coding models can answer broad programming questions, generate functions and reason about complex code. However, those capabilities come with higher infrastructure requirements and may not be optimised for security-specific repository searches.
Antares takes a more specialised approach.
Instead of attempting to solve every software-development problem, it has been trained to navigate repositories based on known vulnerability context.
That narrower scope may offer several benefits.
Smaller models are easier to deploy locally, require less inference capacity and may be simpler to integrate into controlled security workflows. They can also reduce the need to expose proprietary source code to an external hosted AI service.
For organisations with strict data-residency, confidentiality or intellectual-property requirements, local deployment may be one of Antares' most attractive features.
How the Repository Search Works
The Antares workflow begins with external vulnerability context.
A security team may receive a vulnerability advisory, dependency alert or CWE category indicating the type of flaw that requires investigation.
The model is then given the weakness identifier and a general description. From there, it searches through the repository using terminal commands.
It may begin by looking for filenames, functions, classes or code patterns commonly associated with the weakness. After reviewing the results, it can adjust its query and inspect additional files.
For example, a prototype-pollution investigation might lead the model to search for unsafe object merging, property assignment or recursive processing functions.
A permission-related weakness might require it to examine authentication handlers, role checks, access-control middleware and request-routing logic.
The difficulty is that some vulnerabilities have clear textual patterns, while others depend on interactions between several components. This difference affects how well the model performs.
The Benchmark Limited the Model's Investigation
Cisco evaluated Antares using a purpose-built Vulnerability Localization Benchmark.
During the test, each model received only a CWE category and a generic description of the weakness.
It did not receive advisory text, severity details, exact filenames or hints about where the problem was located.
The model was also restricted to 15 terminal commands before it had to submit its answer.
This creates a more demanding evaluation because the model must decide how to use a limited search budget.
A weak search strategy may waste commands on irrelevant files. A stronger strategy must quickly identify useful patterns, inspect likely areas and refine the investigation before time runs out.
The command limit also helps explain why repository size becomes an important constraint.
Designed to Complement Existing Security Tools
Cisco does not present Antares as a replacement for static analysis, dependency scanning or dynamic security testing.
Traditional application-security tools already perform important tasks that Antares does not.
Static application security testing may use predefined rules, data-flow analysis, control-flow analysis or taint tracking to identify suspicious code patterns.
Software composition analysis can identify vulnerable third-party packages and dependencies.
Secret scanners look for exposed passwords, API keys and tokens.
Dynamic testing evaluates how a running application behaves under attack.
Runtime monitoring can detect exploitation attempts or suspicious behaviour in production.
Antares approaches the problem from a different direction. It begins with an external vulnerability description and uses a learned search process to identify files that may be connected to that weakness.
A practical security workflow could therefore combine several tools rather than choosing only one.
A dependency alert may identify the affected package. Antares could then locate the files that interact with the relevant code. Static analysis and human review could confirm the weakness, while testing and remediation tools handle validation and repair.
Why Local Deployment Matters
Many software repositories contain proprietary logic, internal architecture and confidential business information.
Sending that source code to a public AI service may be unacceptable for some organisations, particularly those operating in healthcare, finance, government, defence or regulated industries.
Antares' smaller size makes local hosting more realistic.
Cisco documents deployment through frameworks and runtimes including:
However, installing the model locally does not automatically guarantee that repository data remains private.
The command-line interface connects to an OpenAI-compatible inference endpoint. To keep the full workflow inside the organisation, both the model and the endpoint must be hosted internally.
The organisation must also manage the surrounding infrastructure, including hardware, authentication, access controls, logging, patching and model lifecycle management.
Running the Model Safely
Giving an AI model terminal access to a repository introduces operational risks, even when the model is only intended to read files.
Cisco recommends running repository analysis inside isolated containers with network access disabled.
It also advises using:
These precautions reduce the risk of accidental modification, uncontrolled resource usage or unexpected access to unrelated systems.
Network isolation is especially important. A repository-analysis tool should not need unrestricted internet access while examining sensitive source code.
The safest architecture is one where the model can read only the required repository snapshot and cannot communicate with external destinations.
Integrating Antares Into CI/CD Pipelines
The Antares command-line interface supports both targeted investigations and broader repository searches.
Teams can provide a specific CWE category when a known vulnerability requires follow-up, or run a wider sweep across the codebase.
The tool can return results in several formats, including human-readable reports, JSON and SARIF 2.1.0.
SARIF support allows candidate findings to appear in compatible platforms such as GitHub Code Scanning or feed into internal security dashboards and orchestration systems.
In a CI/CD workflow, Antares could be triggered after:
Cisco also allows the CLI to fail a build or deployment pipeline when candidate files are returned.
That behaviour is disabled by default, which is sensible because candidate files are not confirmed vulnerabilities.
Automatically blocking every pipeline based on an unverified shortlist could create unnecessary disruption and encourage teams to ignore or bypass the tool.
Changed Files or the Entire Repository?
One important implementation question remains open: how much of the repository should Antares examine during routine use?
A full repository scan may provide more context but consume additional time and computing resources.
Scanning only changed files could be faster, but it may miss vulnerabilities that depend on older code elsewhere in the application.
Another option would be to reuse previous results and focus only on areas affected by recent changes.
Cisco's documentation does not prescribe one production strategy.
Organisations will need to decide based on repository size, development velocity, available hardware and the level of security assurance required.
A high-risk release may justify a broader scan, while routine pull requests may be better suited to targeted analysis.
Benchmark Performance Shows Promise but Also Clear Limits
Cisco reported that Antares-1B completed its 500-task benchmark in approximately 13 to 15 minutes on a single Nvidia H100 GPU while using 16 parallel workers.
The company estimated the inference cost for the full run at US$0.71.
Under Cisco's comparison setup, GLM-5.2 reportedly cost US$12.50, while GPT-5.5 cost US$141.
These figures suggest that a compact specialist model may be significantly cheaper to run than larger general-purpose systems for this particular task.
However, inference cost is only one part of the total expense.
A production deployment would also require hardware, integration work, container management, security controls, monitoring, maintenance and human review.
The real cost per investigation may therefore be considerably higher than the raw model-execution figure.
What the Benchmark Actually Measures
Cisco created the Vulnerability Localization Benchmark because conventional coding benchmarks do not directly measure repository-level security localisation.
The benchmark contains 500 tasks drawn from 290 software repositories.
It covers six package ecosystems and 147 CWE categories, while 78% of the entries are associated with known CVE identifiers.
Each task uses a repository snapshot captured before the vulnerability was fixed.
The ground-truth files are the implementation files changed in the corresponding security patch. Tests, documentation and configuration files are excluded.
This approach provides a practical way to evaluate whether the model identifies files that were later modified to resolve a real vulnerability.
However, patch files are not always a perfect representation of every location involved in the weakness. Developers may alter nearby code for maintainability, refactoring or defensive improvements.
The benchmark therefore measures a useful but still imperfect approximation of successful localisation.
The Accuracy Numbers Require Careful Interpretation
Antares-1B achieved a file-level F1 score of 0.209, with precision of 0.262 and recall of 0.224.
Those numbers show that the model can find relevant files, but it is far from consistently accurate.
A precision score of 0.262 means that many returned candidates were not part of the recorded security fix.
A recall score of 0.224 means the model missed a substantial number of files associated with the patch.
The system can therefore reduce the search space in some cases, but teams should not assume that an unlisted file is safe or that every listed file is vulnerable.
Cisco reported that Antares-1B outperformed several larger models when all systems were given the same tools, prompts, command limit and generation settings.
That comparison is encouraging, but it remains a vendor-published evaluation.
The accompanying material does not include an independent replication, so external testing will be important before organisations rely on the results.
Repository Size Remains a Major Constraint
Cisco reports that Antares performs less effectively on repositories larger than 10MB when using the default 15-command limit.
This limitation is understandable.
Larger repositories contain more files, more naming patterns and more architectural layers. The model may spend several commands identifying the project structure before it begins investigating the relevant weakness.
Increasing the command limit could improve coverage, but it would also raise inference time, cost and the amount of generated output requiring review.
Teams may therefore need to divide large repositories into smaller services or components before analysis.
This could work well for microservice environments, but it may be more difficult for large monolithic applications where vulnerabilities depend on interactions across many directories.
Multi-File Vulnerabilities Are Harder
Antares also performs less effectively when the vulnerability requires context from five or more files.
Some flaws are local and easy to search for. A dangerous function call or insecure deserialisation pattern may appear in one obvious location.
Other vulnerabilities emerge only through the relationship between several components.
A permission issue may involve route configuration, authentication middleware, session handling and data-access logic.
A race condition may depend on the order in which several modules access shared state.
Memory-management problems may involve allocation in one file and cleanup in another.
These cases require broader architectural reasoning, making them more difficult for a model operating under a small terminal-command budget.
Some Weakness Categories Are Easier Than Others
Cisco reported stronger performance for vulnerabilities with distinctive searchable patterns, including type confusion and prototype pollution.
These weaknesses may involve code structures or terminology that can be located more directly through text-based repository exploration.
Performance was weaker for issues involving permissions, locking, memory management and broader program behaviour.
That difference is significant because it shows that Antares is not equally effective across all security domains.
Teams should evaluate performance against the programming languages, frameworks and CWE categories most relevant to their own software.
A model that performs well on JavaScript object-handling flaws may not provide the same value for complex concurrency problems in a large C++ codebase.
Language Coverage Is Not Clearly Defined
Cisco has not published a fixed list of supported programming languages.
The company states that performance may vary depending on the languages and vulnerability categories represented in the training data.
This creates uncertainty for organisations using less common languages or specialised frameworks.
Before production adoption, teams should test Antares against internal repositories that reflect their actual environment.
A proof of concept should include different repository sizes, languages, security categories and development styles.
The goal should not be simply to confirm that the model runs. It should determine whether the candidate files are useful enough to save reviewers time.
The Training Cutoff Creates a Freshness Gap
The models' training data has a cutoff of April 10, 2025.
This does not prevent Antares from investigating vulnerabilities disclosed later because the model can still receive a current CWE description or advisory-derived context.
However, it may be less familiar with newer frameworks, coding conventions, vulnerability patterns and library structures introduced after the cutoff.
Cisco recommends supplementing the models with current vulnerability feeds, advisory databases and security intelligence.
That reinforces the idea that Antares should operate as part of a larger security process.
The model supplies repository-search capability, while external systems provide up-to-date information about new threats.
The Training Corpus Is Not Fully Public
Cisco says the reinforcement-learning training data and benchmark do not overlap, which is important for reducing the risk of evaluation contamination.
However, the full proprietary training corpus has not been released.
Without that information, external reviewers cannot fully assess the balance of programming languages, repository types or vulnerability categories used during training.
This is common for commercial AI systems, but it limits transparency.
Organisations considering high-assurance use should treat the model as an experimental assistant until its performance is independently validated across a wider range of real-world environments.
Human Review Remains the Final Control
Antares may help answer the question, "Which files should we inspect first?"
It does not answer the more important questions that follow:
Is the vulnerability actually present?
Can it be exploited in this application?
What is the real business impact?
How should the issue be fixed safely?
Those decisions still require developers, security engineers and application owners.
Human reviewers must validate the candidate files, examine data and control flows, consider application context and test any proposed remediation.
The model's value lies in helping those specialists reach the relevant code faster.
Final Thoughts
Cisco's Antares models represent a practical attempt to apply smaller, specialised AI systems to a clearly defined application-security problem.
Rather than competing with general coding assistants, Antares focuses on vulnerability localisation: connecting known weakness information with the files most likely to contain the affected implementation.
Its small model sizes, local deployment options and SARIF support make it potentially useful for organisations that want AI-assisted repository triage without sending source code to an external provider.
At the same time, the benchmark results show that the technology remains imperfect. Antares returns false candidates, misses relevant files and struggles with large repositories, multi-file vulnerabilities and certain weakness categories.
It should therefore be treated as a prioritisation tool rather than an automated security authority.
Used carefully, Antares could reduce the time spent searching unfamiliar repositories after an advisory appears. Used without validation, it could create false confidence or unnecessary pipeline disruption.
The most effective role for the platform is likely to be alongside established security tools, current vulnerability intelligence and experienced human reviewers—helping teams decide where to look first, while leaving confirmation and remediation in professional hands.
Comments