Mantenere i plugin aggiornati e monitorare le vulnerabilità

Installare un plugin è la parte facile. Sapere quando ha bisogno di un aggiornamento, e soprattutto di un aggiornamento di sicurezza, è il lavoro che non finisce mai. MeteorGPL offre quattro strumenti a questo scopo: seguire i pacchetti, le notifiche, la dashboard delle dipendenze e i bollettini sulle vulnerabilità. Questa guida li configura in quest’ordine, poi mostra come aggiornare.

Passo 1 — Segui i pacchetti che usi#

Ogni pagina di pacchetto ha un menu Segui, come su GitHub:

Quando metti una stella a un pacchetto, inizi anche a seguirne le release; puoi disattivare questo comportamento nelle impostazioni di notifica. Impostazioni → Seguiti elenca tutti i pacchetti che segui.

Passo 2 — Scegli come essere avvisato#

In Impostazioni → Notifiche scegli, per ogni tipo di evento, se deve raggiungerti nell’app, come notifica push o via e-mail. Per impostazione predefinita:

• Le nuove versioni arrivano nell’app e via e-mail.
• Gli avvisi di sicurezza arrivano nell’app, tramite push e via e-mail.
• I ritiri arrivano nell’app e via e-mail.

È disponibile anche un riepilogo settimanale di ciò che è cambiato nei pacchetti a cui hai messo una stella, disattivato finché non lo attivi. Le notifiche push si attivano per ogni browser, nella stessa pagina.

Passo 3 — Lascia che sia il file lock a sorvegliarli#

Seguire i pacchetti uno per uno funziona per pochi plugin. Per un intero sito, lascia che sia il file lock a parlare per lui: crea un progetto in Impostazioni → Progetti e carica il composer.lock del sito, a mano o dalla tua pipeline (vedi Token Composer nella CI).

La pagina del progetto mostra ogni pacchetto del repository come:

• aggiornato,
• non aggiornato, con le voci del changelog che ti mancano,
• ritirato, oppure
• rimosso.

Per i tuoi progetti personali, i pacchetti del file lock possono essere seguiti automaticamente per le nuove versioni: spunta Segui le nuove versioni di questi pacchetti nella pagina del progetto. Carica di nuovo il file lock dopo ogni deploy, e la dashboard rispecchierà ciò che gira davvero.

Passo 4 — Intervieni sui bollettini di vulnerabilità#

Le vulnerabilità pubblicate nei plugin e nei temi WordPress, provenienti dal feed delle vulnerabilità di Wordfence Intelligence, vengono confrontate con il catalogo. Ogni corrispondenza compare:

• nella pagina degli avvisi di sicurezza, che ha anche un feed Atom;
• nella sezione Vulnerabilità note della scheda Sicurezza del pacchetto interessato, con le versioni coinvolte e, quando esiste, la versione che corregge il problema e la riga composer require per ottenerla;
• come notifica di sicurezza per chi segue il pacchetto o usa una versione interessata.

I bollettini pubblicati negli ultimi 30 giorni avvisano subito chi segue il pacchetto e le installazioni note. Quelli più vecchi ti avvisano quando in seguito scarichi una versione interessata, o carichi un file lock che la contiene, così anche un sito dimenticato viene segnalato la prossima volta che arriva il suo file lock.

Prima di essere pubblicata, ogni versione viene ripulita, confrontata con il codice di licenza del produttore, analizzata con ClamAV e con regole di pattern e sottoposta a lint; una versione che non supera i controlli non viene pubblicata, e la scheda Sicurezza mostra i controlli. Se in seguito viene trovato un problema, la versione viene ritirata, chi segue il pacchetto viene avvisato e i webhook vengono attivati.

Passo 5 — Aggiorna#

Elenca i pacchetti che hanno versioni più recenti, poi aggiornane uno o tutti, entro i tuoi vincoli:

composer outdated "meteorgpl-plugin/*"
composer update meteorgpl-plugin/elementor-pro

Testa il sito, esegui il commit del nuovo composer.lock e fai il deploy con composer install. Ogni versione pubblicata resta disponibile, quindi se un aggiornamento dà problemi, per tornare indietro basta un comando:

composer require meteorgpl-plugin/elementor-pro:3.20.0

Passo 6 — Automatizza con webhook e feed#

I webhook (Impostazioni → Webhook) inviano una richiesta POST quando un pacchetto che scegli riceve una nuova versione, viene emesso un avviso di sicurezza o un pacchetto viene ritirato: JSON firmato, oppure un messaggio già pronto per Slack o Discord. Verifica le consegne JSON con l’header X-MeteorGPL-Signature, l’HMAC-SHA256 del corpo calcolato con il segreto del tuo webhook. Un webhook JSON può avviare un workflow, ad esempio uno che esegue composer update e apre una pull request.

I feed Atom non richiedono un account: ogni pacchetto ne ha uno per le sue release (nella sua pagina), ogni produttore ne ha uno, e https://meteorgpl.ddev.site/releases.atom riporta ogni nuova versione del repository.