In breve: un processo di patch management stabilisce come gli aggiornamenti procedono dall'arrivo alla prova: in quale classe rientra una patch, in quale finestra viene installata, come si testa e si torna indietro, chi riavvia e come si dimostra il successo. Gli aggiornamenti di routine seguono un ritmo pianificato, le patch d'emergenza una corsia rapida concordata in anticipo. Così gli interventi d'emergenza diventano una procedura ripetibile.
Quando ogni patch è un'emergenza
La sera del 21/10/2026 in molte aziende si è ripetuto lo stesso schema. Le patch erano disponibili, il BSI (l'Ufficio federale tedesco per la sicurezza informatica) sollecitava, e sono iniziate le domande: possiamo aggiornare subito? Chi testa? Chi riavvia i servizi? Chi avvisa la direzione che lo shop sarà fermo per poco? E come dimostriamo dopo che ha funzionato?
Nelle aziende senza processo tutto questo va chiarito sul momento. In quelle con un processo la risposta è già stabilita. La differenza non sta nella tecnica, ma negli accordi presi prima.
Gli elementi di un processo di patch management
Un processo sostenibile distingue innanzitutto quanto sia urgente una patch. Di solito bastano tre classi:
| Classe | Motivo tipico | Finestra | Test | Autorizzazione |
|---|---|---|---|---|
| Routine | correzioni di errori, aggiornamenti di sicurezza a basso rischio | appuntamento mensile fisso | staging, test standard | IT, secondo piano |
| Urgente | classificazione alta, sistema raggiungibile pubblicamente | anticipata a breve termine | abbreviato, processi principali | responsabile IT |
| Emergenza | falla critica, attacchi segnalati, ad es. PHP2Shell | subito | smoke test dopo l'installazione | autorizzazione d'emergenza concessa in anticipo |
Chi assegna quale classe dovrebbe essere stabilito tanto quanto i criteri. La valutazione appartiene al passaggio precedente, vedere Gestione delle vulnerabilità per le PMI.
È importante l'autorizzazione d'emergenza concessa in anticipo. La direzione decide una volta, con calma, che per le patch d'emergenza si può agire subito, anche se ciò comporta una breve interruzione. Nell'emergenza nessuno deve poi cercare un'approvazione di notte.
Altrettanto importanti sono i ruoli. Per ogni sistema dovrebbe essere stabilito chi installa gli aggiornamenti, chi testa dal punto di vista funzionale se shop o portale funzionano dopo, e chi viene informato. Per i sistemi esternalizzati, hoster e agenzia ne fanno parte espressamente, con nome e reperibilità. La finestra di manutenzione fissa dovrebbe essere nota internamente, così che vendite e assistenza clienti sappiano quando sono possibili brevi interruzioni.
Misuri inoltre quanto tempo richiede davvero il Suo processo: dalla pubblicazione di una patch alla chiusura documentata, distinto per classe. Questi valori propri mostrano dove si inceppa e rendono visibili i miglioramenti. Un processo di cui nessuno conosce la durata è difficile da governare.
Il percorso di una patch in otto passaggi
Ogni patch, di qualunque classe, attraversa le stesse tappe. Cambiano solo velocità e profondità dei test.
- Ricezione: la segnalazione o l'aggiornamento disponibile viene registrato, con data e fonte.
- Classificazione: stabilire la classe, determinare i sistemi interessati in base all'inventario.
- Preparazione: backup o snapshot, descrivere il ritorno, informare i partecipanti.
- Test: prima in staging o su un sistema meno critico.
- Installazione: nella finestra concordata, sistema per sistema.
- Riavvio: tutti i servizi e i processi interessati, non solo i pacchetti.
- Prova: annotare stato del pacchetto, voce del changelog e avvio dei processi.
- Controllo: verificare il funzionamento; in caso di falle di sicurezza cercare anche tracce di una precedente intrusione.
Il passaggio 6 viene dimenticato sorprendentemente spesso. PHP carica il proprio codice all'avvio dei processi. Finché sono in esecuzione vecchi worker PHP-FPM o processi Apache con mod_php, continuano a lavorare con la versione vecchia e vulnerabile. Perché è così e come riavviare correttamente è spiegato in Dopo l'aggiornamento: riavviare PHP-FPM e tutti i worker.
Prove che contano dopo
Una patch senza prova, nel dubbio, non è stata installata, almeno agli occhi di clienti, assicuratori o revisori. Annoti per ogni sistema quale stato del pacchetto è installato, se i numeri CVE compaiono nel changelog e quando sono stati avviati i processi in esecuzione. Su sistemi Debian e Ubuntu aiutano comandi di sola lettura come questi (adattare il nome del pacchetto al proprio sistema):
# Il pacchetto installato contiene le correzioni?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Quando sono stati avviati i processi PHP-FPM in esecuzione?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
Se l'orario di avvio dei processi precede l'installazione del pacchetto, manca il riavvio. Lo descrive in dettaglio Dimostrare i numeri CVE nel changelog del pacchetto.
Una patch chiude una falla per il futuro. Non rimuove il malware introdotto in precedenza e non dimostra che prima non sia successo nulla. Con le patch d'emergenza la ricerca di tracce fa quindi parte stabile della procedura.
Automatizzare dove è sicuro
Gli aggiornamenti di sicurezza automatici per i pacchetti del sistema operativo tolgono molto lavoro di routine. Alleggeriscono però solo se esistono backup, qualcuno legge i risultati e vengono riavviati anche i servizi interessati. Come configurarli su Linux e quali sono i limiti lo descrive Aggiornamenti di sicurezza automatici sui server Linux.
I container richiedono una strada propria. Lì non si aggiorna il sistema in esecuzione, ma si ricostruisce e si distribuisce l'immagine con la versione di PHP corretta. Un processo di patch che conosce solo i server trascura facilmente questi sistemi. Includa quindi nell'elenco dei percorsi di patch anche pipeline di build e registri di immagini, con una persona responsabile e la stessa prova prevista per i server classici: quale versione di PHP gira nel container distribuito, e da quando?
Applicazioni, CMS e plugin richiedono di solito una strada propria e testata, perché lì gli aggiornamenti modificano più spesso le funzioni. L'appuntamento mensile fisso è il luogo giusto. Alla fine è importante che tutti i percorsi confluiscano nella stessa documentazione: un unico posto in cui si vede quale sistema è a che punto.
Come aiuta concretamente PHP SOS?
- Mettiamo per iscritto con Lei classi di patch, finestre e autorizzazioni, adatte ai Suoi sistemi e alla Sua organizzazione.
- Configuriamo, dove ha senso, aggiornamenti di sicurezza automatici con controllo del riavvio e notifica.
- Ci occupiamo delle patch d'emergenza, compresi riavvio, prova e ricerca di tracce, tramite il nostro servizio patch PHP.
- Teniamo le prove per ogni sistema in modo che Lei possa presentarle a clienti, assicuratori o revisori.
Conclusione: il patch management sembra poco spettacolare finché funziona. È proprio questo l'obiettivo: quando arriva la prossima segnalazione critica, parte una procedura collaudata e nessuno deve improvvisare.
Domande frequenti
Che differenza c'è tra patch management e gestione delle vulnerabilità?
La gestione delle vulnerabilità rileva e valuta le falle e decide che cosa fare. Il patch management attua la decisione: testare gli aggiornamenti, installarli, riavviare i servizi e dimostrare il risultato. I due ambiti si integrano.
Gli aggiornamenti di sicurezza dovrebbero essere installati automaticamente?
Per i pacchetti del sistema operativo spesso ha senso, a patto che esistano backup e che dopo l'esecuzione si controlli. È importante che anche i servizi interessati si riavviino. Con PHP, altrimenti, in memoria restano i vecchi processi con il codice vulnerabile.
Come dimostro che una patch funziona davvero?
Con lo stato del pacchetto installato e i numeri CVE nel changelog del pacchetto, il momento dell'installazione e l'orario di avvio dei processi in esecuzione, che deve essere successivo all'installazione.
Che cosa fare se un aggiornamento rompe qualcosa?
Per questo esiste il ritorno: un backup o snapshot prima dell'aggiornamento e una procedura descritta per il ripristino. Per gli aggiornamenti di sicurezza il ripristino dovrebbe essere l'eccezione ed essere abbinato a una misura provvisoria.