AiSOC è un Security Operations Center (SOC) open source, installabile sui propri server e rilasciato con licenza MIT. Raccoglie i log, li correla in incidenti e li fa analizzare da agenti AI che registrano ogni prompt e ogni chiamata a uno strumento. Al 31 ottobre 2026 il repository conta 5.489 stelle, 561 fork e 19 contributor.

Cos'è un SOC e come funziona AiSOC

Un SOC somiglia alla sala operativa di un istituto di vigilanza. Arrivano segnalazioni da firewall, computer aziendali, servizi cloud e sistemi di accesso. Gli analisti decidono quali sono minacce vere e quali rumore di fondo. Il collo di bottiglia è il triage, cioè lo smistamento degli allarmi, un lavoro ripetitivo che gli strumenti AI promettono di alleggerire. AiSOC prova a fare proprio quel pezzo, in locale e con il codice leggibile da chiunque.

Installazione e requisiti

Il progetto è nato il 2 maggio 2026 sull'account GitHub di Beenu Arora, CEO e cofondatore di Cyble, azienda che si occupa di threat intelligence e monitoraggio del dark web. Il file dei crediti conferma che Cyble paga il lavoro di sviluppo. Il 31 ottobre è uscita la versione 20.4.0.

Provalo subito gratis e senza account. Servono Docker Compose v2 con 8 GB di memoria e 20 GB di disco liberi, poi basta make up dopo il clone. Non ha Docker? Il simulatore offline si prova con pip install aisoc-sandbox.

Funzionalità di AiSOC

AiSOC prende la telemetria dei tuoi strumenti di sicurezza, la normalizza, applica un insieme di regole di rilevamento, raggruppa gli allarmi in incidenti e affida l'indagine a un agente AI che propone una risposta, da approvare a mano. Il README descrive il percorso con numeri precisi.

Il motore esegue 2.530 regole di una libreria da 7.015, più 76 regole a finestra mobile (73 contano gli eventi, 3 seguono una sequenza ordinata). Sopra mette le regolazioni del singolo cliente, quindi una regola disattivata dalla console smette davvero di scattare. Quando arriva nuova threat intelligence, il sistema ripassa lo storico già raccolto per cercare tracce passate. Un'ipotesi dell'analista diventa una ricerca senza scrivere una query. Il modello compila uno schema chiuso e ogni valore entra come parametro, perciò non può esprimere una query a modo suo.

Requisiti di sistema

Il profilo base richiede Docker Compose v2 con 8 GB di memoria e 20 GB di disco liberi nella macchina virtuale di Docker, più circa 2 GB da scaricare per il modello locale. Il progetto indica tre profili:

Profilo Full: make up-full, 22 servizi, circa 12 GB di memoria
Profilo Demo: make up && make demo, 16 servizi, circa 8 GB di memoria
Profilo Base: make up, 16 servizi, circa 8 GB di memoria

Il modello incluso è un Llama 3.2 da 3 miliardi di parametri quantizzato, servito da Ollama. Scelta pragmatica, pensata per la sola CPU, ma lontana da un modello di frontiera: su 50 alert il progetto ha misurato 44 risposte utilizzabili prima di vincolare l'output al formato JSON e 50 dopo.

Come ragiona l'agente e chi lo controlla

Ogni passo dell'agente finisce nell'Investigation Ledger, un registro che conserva prompt, chiamate agli strumenti, citazioni, verdetto, costo in token. Un'indagine si esporta come bundle firmato, identico byte per byte; chi la riceve può rifare il percorso senza fidarsi del riassunto. È la parte più convincente del progetto, perché risponde alla domanda che ogni responsabile della sicurezza fa a un sistema AI, cioè su quali prove ha deciso.

Le difese stanno attorno al modello. Un verdetto che cita un indicatore mai comparso nelle prove viene declassato a revisione umana invece di chiudere l'allarme. I prompt vengono validati prima dell'invio e log grezzi o valori che sembrano segreti vengono rifiutati, non ripuliti dopo. Nessun fornitore esterno viene toccato senza un umano, a meno che il cliente non abbia concesso autonomia per quella specifica azione. Chi approva non può essere la persona che l'ha richiesta.

I playbook, le sequenze di risposta automatica, partono in anteprima. Servono tre interruttori d'accordo (installazione, cliente, singolo playbook) e tutti e tre sono spenti di default; una richiesta di approvazione sospende l'esecuzione su Postgres, sopravvive a un riavvio e scade con un esito registrato invece di restare appesa.

Limiti e considerazioni

I conteggi (2.530 regole eseguibili, 87 connettori) li fa il progetto sul proprio albero di codice, senza che nessun terzo li abbia rifatti. "Eseguibile" significa che la regola scatta su un evento di prova, non che riconosca un attacco vero, come precisa il README stesso.

Nessun provider ospitato è mai stato messo alla prova, perché al progetto manca una chiave a pagamento. Se collegherai un modello commerciale, accuratezza e costi per modello restano "non misurati" nelle tabelle del progetto.

Non risulta una recensione indipendente né un audit di sicurezza esterno. Le 5.489 stelle in sei mesi misurano attenzione, non installazioni in produzione. La numerazione corre: l'audit interno del 23 settembre si riferiva alla versione 8.1.0, il 31 ottobre si è arrivati alla 20.4.0. Un numero di versione alto qui non dice nulla sulla maturità.

Quando l'agente di triage viene ingannato

Il 27 maggio 2026 un ricercatore, segnalando il problema numero 220, ha mostrato che un'iniezione di prompt (testo ostile nascosto nei dati, scritto per dare ordini al modello) negli agenti di classificazione poteva far chiudere in automatico un allarme. La correzione, con sanificazione dei prompt e contenuto non fidato racchiuso a parte, è arrivata il giorno dopo, in meno di 15 ore.

Il dettaglio importa più del tempo di risposta. In un SOC il testo che l'attaccante controlla è ovunque (il nome di un file, l'user agent di una richiesta, il messaggio di un commit) e un agente che legge quei campi li prende per input. Chi valuta uno strumento del genere deve chiedere come tratta il testo ostile, prima ancora di quanti allarmi chiude.

L'audit scritto contro se stesso

Il progetto pubblica una verifica interna di ciò che funziona davvero, datata 23 settembre 2026. Ammette che la guida d'avvio di allora portava a un compose senza servizio di ingestione né di fusione, dove la console si riempiva con 15 incidenti inventati scritti direttamente nel database, quindi chi seguiva il README vedeva una piattaforma viva senza averla mai eseguita. Il modulo di analisi del comportamento degli utenti (UEBA) leggeva un canale Kafka che nessuno alimentava; un componente classificato come codice morto, poi, era in uso.

Tutto risulta corretto nelle versioni successive. Resta un'autodichiarazione, ma scrivere nero su bianco che il quick start non provava nulla non è una mossa da vetrina. Rende il README più credibile di quello tipico da sala stampa.

Chi paga e che cosa resta gratuito

Secondo i crediti, Cyble finanzia le ore di ingegneria e rilascia tutto sotto licenza MIT. Il progetto è open source e gratuito, ma per funzionalità avanzate potrebbe essere necessario collegare modelli commerciali, con costi aggiuntivi.