KaliBench: il divario tra LLM e operatività cyber reale — perché i modelli faticano ancora con la CLI

L'entusiasmo per i Large Language Models applicati alla cybersecurity ha toccato picchi notevoli negli ultimi diciotto mesi. Dalle demo di analisi log automatizzata alla generazione di regole SIEM, la narrazione dominante dipinge gli LLM come copiloti pronti a sgravare l'analista da task ripetitivi. Ma quando si passa dalla prova su benchmark accademici all'operatività quotidiana su una console Kali Linux, la realtà si fa più granulare — e meno permissiva.

È qui che si inserisce KaliBench, un benchmark presentato su arXiv il 1° ottobre 2026 che sposta il focus dalla "conoscenza" alla "eseguibilità". Non misura se il modello sa cos'è Nmap o come funziona un handshake TLS, ma se riesce a generare il comando esatto, flag per flag, argomento per argomento, che un terminale accetterà senza errori di sintassi, binding errati o ordinamento sbagliato degli argomenti (KaliBench: A Fine-Grained Benchmark for Cybersecurity Tool Use on Kali Linux with Runtime-Free Verifiable Rewards).

Il benchmark: 8.504 coppie query-comando, 1.642 tool, 23 dimensioni

KaliBench non è un dataset sintetico. È stato costruito tramite una pipeline "manuscript-grounded" che parte da documentazione ufficiale, manuali e casi d'uso reali per produrre coppie natural-language → CLI command deterministiche. Il risultato: 8.504 voci che coprono 1.642 tool distinti su Kali Linux, organizzate in 23 capability dimensions (ricognizione, scanning, exploitation, post-exploitation, reporting, ecc.) e 5 fasi operative del ciclo di vita della sicurezza (KaliBench: A Fine-Grained Benchmark for Cybersecurity Tool Use on Kali Linux with Runtime-Free Verifiable Rewards).

La novità metodologica sta nella canonicalizzazione deterministica e nella valutazione alias-aware: due comandi semanticamente equivalenti ma sintatticamente diversi (es. nmap -sS 192.168.1.0/24 vs nmap --syn-scan 192.168.1.0/24) vengono normalizzati a una forma canonica prima del confronto. Questo elimina l'ambiguità che affligge i benchmark basati su LLM-as-judge.

Per garantire che i comandi siano davvero eseguibili, gli autori hanno sviluppato una pipeline di verifica a tre stadi: validazione basata su LLM, esecuzione in sandbox su terminale reale, e raffinamento human-in-the-loop. Solo i comandi che superano tutti e tre i livelli entrano nel ground truth.

Risultati: il muro del 42%

La valutazione ha coperto 24 configurazioni tra modelli general-purpose e security-focused, tutti open-weight. In setting "unrestricted" (nessun hint su quale tool usare), nessun modello supera il 42% di exact-command accuracy (KaliBench: A Fine-Grained Benchmark for Cybersecurity Tool Use on Kali Linux with Runtime-Free Verifiable Rewards).

Il dato è significativo: anche i modelli più capaci falliscono nella maggioranza dei casi quando serve precisione chirurgica su interfacce a riga di comando. Gli errori tipici non sono concettuali ("sbaglia il tool") ma sintattici: flag mancanti, valori scambiati, quoting errato, escape di caratteri speciali. In un contesto operativo, ciascuno di questi errori richiede intervento umano, annullando il guadagno di automazione.

La difficoltà emerge anche confrontando le tre modalità di valutazione: tool selection only, argument construction only, e full command. Il collo di bottiglia si sposta a seconda del modello, ma la composizione end-to-end rimane il tallone d'Achille trasversale.

Dalla diagnosi alla cura: verifiable rewards per il fine-tuning

KaliBench non si ferma alla misurazione. La sua architettura a segnali deterministici e riproducibili abilita runtime-free verifiable rewards per l'addestramento. Gli autori dimostrano che supervised fine-tuning (SFT) e reinforcement learning (RL) con reward derivati da KaliBench migliorano significativamente un modello da 8B parametri, portandolo a competere con modelli ben più grandi (KaliBench: A Fine-Grained Benchmark for Cybersecurity Tool Use on Kali Linux with Runtime-Free Verifiable Rewards).

Il concetto chiave è "runtime-free": i reward non richiedono esecuzione live durante l'addestramento (costosa, lenta, non deterministica). La canonicalizzazione e la verifica offline forniscono un segnale di qualità preciso, denso e calcolabile a costo marginale quasi nullo. Questo apre la strada a cicli di miglioramento continuo su dataset operativi reali, senza la necessità di sandbox persistenti nel loop di training.

Implicazioni per le operation di sicurezza italiane

Per i SOC e i team di incident response italiani, il messaggio è duplice. Primo: integrare LLM "out-of-the-box" in playbook automatizzati che invocano CLI reali espone a tassi di errore operativamente inaccettabili. Un comando tcpdump malformato può significare traffico non catturato durante un incidente; un msfconsole con payload sbagliato può far fallire una validazione di vulnerabilità.

Secondo: la via percorribile non è attendere modelli più grandi, ma specializzare modelli medi (8-13B) su dati operativi verificati. L'approccio KaliBench — SFT + RL con verifiable rewards — è replicabile internamente: ogni organizzazione può costruire il proprio "KaliBench interno" partendo da runbook, ticket storici e documentazione tool-specifica, per poi addestrare modelli che parlano il dialetto CLI del proprio stack.

C'è un parallelo interessante con l'efficienza di fine-tuning. Lavori recenti come TACO (Ternary Absolute-max Column-wise One-sparse Optimizer) mostrano come ridurre la memoria dell'ottimizzatore di 174× rispetto ad AdamW 8-bit, abilitando full-parameter fine-tuning di modelli 30-32B su singola GPU H100 80GB (TACO: Ternary Absolute-max Column-wise One-sparse Optimizer for LLM Fine-Tuning). Combinare ottimizzatori memory-efficient con dataset verificati come KaliBench rende l'adattamento domain-specific accessibile anche a team senza cluster dedicati.

Oltre la CLI: il pattern generale della "executable correctness"

Il problema evidenziato da KaliBench non è unico alla cybersecurity. Emerge ovunque un LLM debba produrre output soggetti a validazione formale stretta: query SQL, configurazioni Infrastructure-as-Code, pipeline CI/CD, query PromQL/Grafana. In tutti questi domini, l'accuratezza semantica non basta — serve eseguibilità garantita.

La lezione metodologica di KaliBench è trasferibile: definire una forma canonica, costruire verificatori deterministici, usare i loro segnali come reward. Questo sposta il paradigma da "il modello ragiona bene" a "il modello produce artefatti validi", che è l'unica metrica che conta in produzione.

Per AegisCore e l'ecosistema cyber italiano, l'opportunità sta nel trattare i benchmark come KaliBench non come paper accademici, ma come specifiche di accettazione per l'adozione di LLM in ambienti regolati e ad alta affidabilità. La prossima frontiera non è il modello più grande, ma il dataset di verifica più rappresentativo del proprio contesto operativo.