Antares, i piccoli modelli AI di Cisco che cercano vulnerabilità nel codice

L’intelligenza artificiale applicata allo sviluppo software è spesso associata a modelli sempre più grandi, costi di inferenza elevati e infrastrutture difficili da gestire fuori dai grandi data center. Con Antares, Cisco propone un approccio diverso. La nuova famiglia di Small Language Model (SLM) dedicati alla cybersecurity è stata progettata per svolgere un compito molto specifico: individuare i file che con maggiore probabilità contengono una vulnerabilità all’interno di un repository software.

I primi due modelli della famiglia, Antares-350M e Antares-1B, sono disponibili come open weight nella raccolta Antares su Hugging Face. Cisco anticipa anche l’arrivo di Antares-3B, che dovrebbe ampliare la famiglia mantenendo lo stesso orientamento: modelli più piccoli dei grandi LLM generalisti, ma addestrati per una fase precisa dell’analisi di sicurezza.

Il punto centrale non è soltanto la dimensione dei modelli. La tesi di Cisco è che, in attività altamente specializzate, la capacità di ragionamento non dipenda necessariamente dal numero di parametri. Un modello compatto, addestrato su un workflow ben definito, può risultare più pratico da usare in azienda perché richiede meno risorse hardware, consuma meno energia, costa meno per ogni esecuzione e può lavorare direttamente sull’infrastruttura interna, senza inviare il codice sorgente a un servizio cloud.

Piccoli modelli, costi ridotti e codice che resta in azienda

La localizzazione delle vulnerabilità è una delle attività più costose nella sicurezza del software. Quando emerge un nuovo problema, gli analisti devono collegare informazioni esterne, come advisory, database pubblici, CVE e categorie CWE, al codice effettivamente usato dall’organizzazione. Nei repository di grandi dimensioni questa ricerca non si riduce a una semplice corrispondenza testuale: bisogna seguire convenzioni di denominazione, dipendenze, percorsi di chiamata e relazioni tra file che spesso non sono evidenti.

Gli LLM generalisti possono aiutare a ragionare sul codice, ma il loro impiego su grandi repository comporta costi di inferenza elevati e requisiti hardware non banali. Se il modello viene usato tramite un servizio cloud, si aggiunge anche un problema di riservatezza: il codice sorgente, spesso proprietario, deve uscire dall’ambiente aziendale.

Antares affronta il problema partendo dall’efficienza. Modelli da 350 milioni e 1 miliardo di parametri possono essere eseguiti in locale o in ambienti on-premises, con requisiti computazionali molto più contenuti rispetto ai grandi LLM. Questo rende più semplice l’adozione in organizzazioni soggette a vincoli di compliance, ma anche in università, enti pubblici, centri di ricerca, nonprofit e team di sicurezza che non dispongono di budget paragonabili a quelli delle grandi aziende tecnologiche.

Il vantaggio diventa ancora più rilevante se l’analisi deve essere eseguita spesso. Uno strumento economico e abbastanza leggero da lavorare su ogni commit o all’interno di una pipeline CI/CD può trasformare la verifica del codice da controllo occasionale a processo continuo. È il punto editoriale più rilevante dell’annuncio: i piccoli modelli specializzati non cercano di sostituire un LLM generalista in ogni attività, ma rendono sostenibile un compito ripetuto molte volte.

Antares non genera codice: localizza vulnerabilità

Antares non è un assistente di programmazione e non nasce per generare patch. Il suo compito è precedente: restringere il perimetro dell’indagine quando si deve capire dove una vulnerabilità nota potrebbe trovarsi. Cisco definisce questa attività vulnerability localization.

Il workflow parte da una descrizione della vulnerabilità, che può essere ricavata da un advisory, da un CVE o da una categoria CWE. Il modello esplora quindi il repository e restituisce una classifica dei file che hanno la maggiore probabilità di contenere il problema. L’output non sostituisce il giudizio dell’analista, ma riduce il numero di file da verificare e rende più rapida la fase iniziale del triage.

