Mancano poco più di tre settimane. Il 30 giugno Adobe smette ufficialmente di supportare Magento 1, e per la prima volta da quando nel 2011 ho cominciato a lavorare su questa piattaforma mi trovo a scrivere di una fine annunciata da anni ma che, guardandomi intorno, moltissimi merchant stanno ancora rimuovendo. Ho visto negozi da milioni di GMV arrivare a maggio 2020 senza un piano. Non lo dico per fare il catastrofista: lo dico perché il 1° luglio cambia qualcosa di molto concreto, e vale la pena capire cosa.
Cosa smette davvero di funzionare il 1° luglio
Partiamo da un equivoco che sento ripetere spesso: “tanto il sito continua a funzionare”. È vero, ed è esattamente il punto. Magento 1 il 1° luglio non si spegne. Nessuno stacca la spina. Il checkout funziona, gli ordini entrano, il magazzino si aggiorna. Ed è proprio questa apparente normalità la trappola più pericolosa, perché toglie l’urgenza percepita mentre il rischio reale sale.
Quello che finisce non è il software, è il supporto. Nel concreto significa tre cose. Non usciranno più patch di sicurezza ufficiali da Adobe. Non usciranno più i SUPEE, i pacchetti di security che chi lavora su Magento 1 conosce a memoria. E non ci sarà più alcun aggiornamento di compatibilità: né per PHP, né per le librerie di terze parti, né per i moduli di pagamento.
Da sviluppatore, la parte che mi preoccupa di più è la prima. Finché Adobe rilasciava SUPEE, esisteva un canale ufficiale: si scopriva una vulnerabilità, arrivava la patch, la si applicava. Dal 1° luglio quel canale si chiude. Se domani qualcuno trova una falla in una porzione core di Magento 1 — e la troverà, perché è una piattaforma diffusissima e quindi un bersaglio interessante — non ci sarà nessuna patch ufficiale a proteggerti. Sei solo, con il tuo team o con la tua agency.
Perché una piattaforma “che funziona” è comunque un rischio
Le piattaforme e-commerce sono bersagli appetibili per una ragione ovvia: ci passano i dati delle carte e i dati personali dei clienti. Magento 1 negli anni ha già avuto la sua dose di attacchi noti — il fenomeno del Magecart, cioè l’iniezione di skimmer JavaScript che intercettano i dati di pagamento in fase di checkout, ha colpito migliaia di negozi Magento proprio sfruttando installazioni non aggiornate. E questo mentre le patch esistevano ancora.
Il mio timore, molto concreto, è che il 30 giugno funzioni da segnale. Chi cerca vulnerabilità sa benissimo che da luglio un’enorme base installata resterà congelata per sempre. È l’equivalente digitale di annunciare pubblicamente che una certa serratura non verrà più cambiata. Non è una previsione apocalittica, è come funziona l’ecosistema: dove il difensore smette di aggiornare, l’attaccante ha più tempo e più margine.
Il problema PCI-DSS, che è la parte che spesso viene sottovalutata
C’è un aspetto che i merchant sottovalutano quasi sempre, ed è quello che secondo me pesa di più a livello di business. Se accetti pagamenti con carta, sei tenuto alla conformità PCI-DSS. Uno dei requisiti fondamentali dello standard è mantenere i sistemi aggiornati e protetti con le patch di sicurezza rilasciate dal vendor.
Ora, ragioniamo. Se il vendor smette di rilasciare patch, come fai a soddisfare un requisito che ti chiede di applicare le patch del vendor? Non puoi. Girare su una piattaforma non più supportata ti mette, di fatto, in una posizione difficile rispetto alla compliance. Non è un cavillo formale: significa che, in caso di data breach su un sistema non supportato, l’esposizione — verso l’acquirer, verso i circuiti, verso i clienti — diventa molto più pesante. Ho visto responsabili IT scoprire questo dettaglio troppo tardi, quando la domanda arriva dalla banca e non dall’agenzia.
Cosa fare se non hai ancora migrato
Qui divido nettamente in due, perché sono due cose diverse che vengono spesso confuse.
Le mitigazioni tampone (utili, ma non sono la soluzione)
Se al 3 giugno non sei ancora migrato, la migrazione vera non la completi in tre settimane — sarei disonesto a dirti il contrario. Quindi nel frattempo servono misure per ridurre l’esposizione. Nella mia esperienza le più sensate sono: mettere un Web Application Firewall davanti al negozio, così da filtrare buona parte degli attacchi noti prima che tocchino Magento; irrigidire gli accessi al pannello admin (IP whitelisting, autenticazione forte, URL admin non banale); rimuovere estensioni di terze parti che non usi più e che restano una superficie d’attacco dimenticata; monitorare in modo attivo file e integrità del checkout per accorgersi in fretta di eventuali skimmer.
Esistono anche patch di sicurezza mantenute da terze parti al di fuori di Adobe. Possono aiutare, ma diciamolo chiaramente: dipendi da un attore che non è il vendor originale, con tutte le incognite del caso. È un cerotto, non una cura.
La mia opinione netta: queste misure servono a comprarti mesi, non anni. Se le presenti a te stesso come “soluzione”, ti stai raccontando una storia.
La migrazione vera
La migrazione a una piattaforma supportata non è un aggiornamento, è un progetto di re-piattaforma. Non si trascina il vecchio codice: si ricostruisce il tema, si rivedono le estensioni (molte non esistono più o vanno riscritte), si migrano dati di catalogo, clienti e ordini. Chi ha una base di codice custom stratificata negli anni deve mettere in conto tempo vero — nella mia esperienza si ragiona in mesi, non in settimane, e il numero dipende quasi tutto da quanta personalizzazione hai accumulato.
Il consiglio che do sempre: usa questa scadenza per fare pulizia, non per replicare. Ogni progetto di migrazione è l’occasione per buttare i moduli che non servono più e ripensare le personalizzazioni che nel tempo sono diventate zavorra. Chi migra “com’era” si porta dietro i problemi vecchi dentro una piattaforma nuova.
Non è un problema tecnico, è un problema di business
Chiudo con la cosa che mi preme di più. Per anni la fine del supporto di Magento 1 è stata trattata come una faccenda da reparto IT, una scadenza tecnica da spuntare. Secondo me è un errore di inquadramento.
Un incidente di sicurezza su un e-commerce non è un downtime. È il nome del tuo negozio associato a “dati delle carte rubati”. È la fiducia dei clienti, che nell’online è l’unico asset che conta davvero, che si incrina in un pomeriggio e ci mette anni a ricostruirsi. È il rischio compliance che diventa un problema legale. La componente tecnica è solo l’innesco; il danno è di reputazione e di business.
Il 30 giugno non è la fine del mondo e Magento 1 non esploderà. Ma è il giorno in cui smetti di avere una rete di protezione ufficiale sotto i piedi. La domanda giusta da farsi in queste settimane non è “quanto costa migrare”, ma “quanto sono disposto a scommettere che a me non succeda niente”. Io, quella scommessa, non la farei.
Mini-FAQ
Magento 1 smette di funzionare il 30 giugno 2020?
No. Il negozio continua a funzionare. Ciò che finisce è il supporto ufficiale di Adobe: niente più patch di sicurezza, niente più SUPEE, niente più aggiornamenti di compatibilità.
Cosa rischio se resto su Magento 1 dopo la fine del supporto?
Esposizione crescente a vulnerabilità non più corrette, maggior rischio di attacchi tipo Magecart e skimming dei dati di pagamento, e difficoltà a mantenere la conformità PCI-DSS, che richiede sistemi aggiornati con le patch del vendor.
Se non ho ancora migrato, faccio in tempo entro il 30 giugno?
Una migrazione completa non si conclude in poche settimane. Nel frattempo si adottano mitigazioni tampone — WAF, hardening dell’admin, rimozione delle estensioni inutili, monitoraggio del checkout — che riducono l’esposizione ma non sostituiscono la migrazione.
La conformità PCI-DSS è davvero a rischio su una piattaforma non supportata?
Sì. Lo standard richiede di applicare le patch di sicurezza del vendor. Se il vendor non ne rilascia più, quel requisito diventa impossibile da soddisfare pienamente, aumentando l’esposizione in caso di data breach.
Fabio Canovi — Esperto di Magento e Adobe Commerce, tra i primi professionisti in Italia a ottenere la certificazione Adobe Commerce. Progetto e seguo piattaforme e-commerce enterprise dal 2011, quando ho iniziato a lavorare proprio su Magento 1.