Picture that Tuesday morning we’ve all had. A new advisory lands in your inbox: CWE-22, path traversal, and it names a dependency you ship in production. The advisory tells you what class of bug exists. It does not tell you where it lives in the 300-file repo now staring back at you.

So begins the triage tax: an engineer, a coffee, and two hours of grep before anyone can even start the conversation about whether you’re exposed. Multiply by every advisory, every repo, every quarter. That’s not a security problem, that’s a payroll problem!

Hold on to that Tuesday. This series is about answering it properly, end to end. It takes five posts to get there, each answering one question:

1. Where should I look? That’s this post.
2. Is what I found there actually real? That’s Part 2.
3. How do I make sure nobody, human or AI, ever writes it again? That’s Part 3.
4. Does that prevention actually work? That’s Part 4, a controlled experiment, because a security control you haven’t measured is just a hope.
5. Can all of this run as one loop? That’s Part 5.

These questions can be addressed with some very interesting Cisco-originated projects, and I like to think of them as a small cast: Antares is the star that shows you where to look, Foundry is the forge that proves what’s real, and CodeGuard is the guard that keeps the weakness from coming back. Parts 4 and 5 put that cast to the test and then to work together. Today is the star’s turn.

I spent a few weeks running Cisco’s Antares-1B against a public benchmark, entirely on my laptop, and I want to show you what a one-billion-parameter model can do when it has been taught not to know things, but to investigate them. No cloud API. No source code leaving the machine. No GPU invoice.

Everything below comes from stored runs you can replicate yourself in my Antares repo. Let’s go.

The idea: retrieval that behaves like an investigator

Most “AI finds your bugs” demos are one-shot. You paste code in, a very large model pattern-matches, and you get an answer with a confidence you have no way to audit.

Antares does something different, and the difference is the whole product. Cisco took IBM’s Granite 4.0 1B as a base and post-trained it (supervised fine-tuning, then GRPO) on vulnerability localization. What it learned is not a catalogue of CVEs. It learned a search policy: given a weakness class and an unfamiliar repository, what’s the smartest next question to ask?

The loop is deliberately boring. The model gets a CWE description and a read-only repo in a locked-down sandbox. It can run up to 15 shell commands (a limit by design), like find, rg, grep, or sed. No network, no writes, no interpreters. It reasons, runs a command, reads the output, reasons again, and then submits a ranked shortlist of files that might be vulnerable.

Mundane tools. The value is everything in between: when to broaden, when to refine, when to abandon a hypothesis.

Watch it think

Let me show you one episode so you can see it in action. This is Antares applied to the tokio-rs/slab repo, given nothing but generic CWE-119 text about memory buffer boundaries, and working within that same 15-command budget from start to finish (you can find the full trace in my repo).

Turns 1–2. It wants to orient itself, so it reaches for a normal shell workflow: cd /workspace/repo && ls. The sandbox rejects &&. It swaps in a semicolon. Rejected too. Argh.

Here’s the first interesting moment: it doesn’t loop. It re-plans entirely, fires find . -maxdepth 2, and gets the project layout in one shot. Budget spent learning the terrain before hunting.

Turn 4. Now it translates. CWE-119 is abstract, standards-body prose about buffer boundaries. Antares converts it into Rust: unsafe, from_raw, ptr::, copy_nonoverlapping, unchecked offsets. That mapping from generic weakness class to ecosystem-specific idiom is exactly the kind of knowledge you normally pay a senior engineer for.

It tries all of those in one clever alternation regex. The sandbox rejects that too. So it drops the compound pattern and runs the simplest possible version: rg -n "unsafe" src tests. Hits, and only in src/lib.rs.

Turns 7–9. It probes ptr:: and copy_nonoverlapping. Both return nothing. A weaker model widens in panic. Antares treats the silence as evidence: the risk is already concentrated in one file, so its next moves double down there, with grep and then rg scoped to src/lib.rs alone. Same lines, higher confidence.

From searching to reading

Turn 12. With three commands left of its 15-command budget, it stops grepping and reads: nl -ba src/lib.rs | sed -n '700,900p', pulling the actual implementation around the unsafe blocks.

Turn 14. One command before it would have had to stop and guess, it submits src/lib.rs. One file. Exactly the file the security patch touched. F1 of 1.0, in 17.5 seconds.

Rejected commands, recovery, negative evidence, read-before-answer. That’s not autocomplete. That’s a junior analyst with good instincts, and every step of it is written down in a trace a human can audit.

The honest numbers, across 500 repositories

One good episode might be an anecdote. So I ran the full public VLoc Bench manifest (the vulnerability localization benchmark): 500 real repositories, each checked out at the commit before its security patch. Roughly 9 hours on my Mac.

Let’s be straight about that F1. Cisco publishes 0.209 for the same weights on the same benchmark, served with vLLM on datacenter GPUs and averaged over three runs. I got 0.168 from a single sweep on an Apple M1. Same model, different stack. Reproducing 80% of a vendor’s published score on hardware that fits in a backpack is, frankly, a great result for the vendor.

And notice which metric matters for the use case. If your job is “which file do I open first?”, hit@any is your number, and one in three is a shortlist that pays for itself in minutes.

“Fine, but why not just use a big model?”

Fair question, and the honest answer is that I can’t settle it from my laptop, because I only ran Antares. But Cisco’s technical report settles it.

They put the whole field (frontier closed models, large open-weight models, small open-weight models, and the Antares family) through the identical harness: same tools, same task inputs, same interaction budget, same temperature, averaged over three runs each. Here’s where the file F1 landed on Phase A:

Sit with that for a second. The one-billion-parameter model that runs on your laptop places fourth, above every large open-weight model in the study and above Gemini 3 Pro. And on recall, the fraction of genuinely vulnerable files it manages to surface, Antares-1B beats everything, including GPT-5.5 at maximum reasoning effort.

The report’s own phrase for the shape of this table is a “capability cliff”: systems either reach the 0.186–0.229 tier or fall below 0.152, and parameter count barely predicts which side you land on. GPT-5 scores 0.048. Its own smaller sibling GPT-5 Mini scores twice that. Model scale is simply not the axis that matters here.

There’s a floor worth knowing too. Cisco also ran the classic tools at this task: the best Semgrep configuration reached 0.086 file F1, and CodeQL 0.023 while abstaining on over 92% of repos, because it couldn’t build the extracted snapshots. A 1B model that reads code adaptively is doing something rule engines structurally cannot.

The cost gap

And the cost line is the punchline. The full 500-task benchmark runs in about 15 minutes on a single H100: under two seconds and less than $0.002 per repository, roughly a dollar for the whole sweep. Cisco puts the equivalent frontier-API workload at over one hundred dollars. Same task, two orders of magnitude apart, and only one of the two options can run inside your own trust boundary.

That’s the real answer to “why not a big model?” On this job, the big model isn’t better. AND it’s more expensive. AND it needs your source code.

One caveat, and one check I ran myself

That table is Cisco’s own evaluation, so treat it as a vendor benchmark, which is exactly why it matters that the harness and weights are public and the numbers are reproducible. My sweep is one small piece of that reproduction, and it landed where it should have.

I did run one thing purely as a methodological check: the same 500 repos against the base Granite model, the un-post-trained checkpoint Antares starts from. Of course it did not perform at all, as it was never trained for this task. That is not a fair fight and I’m not claiming it is; Cisco reports the same near-zero result for it. Its only job in my study was to rule out the boring explanation for my own numbers: that VLoc Bench is easy, and any competent 1B model dropped into this sandbox would stumble onto the right file with generic greps. It wouldn’t. It can’t even complete the loop. So the 33% is coming from the weights, not from the scaffolding.

Why a business should care

Your source code never moves. This is the headline for every regulated customer I talk to: financial services, public sector, defense, healthcare, and any partner who is contractually forbidden from shipping a client’s proprietary code to a third-party inference API. Antares runs air-gapped. The weights sit on the machine, the repo sits on the machine, the analysis happens on the machine. The data-residency conversation is over before it starts.

The economics change BIG TIME. Fractions of a cent per repository instead of a per-token bill that grows with how thorough you’re willing to be. That changes behavior: you can afford to run this on every advisory against every repo, not just the scary ones. And Cisco sized the family for where the code actually lives: 350M for mobile and IoT, 1B for laptops and workstations, 3B for any single GPU.

It shows its work. Every episode produces a reasoning trace, and the official Antares CLI emits SARIF 2.1.0 (the format GitHub Code Scanning uses) plus a --fail-on-findings flag you can wire into your CI/CD pipelines. This drops into the tooling customers own today. For partners, that’s a services offering with an audit trail attached, not a black box.

It reduces scope before the expensive step runs. That shortlist provided by Antares is a filter. Point an LLM-powered heavier detector, a deeper indexer, or a full reasoning pass at 30 files instead of 300 and the whole downstream pipeline gets cheaper and sharper. Remember that sentence; the finale of this series is built on it.

What it is not

I would be doing you a disservice if I didn’t clarify this.

Antares does localization, not detection. It answers “where should I look?”, not “is this exploitable?” A path on the list is a hypothesis, not a finding, and a human, a test, or a deeper analysis still has to confirm it.

The lists are noisy. The gap between hit@any (a third of repos) and F1 (0.17) is that noise: the right file frequently shows up with wrong ones for company.

On already-patched trees, it still tends to submit files rather than declare the code clean. It was trained to find candidates, not to certify fixes. So never read a weak list as “we’re safe”.

And it has an operating envelope. Its accuracy falls off sharply as repositories grow past a few megabytes, because 15 commands simply can’t cover a 100 MB codebase. I hit that wall myself later in this series, and I’ll show you exactly where it is.

Used as a triage accelerator, it’s excellent. Used as an oracle, it will mislead you.

Cisco built that patched-tree failure mode straight into the benchmark. Every repo is evaluated twice, once on the vulnerable tree and once on the patched one, so the false-positive behavior is measured in public rather than buried. Vendors who are nervous about their numbers do not design evaluations that way.

Next: the star needs a forge

So we have a star. It points a beam into the dark and says “look here”. It’s cheap, it’s private, and one time in three it’s pointing at the right file.

But “look here” is not “this is real”. If you hand that shortlist straight to a developer, you’re asking them to trust a hunch. If you hand the whole repo to a big LLM instead, you get a confident wall of text that you can’t verify, can’t reproduce next week, and can’t build a process on.

That’s exactly the reason why in my next post we’ll take Cisco’s Foundry Security Spec out of the design document and into the real world: a working implementation run against some real-world popular repos and libraries, with every finding checked against the bytes on disk. That’s where hunches become evidence. And ofc I’ll show you how to point it at your own code.

See you next week!

Everything in this post is reproducible from github.com/juliogomez/antares: stored 500-repo sweeps, saved traces, and the analysis scripts. Antares-1B weights and the technical report are on Hugging Face.