Deployment di CyberStrikeAI: anche gli strumenti semplici vanno installati curando i dettagli

Ultimamente mi sto cimentando con CyberStrikeAI, una piattaforma di security testing nativa AI scritta in Go. Pensavo che il “deployment in un clic” si riducesse a clonare la repo ed eseguire uno script, invece mi sono imbattuto in qualche insidia di media entità. Approfittando della memoria ancora fresca, racconto tutto il processo: molti problemi non dipendono dallo strumento, ma da dettagli trascurati.

Prima di tutto: cos'è questo strumento

CyberStrikeAI si presenta come un “sistema operativo per la cybersecurity nativa AI”, scritto in Go, che raccoglie pianificazione, esecuzione, supervisione umana, conservazione delle evidenze e replay in un'unica workbench auditabile. I componenti chiave comprendono agenti basati su Eino, strumenti MCP nativi, una knowledge base RAG, workflow visuali e analisi delle catene di attacco.

Include oltre 100 ricette di strumenti che coprono l'intera kill chain: scansione di rete con nmap, masscan e rustscan; scansione web con sqlmap, nikto, gobuster e ffuf; scansione delle vulnerabilità con nuclei, wpscan e dalfox; più enumerazione di sottodomini, sicurezza API, sicurezza di container e cloud, analisi binaria, exploit, cracking di password, forensics, post-exploitation e altro. Praticamente tutto il corredo necessario per un penetration test autorizzato, già orchestrato.

In più ci sono un plugin per Burp Suite e un'estensione browser per inviare direttamente il traffico catturato alla piattaforma per un'analisi assistita dall'AI. Un design intelligente: non ti costringe a cambiare il workflow esistente.

Preparazione dell'ambiente prima del deployment

I prerequisiti ufficiali sono due, attenti a non scendere sotto le versioni richieste:

• Go 1.25+(la versione richiesta esplicitamente nel go.mod; con versioni precedenti la compilazione fallisce subito)
• Python 3.10+(richiesto da alcuni strumenti, come api-fuzzer e http-framework-test)

Insidia numero uno: la versione di Go. La prima volta ho usato la vecchia versione di Go preinstallata nel sistema e l'errore è arrivato solo in fase di compilazione. Consiglio di go version verificare subito, e se la versione non basta installare quella nuova dal sito ufficiale. Questo tipo di “prerequisito” è il più trascurato, perché l'errore scoppia molto più avanti.

Deployment in un clic: cosa fa lo script per te

Il comando ufficiale per il deployment in un clic è essenziale:

git clone https://github.com/Ed1s0nZ/CyberStrikeAI.git
cd CyberStrikeAI
chmod +x run.sh && ./run.sh

Ma run.sh in realtà fa più cose di quanto pensiate, e le esegue in sequenza:

• ✅ Verifica e controlla l'ambiente Go e Python
• ✅ Crea l'ambiente virtuale Python
• ✅ Installa le dipendenze Python
• ✅ Scarica le dipendenze Go
• ✅ Compila il progetto
• ✅ Avvia il servizio

Dettaglio uno: la venv è gestita automaticamente dallo script. La directory venv/ viene creata e mantenuta da run.sh, e gli strumenti che richiedono Python (api-fuzzer, http-framework-test ecc.) usano automaticamente quell'ambiente. Non createne una a mano: rischia di generare conflitti.

Verifica dell'avvio: i punti da confermare

Al termine dello script, niente fretta di aprire il browser: prima guardate il terminale.

• verificate che il terminale mostri ● ONLINE, seguito dall'indirizzo effettivo della Web UI
• aprite quell'indirizzo: in modalità HTTPS predefinita viene usato un certificato self-signed locale, il browser darà un avviso, basta accettarlo una volta
• Le nuove installazioni hanno una password amministratore monouso: il terminale la mostra sotto ADMIN SETUP REQUIRED, cambiatela subito dopo il login

