Quando una versione di PHP esce dal supporto ufficiale e la migrazione richiede mesi, molte aziende cercano un fornitore che continui a correggere le vulnerabilità sul ramo in uso. Le offerte di “supporto esteso” però sono molto diverse tra loro: alcune forniscono pacchetti ricostruiti con le patch, altre sostituiscono l’intero stack, altre ancora si limitano a una consulenza a chiamata. Dal nome del servizio è difficile capire cosa si sta comprando, e le differenze emergono quando esce una CVE critica e il fornitore deve rispondere davvero.
In questo articolo raccogliamo le domande da fare prima di firmare, divise in sei aree, insieme ai segnali che indicano un servizio solido e a quelli che meritano un chiarimento. Sono le stesse domande che ci aspettiamo dai nostri clienti, e per ognuna indichiamo come rispondiamo noi, così il confronto con altre offerte è più semplice.
Cosa si compra davvero
Il supporto esteso per PHP consiste nel prendere le correzioni di sicurezza pubblicate per i rami supportati e adattarle al codice di un ramo in End of Life, ricostruire i pacchetti e installarli al posto di quelli in uso. È il lavoro di backport che descriviamo nell’articolo su cos’è il backport delle patch di sicurezza.
Due limiti vanno chiariti fin dall’inizio, perché nessun fornitore serio dovrebbe nasconderli. Il primo: il backport chiude le vulnerabilità note, ma la versione resta fuori supporto e ogni nuova CVE richiede una nuova analisi. Il secondo: le librerie dell’applicazione, il CMS e i suoi moduli restano fuori dal perimetro, e su un PHP vecchio spesso sono anch’essi datati. Il supporto esteso è un ponte verso la migrazione e va scelto come tale.
1. Il perimetro
La prima domanda è banale e decisiva: il fornitore copre esattamente la tua combinazione di versione di PHP, distribuzione e modalità di esecuzione? PHP 7.4 con PHP-FPM su AlmaLinux 8 e PHP 5.6 con mod_php su CentOS 7 sono situazioni molto diverse. Chiedi inoltre:
- quali estensioni sono incluse, in particolare quelle che usi davvero, come
gd,intl,soapombstring; - da quali pacchetti parte la ricostruzione: quelli della distribuzione, di Remi, delle Software Collections, di AppStream o di deb.sury.org;
- se i pacchetti corretti mantengono nomi, percorsi e configurazioni attuali, o se impongono una nuova struttura;
- se le librerie di sistema da cui PHP dipende, come OpenSSL o libxml2, sono comprese.
Noi ricostruiamo i pacchetti RPM e DEB partendo da quelli già installati, per toccare il meno possibile la configurazione esistente.
2. Il processo sulle CVE
Un servizio di supporto esteso vale quanto il suo processo di analisi. Le domande da fare:
- quali fonti vengono seguite: avvisi del progetto PHP, database come NVD e cve.org, liste di sicurezza delle distribuzioni;
- come si stabilisce se una CVE riguarda il ramo in uso, visto che molte correzioni toccano codice che nei rami vecchi non esiste o è diverso;
- se esiste un elenco, per ogni versione, delle CVE corrette, di quelle non applicabili con il motivo e di quelle ancora aperte;
- come viene comunicata una nuova vulnerabilità e la decisione presa.
L’elenco delle CVE è il documento più importante: è quello che mostrerai a un auditor o a un cliente. Sul solo PHP 5.6.40 il nostro pacchetto corregge 55 CVE, di cui 11 aggiunte da noi con backport dedicati.
3. Tempi e reperibilità
Ogni offerta promette rapidità. La differenza sta nella definizione. Chiedi da quale momento parte l’orologio (pubblicazione della CVE, tua segnalazione, conferma dell’applicabilità), a quale evento si ferma (analisi, pacchetto pronto, rilascio in produzione) e cosa succede se il termine non viene rispettato. Chiedi anche chi risponde fuori orario e come lo si contatta: un indirizzo email letto il giorno dopo non è reperibilità.
Per un intervento d’urgenza su una singola CVE il nostro obiettivo è di 24 ore dall’analisi al rilascio, con reperibilità H24 al numero +39 340 985 4556. È un obiettivo, e come tale lo scriviamo: il tempo reale dipende dalla complessità della correzione e dai test necessari.
4. Test, rilascio e rollback
Una patch corretta può comunque rompere un’applicazione che dipende da un comportamento particolare. Per questo conta come viene verificata prima di arrivare in produzione:
- se esiste un ambiente di prova con la tua applicazione reale, non solo con i test dell’interprete;
- chi esegue le verifiche funzionali e con quali criteri di accettazione;
- come avviene l’installazione: a mano, con script o con strumenti di automazione;
- qual è il piano per tornare alla versione precedente, e in quanto tempo;
- quale documentazione resta dopo ogni rilascio.
Il nostro rilascio passa da un ambiente di prova con l’applicazione reale e avviene con Ansible, con un piano di rollback definito prima di toccare la produzione.
5. Accessi, dati e contratto
Un fornitore che installa pacchetti sui tuoi server può accedere, almeno in teoria, ai dati che quei server trattano. Questo ha conseguenze precise. Se ci sono dati personali, il fornitore agisce di norma come responsabile del trattamento e l’articolo 28 del Regolamento (UE) 2016/679 richiede un contratto con contenuti minimi, tra cui istruzioni documentate, riservatezza, misure di sicurezza e regole sui subfornitori. Se la tua organizzazione è soggetta alla NIS2, il fornitore rientra nella sicurezza della catena di approvvigionamento. Se tratti dati di carte di pagamento, PCI DSS chiede accordi scritti con i fornitori terzi e un monitoraggio annuale della loro conformità.
Le domande pratiche riguardano chi accede, con quali credenziali, da dove, per quanto tempo e con quale tracciamento. Ne parliamo in dettaglio nell’articolo su patching su server di altri fornitori, accessi e GDPR. Per la qualificazione dei ruoli nel tuo caso specifico, fai riferimento al tuo consulente privacy.
6. Durata e uscita
Il supporto esteso deve avere una fine prevista. Le domande sull’uscita sono spesso le più trascurate:
- per quanto tempo il fornitore si impegna a coprire il ramo, e con quale preavviso può interrompere il servizio;
- cosa resta al cliente alla fine del contratto: pacchetti installati, elenco delle patch applicate, documentazione;
- se il fornitore offre o supporta la migrazione verso un ramo supportato, e come si integra con il supporto in corso;
- se esistono vincoli che rendono difficile cambiare fornitore, come pacchetti con nomi o repository proprietari.
Un’offerta che presenta il supporto esteso come soluzione definitiva sta vendendo un rischio come se fosse una garanzia.
Come confrontare due offerte
Due proposte di supporto esteso raramente sono confrontabili a colpo d’occhio: una indica un canone mensile per server, l’altra un prezzo per intervento, una terza un pacchetto annuale con un numero di ore. Prima di guardare il prezzo conviene riportarle allo stesso schema, chiedendo a ogni fornitore la stessa evidenza per ogni voce.
| Voce | Cosa chiedere | Evidenza da ottenere |
|---|---|---|
| Copertura | versioni, distribuzioni, SAPI ed estensioni incluse | elenco scritto, allegato al contratto |
| CVE | elenco delle vulnerabilità corrette e non applicabili | documento per versione, con motivazioni |
| Tempi | inizio e fine del conteggio, eccezioni | definizioni scritte nel contratto |
| Qualità | test eseguiti prima del rilascio | esempio di report di un intervento reale |
| Rilascio | modalità di installazione e ritorno indietro | procedura scritta e tempi di rollback |
| Dati | ruolo privacy, accessi, subfornitori | accordo sul trattamento e registro degli accessi |
| Uscita | durata, preavviso, materiali lasciati al cliente | clausole di fine contratto |
| Costo | cosa è compreso nel canone e cosa si paga a parte | esempio di fattura per un mese con un’urgenza |
L’ultima riga è la più rivelatrice. Chiedere quanto costerebbe un mese in cui esce una CVE critica, con analisi, ricostruzione, test e rilascio fuori orario, mostra subito se il canone base copre il caso che conta o se lo esclude. Allo stesso modo, conviene chiedere cosa succede quando una correzione non si può portare sul ramo in uso: un fornitore serio lo dice e propone mitigazioni documentate, invece di dichiarare la vulnerabilità chiusa.
Segnali da osservare
Una verifica utile è chiedere un esempio concreto: una CVE recente che riguardava il tuo ramo, l’analisi fatta, la patch applicata e il pacchetto prodotto. Un fornitore con un processo reale può mostrarlo in pochi minuti; anche il changelog del pacchetto installato dovrebbe citare gli identificativi delle CVE corrette.
In conclusione
Prima di firmare un contratto di supporto esteso per PHP, chiedi per iscritto risposte su sei aree: perimetro coperto, processo di analisi delle CVE, tempi e reperibilità con definizioni precise, test e rollback, accessi e accordi sui dati, durata e uscita. Il documento più importante è l’elenco delle CVE corrette per versione, che serve anche negli audit. Diffida delle promesse generiche, delle installazioni senza ambiente di prova e del supporto presentato come definitivo: il backport chiude le vulnerabilità note e dà tempo, mentre la soluzione stabile resta la migrazione a un ramo supportato. Se vuoi mettere alla prova le nostre risposte, le trovi nella sezione sugli interventi.