È una distinzione importante. Molti benchmark di coding misurano la capacità di correggere un bug, modificare una base di codice o produrre una soluzione funzionante. Antares lavora invece su una fase diversa: aiuta a individuare il punto in cui guardare. In un grande repository, questa attività può assorbire ore o giorni, soprattutto quando il team deve verificare rapidamente se una vulnerabilità pubblicata riguarda anche il proprio software.

Come Antares esplora un repository

Il funzionamento di Antares richiama il metodo di lavoro di un analista esperto. A partire dalla descrizione di una vulnerabilità, il modello esplora il repository, individua pattern di codice pertinenti, legge i file candidati e aggiorna progressivamente il proprio percorso sulla base delle informazioni raccolte. Quando una pista non produce risultati utili, può abbandonarla e riprendere l’analisi in un’altra direzione, fino a restringere il campo ai file più rilevanti.

Il progetto nasce da una linea di ricerca del team Cisco Foundation AI sui modelli compatti. L’idea è che comportamenti come ricerca, revisione delle ipotesi, cambio di strategia e backtracking possano essere appresi anche da modelli di dimensioni contenute. In questo caso, la lettura proposta da Cisco è chiara: la specializzazione del training conta più della dimensione del modello.

Antares restituisce due elementi utili per il lavoro operativo: una lista ordinata dei file probabilmente coinvolti e la traccia dell’esplorazione effettuata nel terminale. Il secondo punto è rilevante perché rende il percorso del modello più verificabile. Un analista può controllare perché un file sia stato ritenuto importante e usare quella traccia come base per ulteriori verifiche manuali o automatizzate.

Cisco cita anche una CLI associata al modello, pensata per rendere il workflow utilizzabile in scenari concreti: scansione dei repository, ispezione dei risultati e integrazione nelle pipeline di automazione. Questo passaggio è essenziale perché Antares non viene presentato solo come modello di ricerca, ma come componente inseribile nei processi AppSec già esistenti.

La sicurezza deve diventare un controllo continuo

L’aumento degli strumenti di AI coding cambia anche il ritmo della sicurezza applicativa. Se gli assistenti generativi accelerano la produzione di codice, diventa più importante verificare in modo continuo che quel codice non introduca nuove vulnerabilità. Il problema non è solo scrivere software più velocemente, ma riuscire a controllarlo alla stessa velocità.

Nel comunicato Cisco, Reza Shokri, professore di Computer Science alla National University of Singapore, collega direttamente questo tema alla necessità di controlli economici e vicini al ciclo di sviluppo. Modelli piccoli ed eseguibili in locale permettono di analizzare codice proprietario senza farlo uscire dall’azienda e possono intervenire prima che una modifica venga integrata nel repository principale.

Una valutazione simile arriva da Amin Saberi, professore alla Stanford University e direttore del Language, Data, and Reasoning Lab. Il punto, in questo caso, è economico: strumenti avanzati di rilevamento basati sull’AI sono stati finora più accessibili alle organizzazioni con budget elevati. Modelli specializzati e meno costosi possono rendere più praticabile l’analisi automatica di ogni commit, non soltanto di controlli sporadici.

Un benchmark per misurare un problema specifico

Per valutare Antares, Cisco ha pubblicato il Vulnerability Localization Benchmark, o VLoc Bench, un test costruito per misurare proprio la capacità di localizzare file vulnerabili in repository reali. Il benchmark comprende 500 task, tratti da 290 repository, con 147 categorie CWE e più di 25 modelli valutati.

La struttura è in due fasi. Nella prima, il modello riceve un repository che contiene una vulnerabilità nota e descrizioni generiche delle categorie CWE; deve quindi esplorare il codice tramite terminale sandboxed e identificare i file vulnerabili. Nella seconda, il modello analizza la versione corretta dello stesso repository e deve confermare che la vulnerabilità non sia più presente, evitando falsi allarmi.

La scelta di creare un benchmark dedicato nasce da un limite dei test già usati per i modelli di coding. Benchmark come SWE-Bench misurano soprattutto la capacità di comprendere un problema software, modificare il codice e produrre una correzione. Antares affronta invece una fase precedente: individuare dove si trova il problema, partendo da un contesto di sicurezza limitato.