Dettaglio due: HTTPS o HTTP. run.sh si avvia per impostazione predefinita con il parametro –https (TLS self-signed locale; secondo l'ufficiale è più adatto ai flussi concorrenti). Se volete il solo HTTP dovete usare esplicitamente ./run.sh --http. Per l'avvio manuale, aggiungete –https o impostate la variabile d'ambiente CYBERSTRIKE_HTTPS=1.

In produzione niente certificati self-signed: configurate server.tls_cert_path e server.tls_key_path nel config.yaml.

Insidia numero due: l'errore di protocollo non corrispondente. Se nei log compare “client sent an HTTP request to an HTTPS server”, significa che qualche client sta ancora puntando http:// alla porta TLS. Basta correggere l'URL, non andate a toccare la configurazione del server.

Configurazione iniziale: il canale AI è obbligatorio

Senza questo passo, la piattaforma è come se non fosse installata. Dopo il primo avvio, visitate https://127.0.0.1:8080/ (la porta fa riferimento a server.port nel config.yaml) e entrate in System Settings → Basic Settings → AI Channel Configuration, aggiungete un canale e compilate provider, Base URL, API key, model e limite di token.

Potete anche modificare direttamente il config.yaml; il formato è più o meno questo:

ai:
default_channel: openai-main
channels:
openai-main:
provider: openai_compatible
api_key: “${OPENAI_API_KEY}”
base_url: “https://api.openai.com/v1”
model: “gpt-4o”

Dettaglio tre: l'ambito del canale predefinito. ai.default_channel vale per le nuove sessioni e per i task che non scelgono un canale esplicito; nella pagina di chat potete comunque selezionare per ogni sessione uno qualsiasi dei canali salvati. Quindi, se avete più modelli, non serve limitarsi a uno.

Con provider impostato su openai_compatible si collegano la maggior parte dei servizi compatibili con l'API OpenAI: basta cambiare base_url in https://api.deepseek.com/v1 e model in deepseek-chat, uguale per qwen3-max. Qualsiasi modello si aggancia, un punto davvero comodo.

⚠️ Avviso di sicurezza: non committate chiavi reali nel config.yaml. L'ufficiale è esplicito: niente credenziali vere nel repository, iniettatele tramite variabili d'ambiente.

Anche l'aggiornamento richiede metodo

Ufficiale offre uno script di upgrade in un clic, ma la prima volta bisogna concedere i permessi di esecuzione:

chmod +x upgrade.sh && ./upgrade.sh –yes

Cosa fa: backup di config.yaml e della directory data/ → scarica il nuovo codice dai GitHub Release → aggiorna il numero di versione in config.yaml → riavvia il servizio.Le directory locali tools/, roles/ e skills/ vengono sempre preservate: un punto cruciale, le vostre ricette di strumenti personalizzate non vengono sovrascritte.

Insidia numero tre: le dipendenze dello script di upgrade. Servono curl o wget per scaricare il pacchetto Release e rsync per una sincronizzazione sicura del codice (secondo l'ufficiale raccomandato/necessario). Se la GitHub API applica rate limit, prima export GITHUB_TOKEN="..." e poi rilanciate.

In caso di problemi si può ripristinare da .upgrade-backup/, oppure ricopiare manualmente data e config.yaml e rilanciare run.sh.

Regola fondamentale: prima di aggiornare, leggete sempre le release notes della versione di destinazione, con particolare cautela se cambiano configurazione, database o API. L'ufficiale lo dice senza sconti: “il backup è obbligatorio, anche per un semplice aggiornamento di patch; il numero di versione di per sé non garantisce la compatibilità”.

Panoramica della struttura delle directory

Capire a cosa serve ogni directory evita di perdersi nelle manutenzioni future:

• cmd/ — server, ingresso MCP stdio, strumenti
• internal/ — Agent, core MCP, handler, C2, executor di sicurezza
• web/ — SPA statiche e template
• tools/ — ricette strumenti YAML (100+ esempi)
• roles/ — configurazioni dei ruoli (12+ ruoli di security testing predefiniti)
• skills/ — directory Agent Skills (SKILL.md + file opzionali)
• agents/ — Markdown multi-agent (orchestrator.md + sub-agent)
• config.yaml — configurazione runtime
• run.sh / upgrade.sh — script di avvio / aggiornamento

La sicurezza non si delega allo strumento

La piattaforma integra capacità ad alto rischio come la gestione di WebShell e un C2 integrato (listener, beacon cifrati, sessioni, code di task). La posizione ufficiale è chiarissima:usabile solo su sistemi che possedete o su cui avete un'autorizzazione esplicita a testare.

Prima di abilitare strumenti ad alto rischio in ambienti condivisi o di produzione, leggete sempre il modello di sicurezza e la guida all'hardening. È incluso anche l'intercettamento delle chiamate agli strumenti: controlli regex configurabili prima dell'esecuzione MCP, con protezione dei domini governativi attiva per impostazione predefinita.

Inoltre, per impostazione predefinita il servizio ascolta solo su 127.0.0.1: se dovete esporlo all'esterno, eseguite prima l'hardening. Non è una formula di cortesia, è l'avvertimento di chi ha imparato a proprie spese.

Per concludere

Guardando indietro, il deployment in sé non ha dato grossi problemi: lo script aveva già fatto il 90% del lavoro. Ciò che mi ha davvero fatto fermare a consultare la documentazione sono stati tutti dettagli “non notati”: la soglia della versione di Go, la venv da non creare a mano, il HTTPS attivo per default che causa il mismatch di protocollo, il backup prima dell'upgrade, le chiavi da non mettere nella configurazione.

Presi singolarmente non sono dettagli difficili, ma se ne perdi uno puoi restare bloccato mezz'ora. Più lo strumento è maturo, più conviene “leggere la documentazione”: incapsula la complessità nello script, e la complessità residua si nasconde nei dettagli di configurazione.

Il progetto è entrato in knownsec 404Starlink ed è open source con licenza Apache 2.0. Se fate security testing autorizzato, vale la pena provarlo.

Deployment in un clic non significa comprensione in un clic: sono i dettagli la vera chiave per risparmiare tempo.

Indirizzo del progetto: github.com/Ed1s0nZ/CyberStrikeAI (migrato su github.com/AIPentest/CyberStrikeAI)
Requisiti d'ambiente: Go 1.25+ / Python 3.10+
Licenza: Apache License 2.0
⚠️ Solo per test autorizzati