Perché conta
La detection scatta. E adesso? Un’allerta senza una risposta preparata è panico in tempo reale: decisioni improvvisate, prove distrutte per sbaglio, tempi lunghi. La incident response (IR) è il piano che trasforma il caos in procedura. E in un mondo DevSecOps — infrastruttura immutabile, tutto automatizzato, artefatti verificabili — la risposta cambia forma rispetto all’IR tradizionale: si sfruttano proprio le proprietà che abbiamo costruito nei capitoli precedenti.
Le fasi, in breve
flowchart LR
PREP[Preparazione<br/>runbook, ruoli,<br/>accessi] --> DET[Rilevamento<br/>+ analisi]
DET --> CONT[Contenimento<br/>isola]
CONT --> ERAD[Eradicazione<br/>rimpiazza]
ERAD --> REC[Recupero]
REC --> LESS[Lezioni apprese<br/>postmortem]
LESS -.migliora.-> PREP
style CONT fill:#fde2e4,stroke:#e63946
Il modello NIST è un ciclo: ci si prepara prima, si rileva e analizza, si contiene, si eradica, si recupera, e si imparano le lezioni che migliorano la preparazione. La differenza DevSecOps sta in come si eseguono contenimento ed eradicazione.
Isola e rimpiazza, non riparare
Nell’IR classico si “ripuliva” un server compromesso. In un’infrastruttura immutabile è un errore: non sai cosa l’attaccante ha toccato, quindi non puoi fidarti di nessuna pulizia. Il modello cloud-native è diverso:
|
|
Il contenimento sfrutta la microsegmentazione: una network policy che taglia il pod dal resto del cluster lo ferma senza distruggere le prove. L’eradicazione sfrutta gli artefatti firmati e immutabili: si ridistribuisce una versione pulita verificabile, con la certezza di cosa contiene.
La provenienza come bussola forense
Durante l’analisi, le proprietà costruite prima diventano strumenti d’indagine. La SBOM dice esattamente cosa girava nell’immagine compromessa. La provenienza SLSA dice da quale commit e quale build proveniva. Gli audit log a prova di manomissione danno la timeline. La domanda “cosa è stato toccato?” — che senza questi dati richiede settimane — diventa una serie di query.
Automazione: contenere alla velocità della macchina
Gli attacchi automatizzati vanno più veloci di un umano. Per i casi ad alta confidenza, il contenimento può essere automatico (SOAR): la detection “pod che esfiltra dati” innesca da sola l’isolamento del pod, poi avvisa gli umani. L’automazione compra i minuti che contano, con la stessa cautela dell’enforce nella runtime security: solo su segnali affidabili, per non isolare servizi sani a un falso positivo.
Il blameless postmortem
La fase più trascurata e più preziosa. Dopo l’incidente, un postmortem senza colpevoli ricostruisce cosa è successo e perché i controlli non l’hanno fermato — non chi ha sbagliato. L’output non è una reprimenda ma azioni concrete: una regola di detection nuova, un gate più stretto, un controllo mancante aggiunto alla pipeline. È così che l’incidente alimenta il miglioramento invece di ripetersi, chiudendo il ciclo DevSecOps.
Domanda: il "blameless postmortem" non è un modo per non responsabilizzare nessuno? Se nessuno paga per l'errore, cosa impedisce che si ripeta?
È l'obiezione classica, e si basa su un'intuizione sbagliata su cosa previene la ripetizione degli errori. L'idea che la paura della colpa migliori la sicurezza è intuitiva ma smentita da decenni di pratica nelle industrie ad alto rischio, dall'aviazione alla medicina: la colpa non previene gli errori, li nasconde. Se sai che ammettere un errore ti costa, la tua reazione razionale non diventa "starò più attento", diventa "non lo segnalerò, non lascerò tracce, dirò che non so come sia successo". Il risultato è che perdi esattamente l'informazione che ti serve per correggere il sistema, e l'errore si ripete — solo che ora nessuno te lo dice finché non esplode di nuovo, più in grande. "Blameless" non significa "nessuna responsabilità": significa separare la responsabilità di capire e migliorare il sistema (collettiva, aperta, onesta) dalla ricerca di un capro espiatorio (che distrugge l'onestà senza aggiungere sicurezza). Il postmortem blameless parte da un presupposto preciso: le persone competenti fanno quasi sempre scelte sensate con le informazioni e gli strumenti che avevano in quel momento. Quindi se qualcuno ha fatto un errore, la domanda produttiva non è "perché quella persona è incompetente?" ma "perché il sistema ha permesso che quell'errore facile da fare arrivasse fino in produzione? dov'era il controllo che avrebbe dovuto intercettarlo?". Questo porta ad azioni concrete che prevengono davvero la ripetizione — un gate mancante, una detection assente, una procedura ambigua, un valore di default pericoloso — mentre "licenziamo il responsabile" lascia il sistema identico e pronto a far inciampare la prossima persona allo stesso modo. La responsabilità vera, in questo modello, è dare seguito alle azioni del postmortem: quello sì che va tracciato e preteso. Punire l'individuo è emotivamente soddisfacente e tecnicamente inutile; correggere il sistema è il contrario, ed è l'unico che riduce il tasso di incidenti nel tempo.
Conclusione
L’incident response DevSecOps isola e rimpiazza invece di riparare, usa SBOM, provenienza e audit log come bussola forense, automatizza il contenimento sui segnali affidabili e chiude con un postmortem blameless che migliora i controlli. Il piano trasforma il panico in procedura. Molto di ciò che abbiamo costruito — controlli, audit, procedure — deve anche dimostrarsi a un revisore o a un regolatore. Farlo senza fermare la consegna è la compliance as code, prossimo capitolo.