Cisco richiama anche CodeScout, un lavoro di ricerca sugli agenti capaci di esplorare basi di codice attraverso un terminale Unix. La differenza è che CodeScout valuta la localizzazione del codice in scenari di sviluppo software, mentre VLoc Bench misura la capacità di riconoscere pattern di vulnerabilità collegati a CWE, advisory e informazioni di sicurezza.

Prestazioni, costi e tempi di esecuzione

Nei risultati pubblicati da Cisco, Antares-350M e Antares-1B superano numerosi modelli open weight e proprietari più grandi nella localizzazione delle vulnerabilità. Il dato va letto come claim dell’azienda, ma è significativo perché il confronto non si concentra solo sull’accuratezza: i grafici mettono insieme prestazioni, costo stimato dell’inferenza e tempo di esecuzione.

Il benchmark ufficiale evidenzia anche quanto il problema resti difficile. Nel dataset, 190 task su 500 non vengono risolti da nessuno dei sistemi valutati, e la dimensione dei repository incide molto sulla difficoltà. Le prestazioni calano sensibilmente quando il codice da esplorare cresce, segno che la complessità strutturale del progetto pesa almeno quanto il tipo di vulnerabilità.

Questi risultati rafforzano la tesi di Cisco: la specializzazione può contare più della scala. Nel benchmark, i modelli Antares sono progettati per competere con sistemi molto più grandi in un compito ristretto, riducendo allo stesso tempo il costo operativo. Per un’organizzazione che vuole integrare controlli automatici nel ciclo quotidiano di sviluppo, il rapporto tra accuratezza, costo e tempo può essere più importante della prestazione assoluta ottenuta da un LLM molto più pesante.

Open weight, non semplice marketing

La pubblicazione dei modelli come open weight è parte integrante dell’annuncio. I pesi disponibili su Hugging Face consentono a ricercatori, sviluppatori e team di sicurezza di eseguire Antares nei propri ambienti, provarlo su repository interni e integrarlo in strumenti esistenti.

Open weight non significa necessariamente open source in senso pieno. Cisco rende disponibili i pesi dei modelli e la documentazione necessaria all’uso, ma questo non equivale alla pubblicazione completa di tutti gli elementi della pipeline di addestramento. Per il caso d’uso di Antares, però, la disponibilità dei pesi ha un effetto pratico immediato: permette analisi locali su codice sensibile e favorisce verifiche indipendenti da parte della comunità.

Il modello non sostituisce gli strumenti tradizionali di sicurezza applicativa. Restano necessari analisi statica, Software Composition Analysis, secret scanning, test dinamici, controlli su infrastruttura e container, threat modeling e revisione umana. Antares si colloca in una fase specifica: ridurre il tempo necessario per passare da un’informazione di vulnerabilità a un elenco ragionato di file da controllare.

Il ruolo di Antares nella strategia AI di Cisco

Antares si inserisce in una strategia più ampia con cui Cisco sta cercando di costruire strumenti di sicurezza basati sull’AI più misurabili e verificabili. Con Foundry Security Spec, l’azienda ha pubblicato una specifica aperta e indipendente dal modello per realizzare sistemi agentici di valutazione della sicurezza, con ruoli, guardrail e output controllabili.

Con Project CodeGuard, il lavoro si sposta invece sulla prevenzione: regole e competenze pensate per guidare gli agenti di coding verso pratiche di sviluppo più sicure. Antares aggiunge un terzo elemento: modelli compatti e specializzati per localizzare vulnerabilità nei repository.

Il filo che collega questi progetti è diverso dalla logica del singolo grande modello chiamato a risolvere ogni problema. Cisco sta costruendo un insieme di componenti più piccoli: specifiche aperte, regole riutilizzabili, benchmark pubblici e modelli open weight. Per la sicurezza applicativa, dove costi, privacy e continuità dei controlli contano quanto le prestazioni, è una direzione più concreta dell’ennesima promessa affidata a un LLM generalista.