Nano-analyzer

Uno scanner minimalista per vulnerabilità zero-day basato su LLM, creato da AISLE.

Prototipo di ricerca a scopo dimostrativo. Si tratta di un semplice harness a file singolo in grado di rilevare reali vulnerabilità zero-day. Tieni presente che è un prototipo, orientato verso bug di sicurezza della memoria in C/C++, e produrrà falsi positivi. Lo condividiamo così com'è nello spirito della ricerca aperta — aspettati spigoli vivi.

Cosa fa

Nano-analyzer è un semplice scanner Python a file singolo che invia codice sorgente attraverso un pipeline LLM a tre fasi:

1. Generazione del contesto — un modello scrive un briefing di sicurezza sul file: cosa fa, dove fluiscono dati non fidati, quali buffer esistono e quanto sono grandi.
2. Scansione delle vulnerabilità — lo stesso modello, alimentato con il contesto, cerca bug zero-day funzione per funzione e produce risultati strutturati.
3. Triage scettico — ogni risultato viene contestato su più round da un revisore scettico che può eseguire grep sul codebase per verificare (o confutare) le difese. Un arbitro prende la decisione finale.

I risultati vengono salvati come file Markdown e JSON per la revisione umana.

Limitazioni attuali

Questo è un prototipo v0.1. Tieni presente quanto segue:

• Orientamento C/C++. I prompt, gli esempi few-shot e le euristiche sono fortemente ottimizzati per vulnerabilità di sicurezza della memoria in C/C++ (buffer overflow, dereferenze NULL, integer overflow, type confusion). Scansionerà altri linguaggi, ma è molto meno efficace.
• Falsi positivi. Anche con triage multi-round, aspettati risultati che non reggono a un esame più attento. Verifica sempre manualmente.
• Falsi negativi. Lo scanner potrebbe perdere intere classi di vulnerabilità — bug logici, race condition, problemi crittografici, bypass di autenticazione, ecc. Una scansione pulita non significa che il codice sia sicuro.
• Analisi a file singolo. Ogni file viene scansionato indipendentemente. Le vulnerabilità cross-file che dipendono da interazioni tra unità di compilazione verranno probabilmente perse.
• Dipende dall'LLM. I risultati variano a seconda del modello utilizzato. Modelli diversi troveranno cose diverse e allucineranno falsi positivi diversi.

Configurazione

Requisiti

• Python 3.8+
• Una chiave API OpenAI (per modelli OpenAI) o una chiave API OpenRouter (per altri provider)
• Opzionale: ripgrep (rg) per ricerche grep durante il triage
• Opzionale: Google codesearch (csearch/cindex) per grep più veloce su repository grandi

Installazione

git clone https://github.com/weareaisle/nano-analyzer.git
cd nano-analyzer
# Non è necessaria installazione di dipendenze. Esegui direttamente:
python3 scan.py --help

Chiavi API

Imposta la tua chiave API come variabile d'ambiente:

# Per modelli OpenAI (nomi di modello senza barra, es. "gpt-5.4-nano"):
export OPENAI_API_KEY=sk-...

# Per modelli OpenRouter (nomi di modello con barra, es. "qwen/qwen3-32b"):
export OPENROUTER_API_KEY=sk-or-...

Lo scanner determina quale chiave utilizzare in base al nome del modello: se contiene una /, instrada attraverso OpenRouter; altrimenti utilizza direttamente l'API OpenAI.

Utilizzo

Scansione base

# Scansiona un singolo file
python3 scan.py ./path/to/file.c

# Scansiona una directory ricorsivamente
python3 scan.py ./path/to/src/

Opzioni comuni

# Usa un modello diverso
python3 scan.py ./src --model gpt-5.4

# Controlla il parallelismo
python3 scan.py ./src --parallel 30

# Indica al triage grep la radice completa del repository (utile quando si scansiona una sottodirectory)
python3 scan.py ./lib/crypto/ --repo-dir ./

# Mostra solo risultati ad alta confidenza
python3 scan.py ./src --min-confidence 0.7

# Più round di triage per maggiore accuratezza (default: 5)
python3 scan.py ./src --triage-rounds 7

Tutti i flag

Output

I risultati vengono salvati in ~/nano-analyzer-results/<timestamp>/ (o --output-dir):

<timestamp>/
├── summary.json              # riepilogo della scansione leggibile da macchina
├── summary.md                # riepilogo della scansione leggibile da umano
├── <filename>.md             # output grezzo dello scanner per file
├── <filename>.context.md     # briefing di contesto per file
├── <filename>.json           # dati completi dei risultati per file
├── triages/                  # ragionamento dettagliato del triage
│   └── T0001_<file>_<title>.md
├── findings/                 # risultati sopravvissuti al triage
│   └── VULN-001_<file>.md
├── triage.json               # tutti i verdetti del triage
└── triage_survivors.md       # riepilogo dei risultati convalidati

Come funziona il triage

Quando una scansione trova un problema di gravità media o superiore, il pipeline di triage si attiva:

1. Un revisore scettico esamina il risultato confrontandolo con il codice effettivo e può eseguire grep sul codebase per verificare o confutare le difese dichiarate.
2. Questo si ripete per più round (default: 5), con ogni revisore che vede gli argomenti precedenti e viene incoraggiato a trovare nuove prove piuttosto che ripetere vecchi punti.
3. Un arbitro finale legge tutti i round e prende una decisione VALIDO/NON VALIDO.
4. Il punteggio di confidenza (es. 80% [VVIVV→V]) riflette la frazione di round che hanno detto VALIDO.

I risultati che sopravvivono al triage vengono scritti nella directory findings/ con catene complete di ragionamento.

Dichiarazione di non responsabilità

Questo strumento è un prototipo di ricerca. Non sostituisce audit di sicurezza professionali, revisione manuale del codice o strumenti di analisi statica consolidati. Non fare affidamento su di esso come unica valutazione della sicurezza. Utilizzalo a tuo rischio.

Licenza

Apache License 2.0