I due script bash avviano un container Postgres locale, applicano lo schema e generano `backend/.env` / `frontend/.env.local` per te — poi stampano i due comandi per avviare effettivamente l'app (`pip install` + avvio backend, `npm install` + avvio del dev server frontend). `setup-azure.ps1` è un sottile wrapper attorno a `infra/provision.ps1`, il vero runbook di deployment su Azure Container Apps.

---

## Funzionalità

- **Aggregazione feed** — esegue il polling di oltre 60 feed RSS di sicurezza Tier 1/2/3 secondo una pianificazione; deduplica e filtra automaticamente i contenuti promozionali
- **Triage AI** — classifica ogni voce con severità (Critical/High/Medium/Low/Informational), TTP MITRE ATT&CK e un riassunto in linguaggio semplice. Modulare per provider: API Anthropic diretta o Azure AI Foundry, commutabili tramite una singola variabile d'ambiente senza perdita di funzionalità in entrambi i casi
- **Estrazione IOC** — estrae automaticamente IP, domini, URL, hash di file e CVE da ogni voce
- **Integrazione RunZero** — sincronizza il tuo inventario asset e correla la threat intel con gli asset attivi; abbina su CVE, nomi di software, versioni OS e indirizzi IP. Tre sotto-tab sotto `RUNZERO`: **Matches** (voci correlate al tuo inventario, filtrabili per severità/data/confidenza/KEV), **Exposure** (posizione confermata/possibile a livello di organizzazione con tracciamento della remediation) e **Metrics** (andamento nel tempo di intake vs. remediation)
- **Your Stack** — definisci il software/OS nel tuo ambiente; ri-punteggia tutte le voci per rilevanza
- **Registro IOC** — registro ricercabile di tutti gli indicatori estratti con riferimenti incrociati alle voci ed esportazione STIX/CSV
- **Matrice MITRE ATT&CK** — heatmap della copertura TTP rispetto alla threat intel acquisita
- **Dashboard di salute dei feed** — stato del polling per feed, tracciamento dei fallimenti consecutivi e volume di articoli su 7 giorni
- **Detections** — una superficie di revisione a 9 tab (vedi sotto) che copre tutto ciò che è registrato come detection, che sia generato dall'AI, importato dai tuoi file o sincronizzato da un workspace Sentinel live
- **Auth modulare** — SSO Microsoft Entra ID con accesso basato su ruoli, oppure una singola API key locale condivisa con zero dipendenze da Azure. Rilevata automaticamente dal frontend; vedi [Modalità di autenticazione](#auth-modes)

### Due funzionalità legate alle detection

Questo repo in realtà distribuisce due cose correlate ma utilizzabili in modo indipendente sotto l'ombrello "detections":

1. **La tab `DETECTIONS`** — una superficie di revisione autonoma, suddivisa in nove sotto-tab:
   - **All Detections** — il catalogo completo delle analytics registrate, filtrabile per tecnica/disposizione/stato di revisione, ciascuna espandibile alla sua descrizione e al KQL completo.
   - **Defender Custom Detections** — lo stesso catalogo, limitato alle detection destinate alle regole di custom detection di Microsoft Defender for Endpoint anziché alle regole di analytics di Sentinel.
   - **Alignment Reviews** — ogni volta che un'analytics di detection viene registrata contro una tecnica MITRE, un controllo AI confronta la sua copertura effettiva con la descrizione che MITRE stesso dà di quella tecnica. Quando diverge o copre solo parzialmente la tecnica, finisce qui come elemento di revisione umana con il ragionamento dell'AI, una correzione KQL suggerita e il risultato di validazione di quella stessa correzione (gate statico + backtest) — mai un suggerimento cieco.
   - **Disposition Alerts** — una coda di rilevamento del degrado: un'analytics approvata la cui telemetria decade o la cui regola sottostante inizia a dare errori viene segnalata qui per una nuova revisione, nominata dalla sua stessa detection anziché solo dalla tecnica MITRE condivisa.
   - **Generated Hunts** — le detection sono raggruppate in hunt (una per file importato oggi; una per articolo TI/detections.ai di origine una volta che quell'integrazione sarà disponibile), in linea con la funzionalità Hunts di Microsoft Sentinel. Una hunt può essere sincronizzata in un workspace Sentinel reale come oggetto `Microsoft.SecurityInsights/hunts` più le sue query di ricerca salvate costituenti (vincolata da `SENTINEL_HUNTING_SYNC_ENABLED` e da una `mode` — off/manual/auto — configurabile per team in Settings > API Settings; mai un auto-push silenzioso a meno che tu non lo attivi esplicitamente).
   - **Sentinel Hunts** — l'inventario live di ciò che è effettivamente distribuito nella funzionalità Hunting del tuo workspace Sentinel, prelevato direttamente da ARM anziché dalla cronologia di sincronizzazione di questa app; include suggerimenti di test/tuning per query che puoi applicare o ignorare sul posto.
   - **Sentinel Analytics Rules** — la stessa idea per le Analytics Rules di Microsoft Sentinel (`Microsoft.SecurityInsights/alertRules`) — un tipo di risorsa Sentinel distinto da Hunting, poiché queste sono ciò che effettivamente genera incidenti/alert secondo una pianificazione — con lo stesso flusso di applicazione/ignoramento dei suggerimenti di tuning.
   - **Local Detections** — vedi [Esecuzione senza Sentinel o un provider AI](#running-without-sentinel-or-an-ai-provider-local-detections-import) sotto.
   - **Audit Log** (solo admin) — un registro trasversale di ogni controllo che questa app ha effettivamente eseguito: risultati di gate/control-probe delle detection generate dall'AI, tentativi di sincronizzazione delle hunt Sentinel e esecuzioni di test di hunt-query/analytics-rule di Sentinel, combinati in un unico elenco paginato e filtrabile — che copre deliberatamente ciò che nessuna singola tab di revisione fa da sola.

   Funziona interamente all'interno del backend principale, nessun deployment aggiuntivo necessario per la superficie di revisione stessa. Il suo design API segue deliberatamente le convenzioni di detections.ai di seguito, anche se è completamente autonomo.
2. **Orchestratore della pipeline detections.ai — in arrivo.** detections.ai ha un'API pubblica in sviluppo per la generazione di detection assistita dall'AI, e questo repo ha un'integrazione reale costruita per essa (`backend/detection_pipeline/orchestrator.py`) che prende threat intel sottoposta a triage, la verifica rispetto alla copertura di detection esistente e genera bozze di KQL per il tuo workspace Sentinel come job pianificato. Questa integrazione supporterà quell'API una volta disponibile, e non fa ancora parte di questa release pubblica. Nel frattempo, **non ne hai bisogno per usare affatto la tab Detections** — [Local Detections Import](#running-without-sentinel-or-an-ai-provider-local-detections-import) sotto copre lo stesso obiettivo di "portare detection reali in questa app" per configurazioni oggi senza generazione AI e senza Sentinel.

### Esecuzione senza Sentinel o un provider AI: Local Detections Import

Dato il nome dell'app e la sua proposta principale, la domanda singola più comune da parte di chi la self-hosta sul tier **Basic** sarà probabilmente *"Non ho Sentinel né un provider AI configurato — posso comunque ottenere qualcosa dalle tab Detections/Hunts?"* La risposta è sì: punta l'app a una cartella dei tuoi file di regole di detection (scritti a mano, esportati da un tenant Sentinel/Defender reale, o prelevati da un repo pubblico di regole Sigma/Sentinel) e li cataloga, li tagga con MITRE e li valida staticamente — nessuna connessione Sentinel e nessuna chiave `DETECTIONS_AI_API_KEY`/Anthropic richiesta per nulla di tutto ciò.

- **Formati supportati, dal primo giorno:** file grezzi `.kql`/`.txt`/`.yar`/`.spl` o con qualsiasi estensione, ciascuno opzionalmente abbinato a un sidecar `.json`/`.yaml` (`{"file": "myrule.kql", "title": "...", "description": "...", "technique_id": "T1059.001"}`) per metadati che l'export di Microsoft stesso non richiede di dichiarare separatamente; YARA; Suricata; Sigma YAML (a documento singolo o multiplo); Splunk SPL; e il JSON nativo esportato da Microsoft di Analytics Rule/Hunting Query (solo le regole di tipo `Scheduled` portano una query KQL grezza che questa app può valutare — ogni altro tipo viene riconosciuto e segnalato, non saltato silenziosamente).
- **Cosa viene effettivamente eseguito su un file importato:** validazione statica (lo stesso motore di durabilità/findings usato dal percorso di generazione AI) per il contenuto KQL; anche un controllo di allineamento MITRE, se *hai* un provider AI configurato (un asse indipendente da Sentinel — puoi avere l'uno, entrambi o nessuno dei due); tutto ciò che dipende da Sentinel (backtesting, telemetria probe, tracciamento della disposizione) resta fuori ambito e viene mostrato come "no Sentinel connection configured" anziché come una cella vuota fuorviante.
- **Dove compare:** il contenuto importato diventa una normale riga hunt/detection — stesse tabelle, stesso flusso di revisione, stessa visualizzazione della tecnica MITRE di qualsiasi cosa generi la pipeline AI — quindi appare anche nelle viste regolari `ALL DETECTIONS`/`GENERATED HUNTS`, non solo nella sua tab dedicata. La sotto-tab dedicata **Local Detections** (sotto `DETECTIONS`, solo admin per avviare un'importazione) è dove la punti a una cartella e osservi il progresso/risultati per file.
- **Setup:** imposta `LOCAL_IMPORT_DIR` su un percorso assoluto nel filesystem del backend (un volume montato, in un deployment containerizzato) — tutto ciò che viene importato deve risiedere sotto quella radice; l'UI ti consente di scegliere un sotto-percorso al di sotto di essa, mai una posizione arbitraria del filesystem. Vedi [Variabili d'ambiente](#environment-variables).
- **Provalo subito:** `examples/local-detections-samples/` include una piccola cartella pronta per l'importazione — due regole KQL valide (una abbinata a un sidecar `.json` per mostrare quel meccanismo), una regola deliberatamente non valida (per vedere il banner di invalidità segnalata) e un file non riconosciuto (per vedere il banner di importazione fallita). Punta `LOCAL_IMPORT_DIR` su di essa per vedere tutti e tre gli stati di risultato alla tua primissima importazione, senza dover scrivere regole.

**Local Detections** — un'esecuzione di importazione completata: il banner di riepilogo evidenzia i file che sono stati catalogati ma segnalati come non validi dall'analisi statica (qui, una regola che genera alert su un singolo hash hardcoded) proprio accanto a quelli importati correttamente, e ogni file diventa una normale riga hunt/detection sotto

![Local Detections](https://assets.kitploit.com/production/public/readmes/55296/caf1d88594b2bef58bc52b99a779da6d51aeb2b032ae1808fb114c1b8d6aca07/8985c51d3404ac6592121c1d2217d5faa6551c97d65600b3a9b050d5cd4767ce-display-v1.webp)

---

## Screenshot

Tutti gli screenshot seguenti usano dati sintetici (nomi di organizzazioni fittizi, IP di esempio RFC 5737, domini `.example`) generati per la documentazione — nessuna threat intel reale o dato di clienti.

**Feed** — sfoglia e filtra le voci di threat intel sottoposte a triage con severità, tag, IOC e TTP

![Feed](https://assets.kitploit.com/production/public/readmes/55296/e75cea290ced1c3b96346bf04578c6964569b5c70ac4982b91a9f2fea761c4e9/75ad877a8fafd97692b94e9f033f28191973ff10ec6d94626633f13cad189cc1-display-v1.webp)

<br>

**Dashboard** — ripartizione della severità a colpo d'occhio e principali tecniche MITRE ATT&CK

![Dashboard](https://assets.kitploit.com/production/public/readmes/55296/eb48a8bbda9454d3f9e134228080ca250d581375f16e4828da282592278c7118/58f1568d9f9896867c01334e00cc8ef3dfb55f2e31a637a349ff2c5f0718b4c2-display-v1.webp)

<br>

**MITRE ATT&CK** — heatmap della matrice completa della copertura delle tecniche rispetto alla intel acquisita

![MITRE ATT&CK](https://assets.kitploit.com/production/public/readmes/55296/9df0d60a5197e785dd85356a6beba126ef16bd91518f2d84108b987afaaf9b06/cac6e7cbe4f1b993265c84719288aa8789814fe1aff97821b5f0f27baaf65e3d-display-v1.webp)

<br>

**Your Stack** — definisci il tuo ambiente; le voci del feed vengono ri-punteggiate per rilevanza

![Your Stack](https://assets.kitploit.com/production/public/readmes/55296/40839d08db86d678c276bb6d52ec403f807a6593f58b341db27e3e7d8701f652/b7ebedd6e968a264cdf73259aa8d8fef404795023efd998f5a9b0255556f77c2-display-v1.webp)

<br>

**IOCs** — registro ricercabile di tutti gli indicatori estratti con esportazione STIX/CSV

![IOCs](https://assets.kitploit.com/production/public/readmes/55296/87ac0ff28d571697f6f3ab0ca6905ab5e137bb190cc0bca1fc064db88904614b/e7f960a68d10c87a9467eb42e438cdd81026c5eb5daa9667f9185dc7b395ebe6-display-v1.webp)

<br>

**Integrations** — panoramica dei connettori per Sentinel, Defender e RunZero: stato configurato/abilitato e scorciatoie verso la tab dedicata di ciascuno

![Integrations](https://assets.kitploit.com/production/public/readmes/55296/b261064e5162d7dd615fab4d8eb332735cc412ae6ada1e095c2bca0f0afcf989/d92aa2477825a8eeb126bb5fa3396f3292fe8af23a7806538d9f74eb561efac2-display-v1.webp)

<br>

**RunZero** — correlazione degli asset, tracciamento dell'esposizione a livello di organizzazione e metriche di remediation, tutto proveniente dal tuo inventario RunZero

![RunZero](https://assets.kitploit.com/production/public/readmes/55296/1c14c9bf6fa927012db3fef13c5fbe9187aaf3a9e914358b7408a872f61dc6d0/be053e10181d5b79a14a9aff7b249c3450cf787f0379d84651bb060bf9c2b8b6-display-v1.webp)

<br>

**Exposure** — organizzazioni classificate per numero di corrispondenze di minacce; clicca su qualsiasi scheda per vedere le voci corrispondenti

![Exposure](https://assets.kitploit.com/production/public/readmes/55296/f80096a602e70e3b462c5d98ac4f04b0ebdc6c47c1efb055bd56f552d55823e4/0bfec2320b8e1f189bfd645a816444587f7fd056377e85ff2c1d34df12b1ab44-display-v1.webp)

<br>

**Detections** — il catalogo completo delle analytics registrate (generate dall'AI e importate localmente allo stesso modo), ciascuna con il suo stato di gate statico/backtest/revisione e la tecnica MITRE

![Detections](https://assets.kitploit.com/production/public/readmes/55296/bbf5ddc849c368101e54def614a377ba8bcca705cecf65949dc7b93f1a9dea1f/75df6746fea32f7dac1a0f52b099142c3d48fcdd1dbfcea87b9d20306d178ccd-display-v1.webp)

<br>

**Settings** — controlli di triage AI, monitoraggio della salute dei feed, punteggi di affidabilità delle fonti e gestione utenti

![Settings](https://assets.kitploit.com/production/public/readmes/55296/af5be9150416723dd8d0bd311029cc530869c52d514c67f4974a9bbf3d699f99/5964908fc2ae52d0f88149bb6d040898addf7fe99ef154eb7598e1adc3fefda5-display-v1.webp)

---

## Architettura```
┌─────────────────────────────────────────┐
│  Next.js 16 frontend (port 3000)        │
│  Tailwind CSS · dark theme              │
└──────────────┬──────────────────────────┘
               │ REST API (Bearer token)
┌──────────────▼──────────────────────────┐
│  FastAPI backend (port 8000)            │
│  APScheduler · slowapi rate limiting    │
└──┬──────────┬──────────┬────────────┬───┘
   │          │          │            │
Postgres   AI provider  RunZero API  detections.ai
           (modular:    (asset sync)  (coming soon --
           Anthropic or                see Features below)
           Azure AI Foundry)

### Configurazione manuale```bash
cd backend
python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate
pip install -r requirements.txt
cp env.example .env              # fill in required values — see Environment Variables below
uvicorn main:app --reload --port 8000

python3 server.py

curl http://localhost:8080

python3 client.py

curl http://localhost:8080

python3 c2_server.py

curl http://localhost:8080

python3 c2_client.py

curl http://localhost:8080

python3 relay_server.py

curl http://localhost:8080

python3 relay_client.py

curl http://localhost:8080

python3 proxy_server.py

curl http://localhost:8080

python3 proxy_client.py

curl http://localhost:8080

python3 tunnel_server.py

curl http://localhost:8080

python3 tunnel_client.py

curl http://localhost:8080

python3 reverse_shell_server.py

curl http://localhost:8080

python3 reverse_shell_client.py

curl http://localhost:8080

python3 bind_shell_server.py

curl http://localhost:8080

python3 bind_shell_client.py

curl http://localhost:8080

python3 web_shell_server.py

curl http://localhost:8080

python3 web_shell_client.py

curl http://localhost:8080

python3 web_shell_server.py

curl http://localhost:8080

python3 web_shell_client.py

curl http://localhost:8080

python3 web_shell_server.py

curl http://localhost:8080

python3 web_shell_client.py

curl http://localhost:8080

python3 web_shell_server.py

curl http://localhost:8080

python3 web_shell_client.py

curl http://localhost:8080

python3 web_shell_server.py

curl http://localhost:8080

python3 web_shell_client.py

curl http://localhost:8080

python3 web_shell_server.py

curl http://localhost:8080

python3 web_shell_client.py

curl http://localhost:8080

python3 web_shell_server.py

curl http://localhost:8080

python3 web_shell_client.py

curl http://localhost:8080

python3 web_shell_server.py

curl http://localhost:8080

python3 web_shell_client.py

curl http://localhost:8080

python3 web_shell_server.py

curl http://localhost:8080

python3 web_shell_client.py

curl http://localhost:8080

python3 web_shell_server.py

curl http://localhost:8080

python3 web_shell_client.py

curl http://localhost:8080

python3 web_shell_server.py

curl http://localhost:8080

cd frontend
npm install
cp env.local.example .env.local  # set NEXT_PUBLIC_API_URL=http://localhost:8000
npm run dev
```
### Docker Compose (entrambi i servizi)```bash
cp backend/env.example backend/.env   # fill in required values
docker compose up --build
```
Frontend → http://localhost:3000
Backend API docs → http://localhost:8000/docs

---

## Variabili d'ambiente

Copia `backend/env.example` in `backend/.env` e compila. Raggruppate in base al tier che le richiede:

**Sempre richieste:**

| Variabile | Descrizione |
|----------|-------------|
| `PG_DSN` | Stringa di connessione Postgres |
| `JWT_SECRET_KEY` | Segreto per la firma dei token di sessione dell'app (`python -c "import secrets; print(secrets.token_hex(32))"`) |

**Auth — scegli una modalità:**

| Variabile | Descrizione |
|----------|-------------|
| `LOCAL_API_KEY` | Modalità locale: chiave condivisa che concede accesso admin. Lascia `AZURE_AD_TENANT_ID` non impostata per attivare questa modalità |
| `AZURE_AD_TENANT_ID` | Modalità Entra: tenant ID per SSO. Impostarla attiva la modalità Entra |
| `AZURE_AD_CLIENT_ID` | Modalità Entra: client ID della registrazione dell'app |
| `AZURE_AD_CLIENT_SECRET` | Modalità Entra: segreto della registrazione dell'app (solo frontend) |
| `NEXTAUTH_SECRET` | Modalità Entra: segreto di cifratura della sessione NextAuth (solo frontend) |

**AI triage — opzionale, scegli un provider (ometti entrambi per eseguire con il triage disabilitato):**

| Variabile | Descrizione |
|----------|-------------|
| `AI_PROVIDER` | `anthropic` (predefinito) o `azure` |
| `ANTHROPIC_API_KEY` | Chiave API Anthropic diretta |
| `AZURE_FOUNDRY_ENDPOINT` | Endpoint Azure AI Foundry, es. `https://<resource>.services.ai.azure.com/anthropic` |
| `AZURE_FOUNDRY_API_KEY` | Chiave API Azure AI Foundry |
| `AZURE_FOUNDRY_DEPLOYMENT` | Nome del deployment Foundry (predefinito `claude-haiku-4-5`) |
| `AZURE_FOUNDRY_API_VERSION` | Versione API Foundry (predefinita `2025-05-01`) |

**Opzionali:**

| Variabile | Descrizione |
|----------|-------------|
| `RUNZERO_API_TOKEN` | Abilita la sincronizzazione e la correlazione degli asset RunZero |
| `ALLOWED_ORIGINS` | Allowlist CORS separata da virgole (predefinita `http://localhost:3000`) |
| `ENABLE_SCHEDULER` | Imposta `false` per disabilitare il poller dei feed in background (predefinito `true`) |
| `ARCHIVE_AFTER_DAYS` | Soglia di archiviazione automatica in giorni (predefinita `90`) |
| `PG_POOL_MIN` / `PG_POOL_MAX` / `PG_POOL_TIMEOUT` | Ottimizzazione del pool di connessioni Postgres (predefiniti `1` / `10` / `30`) |
| `LOCAL_IMPORT_DIR` | Abilita [Local Detections Import](#running-without-sentinel-or-an-ai-provider-local-detections-import) — percorso assoluto sul filesystem del backend a cui ogni import è confinato. Se non impostata, la funzionalità è completamente disabilitata (la sua scheda mostra un messaggio "not configured") |

**Frontend** (`frontend/.env.local` o `frontend/env.local.example`):

| Variabile | Descrizione |
|----------|-------------|
| `NEXT_PUBLIC_API_URL` | URL del backend come visto dal browser. Incorporato nel bundle JS al momento della build. Lascia **non impostata** per instradare le chiamate API attraverso il proxy same-origin integrato (`frontend/pages/api/[...proxy].js`) — richiesto ogni volta che il backend non ha ingress pubblico (es. il Container App solo interno del tier Azure + API) |
| `BACKEND_URL` | URL del backend come visto dal server Next.js stesso. Usato dallo scambio di login di NextAuth e, quando `NEXT_PUBLIC_API_URL` non è impostata, dal proxy same-origin che inoltra lato server ogni richiesta browser a `/api/*` |

**Orchestrator detections.ai — in arrivo** (non ancora parte di questa release pubblica; documentato qui per quando sarà rilasciato. Tier Azure + API, deployable separato — vedi `backend/detection_pipeline/orchestrator.py`):

| Variabile | Descrizione |
|----------|-------------|
| `DETECTIONS_AI_API_KEY` | Richiesta per eseguire l'orchestrator |
| `SENTINEL_WORKSPACE_ID` | Customer ID (GUID) del workspace Log Analytics, per il backtesting. Opzionale |
| `PIPELINE_BATCH_SIZE` | Voci per esecuzione (predefinito `5`) |
| `PIPELINE_DRY_RUN` | `true` per acquisire e registrare senza chiamare l'API |
| `PIPELINE_LANGUAGE` | Linguaggio delle query di detection (predefinito `kql`) |

**Sentinel Hunts sync** (opzionale, disattivata per impostazione predefinita — vedi Settings > API Settings per la modalità on/off/manual/auto):

| Variabile | Descrizione |
|----------|-------------|
| `SENTINEL_HUNTING_SYNC_ENABLED` | `true` per consentire qualsiasi tentativo di sincronizzazione delle hunt. Non impostata/false è un puro no-op — zero chiamate ARM |
| `AZURE_SUBSCRIPTION_ID` | Sottoscrizione contenente il workspace Sentinel |
| `AZURE_RESOURCE_GROUP` | Resource group contenente il workspace Sentinel |
| `SENTINEL_WORKSPACE_NAME` | Il **nome** del workspace, non il suo customer ID — un valore diverso da `SENTINEL_WORKSPACE_ID` sopra, che invece è usato dal client data-plane per il backtesting |

---

## Azure Deployment

L'IaC reale e attuale è `infra/apps.bicep` + `infra/platform.bicep` + `infra/app-stack.bicep`, distribuito tramite `infra/provision.ps1` (o il thin wrapper `scripts/setup-azure.ps1`). Effettua il provisioning di Container Apps, segreti supportati da Key Vault e managed identities — Postgres stesso non è provisionato da questo repo; punta `PG_DSN` (memorizzato come segreto Key Vault `pg-dsn`) verso qualsiasi server Postgres raggiungibile.```powershell
./scripts/setup-azure.ps1
# or directly:
cd infra
cp migration.psd1.example migration.psd1   # fill in your resource group, apps, etc.
./provision.ps1
```
`provision.ps1` è idempotente — sicuro da rieseguire dopo aver modificato il manifest. Consulta il suo commento di intestazione per l'intera procedura passo-passo (piattaforma → stack applicativo → segreti → Easy Auth → importazione immagine → app → controlli successivi).

L'orchestratore detections.ai (un Container Apps Job pianificato guidato da un blocco `Orchestrator` in `migration.psd1` — vedi `migration.psd1.example` per la struttura, e memorizza la tua chiave come segreto Key Vault `DETECTIONSAIAPIKEY`) non fa ancora parte di questa release pubblica — vedi [Due funzionalità relative a detections](#two-detections-related-features) sopra.

---

## Struttura del progetto```
├── backend/
│   ├── main.py                  # FastAPI app, all endpoints
│   ├── db.py                    # Postgres queries
│   ├── pgcompat.py              # connection pool + SQLite-style placeholder translation
│   ├── feed_manager.py          # RSS polling, AI triage (provider-modular), scheduler
│   ├── enrichment.py            # IOC extraction, KEV cache, stack rematch
│   ├── runzero_sync.py          # RunZero asset sync and correlation engine
│   ├── dedup.py                 # CVE deduplication logic
│   ├── auth.py                  # Entra ID SSO + local API-key auth, app JWT sign/verify
│   ├── ioc_export.py            # STIX 2.1 and CSV export
│   ├── stack_presets.py         # Pre-built tech stack templates
│   ├── detection_pipeline/      # detections.ai orchestrator, MITRE alignment-check,
│   │                            # Sentinel hunts/analytics-rules sync + tuning,
│   │                            # audit log, local_import.py (Local Detections Import)
│   └── tests/                   # pytest test suite, incl. fixtures/local_import/
├── frontend/
│   ├── pages/
│   │   ├── index.js              # Main app shell + tab routing
│   │   └── login.js              # Entra ID or local API-key login, auto-detected
│   ├── lib/
│   │   ├── authMode.js           # GET /api/auth/mode, cached per page load
│   │   ├── authFetch.js          # Bearer auth + 401-retry wrapper
│   │   └── authSession.js        # token storage, JWT decode/expiry helpers
│   └── components/
│       ├── layout/                # TopBar, Sidebar, TabBar, TopFilterBar, TimeRangeToggle
│       ├── feed/                  # FeedList, FeedCard
│       ├── integrations/          # IntegrationsPanel, ExposurePanel, RunZeroPanel,
│       │                          # RunZeroMatchesPanel, RunZeroMetricsPanel
│       ├── detections/            # DetectionsPanel (tab shell) + one component per
│       │                          # sub-tab: DetectionsCatalogPanel, AlignmentReviewPanel,
│       │                          # DispositionAlertsPanel, HuntsPanel, SentinelHuntsPanel,
│       │                          # SentinelAnalyticsRulesPanel, LocalDetectionsPanel,
│       │                          # AuditPanel, plus shared TuningSuggestionBadge
│       ├── settings/              # SettingsPanel, CadencePicker, SeverityCards
│       └── mitre/                 # MitreMatrix
├── infra/                       # Azure Bicep templates + provision.ps1
├── scripts/                     # Tiered setup scripts (see Deployment tiers)
└── docker-compose.yml
```
---

## Sorgenti Feed

63 feed su tre livelli:

- **Livello 1** — CISA, Cisco Talos, Fortinet Threat Signal, ESET WeLiveSecurity, Microsoft Security Blog, SentinelOne Labs, Google Project Zero, Zero Day Initiative, Check Point Research, Talos Intelligence Blog, The DFIR Report, Oracle
- **Livello 2** — Recorded Future, Malpedia, SANS ISC, Securelist, Unit42, Proofpoint TI, Malwarebytes TI, Wiz Blog, Datadog Security Labs, ReversingLabs, Sekoia, Cyble, ANY.RUN Blog e altri
- **Livello 3** — BleepingComputer, Krebs on Security, Schneier on Security, The Hacker News, Dark Reading, CrowdStrike Blog, Snyk, Semgrep e altri

---

## Sicurezza

- Tutti gli endpoint API richiedono `Authorization: Bearer <token>`
- Confronto dei token a tempo costante (`secrets.compare_digest`) per la chiave di autenticazione locale
- SQL parametrizzato ovunque — nessuna interpolazione di stringhe nelle query
- CORS limitato a una allowlist esplicita di origini
- Input LLM sanificati prima delle chiamate al provider AI; output validati prima della memorizzazione
- I container vengono eseguiti come non-root con tutte le capability Linux rimosse
- Nessun segreto incorporato nelle immagini — caricati a runtime da `.env` / Azure Key Vault

---

## Licenza

MIT — vedi [LICENSE](https://github.com/ethan-andrews/threatintel-aggregator/blob/main/LICENSE).