Sicurezza.

Nausika prende la sicurezza sul serio. Questa pagina è il punto di riferimento per ricercatori di sicurezza, sviluppatori di client AI e utenti collegati per capire come segnalare una vulnerabilità, quale risposta aspettarsi e cosa rientra o esce dallo scope. Il contatto leggibile da macchina è su /.well-known/security.txt.

Segnalare una vulnerabilità

Scrivi a [email protected] con il maggior dettaglio possibile: l'endpoint o lo strumento interessato, una procedura di riproduzione, l'impatto osservato e se ritieni che la falla sia sfruttabile in produzione. Confermiamo la ricezione di ogni segnalazione entro 2 giorni lavorativi.

Al momento non offriamo cifratura PGP. Invia email in chiaro e, se la segnalazione contiene materiale sensibile da non esporre in transito, ti contatteremo per concordare un canale sicuro. Non gestiamo un bug bounty a pagamento.

Per favore non testare vulnerabilità con modalità che degradano il servizio per altri utenti (denial of service, scansioni automatiche ad alta frequenza, tentativi di accesso ai dati di altri utenti). Se trovi un problema usando Nausika normalmente e lo scopri per caso, va bene — segnalalo.

SLA di risposta alla patch

La severità è valutata dal manutentore in dialogo con chi segnala, usando criteri di triage standard (ragionamento in stile CVSS, focalizzato sull'impatto reale per il modello di dati e la superficie di attacco di Nausika).

• Critica — esecuzione di codice remoto, bypass dell'autenticazione sull'endpoint MCP, esfiltrazione di dati cross-tenant, takeover di un account utente esistente: patch entro 7 giorni; hotfix su mcp.nausika.app lo stesso giorno quando possibile.
• Alta — escalation di privilegi (es. utente → admin), leak di dati sensibili (token OAuth, cookie di sessione), injection persistente (stored XSS nell'admin UI): patch entro 14 giorni.
• Media — denial of service tramite una singola chiamata, divulgazione di informazioni non personali, injection reflected: patch entro 30 giorni.
• Bassa — deviazioni dalle best practice senza exploit dimostrabile, hardening, problemi teorici: indirizzati in una release regolare, in genere entro 90 giorni.

Divulgazione coordinata

Preferiamo la divulgazione coordinata. Una volta confermata la vulnerabilità, chiediamo a chi segnala di trattenere la pubblicazione per almeno 30 giorni dalla conferma (o fino al rilascio della patch, a seconda di cosa arriva prima), così gli utenti collegati non sono esposti a sfruttamento in produzione prima che sia disponibile una correzione.

Daremo credito al segnalante su /log al momento della divulgazione, salvo richiesta contraria. Le segnalazioni anonime sono benvenute e le trattiamo con la stessa disciplina di triage delle altre.

Versioni supportate

Nausika è servita da un unico endpoint pubblico su mcp.nausika.app, costruito dall'ultima build di main. È supportata solo la versione attualmente in produzione; non ci sono branch di manutenzione paralleli né distribuzioni on-premise. Quando esce una patch, esce per tutti contemporaneamente.

Fork self-hosted o deployment non ufficiali sono fuori dallo scope dello SLA descritto sopra — il codice sorgente è privato e al momento non lo distribuiamo.

Fuori scope

• Vulnerabilità nei servizi di terze parti da cui dipendiamo — Railway, Cloudflare, Resend, GitHub OAuth, Google OAuth, Open-Meteo, NOAA, Wikimedia, OpenStreetMap. Segnala direttamente al fornitore upstream; se il problema riguarda come Nausika si integra con loro (es. un controllo redirect-URI mancante dalla nostra parte), allora rientra nello scope.
• Segnalazioni che richiedono accesso fisico al dispositivo dell'utente o un browser/OS compromesso, a meno che un comportamento specifico di Nausika non peggiori la situazione.
• Assenza di rate-limit su endpoint read-only sotto i limiti di servizio documentati — sono trattati come lavoro di performance, non come problemi di sicurezza.
• "Findings" da best-practice senza impatto dimostrabile (header di sicurezza mancanti su asset statici, version disclosure di librerie di terze parti che già aggiorniamo con cadenza regolare, ecc.) — li leggiamo e li valutiamo, ma non rientrano nello SLA sopra.

Cosa proteggiamo, in parole semplici

Il triage si basa su due classi distinte di asset:

• Dati utente — email dell'account, token OAuth, profilo barca, rotte salvate, valutazioni, preferiti, proposte inviate. Un accesso cross-tenant a uno qualsiasi di questi è trattato come critico.
• Dati pubblici curati — luoghi, attributi, metadati di attribuzione, immagini. Manomissioni che influenzano ciò che vedono gli altri utenti (es. scritture non autorizzate su places) sono trattate come alte; l'accesso in lettura è aperto per progetto.

Nausika non conserva dati di pagamento, dati sanitari, documenti d'identità o biometrici. Vedi Privacy per il modello completo dei dati e la policy di conservazione.

Posture di hardening

Per trasparenza: le cose che facciamo in modo continuo, non come reazione a singole segnalazioni.

• OAuth 2.1 con PKCE per i client pubblici; token bearer opachi conservati hashati nel database (nessun segreto JWT da far trapelare).
• Validazione anti-SSRF su ogni fetch da URL forniti dall'utente (image proxy, proposte di luoghi).
• Allow-list CORS rigorosa sull'endpoint MCP; vincolo same-origin sulle icone del connettore come da specifica MCP.
• Accesso al database esclusivamente tramite query parametrizzate (tagged template literals); nessuna SQL costruita per concatenazione di stringhe nel codice request-scoped.
• Conservazione di 90 giorni dei log completi delle richieste, 30 giorni dei log operazionali, pulizia automatica tramite job programmato. Vedi Privacy.
• Schema-version guard sul servizio MCP: il connettore pubblico si rifiuta di avviarsi contro un database più vecchio dello schema atteso, evitando deploy in stato incoerente.

Manutenzione e compatibilità all'indietro

Le patch di sicurezza richiedono a volte modifiche non retro-compatibili. Quando capita seguiamo le regole di preavviso descritte nella roadmap: 60 giorni di preavviso su /log per cambi di interfaccia non retro-compatibili, con l'eccezione di sfruttamento attivo, dove rilasciamo la correzione immediatamente e spieghiamo la modifica a posteriori.

L'impegno più ampio a mantenere Nausika — disponibilità del servizio, preavviso di chiusura, log pubblico — vive nella roadmap.