Risposta agli incidenti

# 1. Rilevamento e triage

Monitoriamo i segnali di sicurezza da:

• Avvisi di sicurezza di GitHub (GHSA) e segnalazioni private di vulnerabilità.
• Issue/discussioni pubbliche su GitHub quando le segnalazioni non sono sensibili.
• Segnali automatizzati (per esempio Dependabot, CodeQL, avvisi npm e scansione dei segreti).

Triage iniziale:

1. Confermare componente, versione e impatto sul perimetro di fiducia interessati.
2. Classificare come problema di sicurezza rispetto a rafforzamento/nessuna azione usando l'ambito e le regole di esclusione dall'ambito del repository SECURITY.md.
3. Un responsabile dell'incidente risponde di conseguenza.

# 2. Valutazione

Guida alla gravità:

• Critica: Compromissione di pacchetto/rilascio/repository, sfruttamento attivo o bypass non autenticato del perimetro di fiducia con controllo ad alto impatto o esposizione di dati.
• Alta: Bypass verificato del perimetro di fiducia che richiede precondizioni limitate (per esempio azione autenticata ma non autorizzata ad alto impatto), oppure esposizione di credenziali sensibili di proprietà di OpenClaw.
• Media: Debolezza di sicurezza significativa con impatto pratico ma sfruttabilità limitata o prerequisiti sostanziali.
• Bassa: Risultati di difesa in profondità, denial-of-service con ambito ristretto o lacune di rafforzamento/parità senza un bypass dimostrato del perimetro di fiducia.

# 3. Risposta

1. Confermare la ricezione al segnalatore (in privato quando sensibile).
2. Riprodurre sulle release supportate e sull'ultimo main, quindi implementare e convalidare una patch con copertura di regressione.
3. Per incidenti critici/alti, preparare le release corrette il più rapidamente possibile.
4. Per incidenti medi/bassi, correggere nel normale flusso di release e documentare le indicazioni di mitigazione.

# 4. Comunicazione

Comunichiamo tramite:

• Avvisi di sicurezza di GitHub nel repository interessato.
• Note di release/voci del changelog per le versioni corrette.
• Follow-up diretto con il segnalatore su stato e risoluzione.

Politica di divulgazione:

• Gli incidenti critici/alti devono ricevere divulgazione coordinata, con emissione di CVE quando appropriato.
• I risultati di rafforzamento a basso rischio possono essere documentati nelle note di release o negli avvisi senza CVE, a seconda dell'impatto e dell'esposizione degli utenti.

# 5. Ripristino e follow-up

Dopo aver distribuito la correzione:

1. Verificare le mitigazioni in CI e negli artefatti di release.
2. Eseguire una breve revisione post-incidente (cronologia, causa radice, lacuna di rilevamento, piano di prevenzione).
3. Aggiungere attività di follow-up per rafforzamento/test/documentazione e monitorarle fino al completamento.