Un sito non viene 'bucato' in astratto. Viene lasciato indietro. Il ritmo delle patch è operatività, non un favore che si fa quando c'è tempo.
Un sito non viene "bucato" in astratto. Resta indietro: CMS, plugin, runtime, sistema. Le CVE escono con un identificativo pubblico, i vendor pubblicano una toppa, la finestra tra i due momenti è tempo operativo, non un favore da fare "quando c'è il budget". Il ritmo delle patch tiene in piedi il sito. Il WAF, i backup, gli scanner, vengono dopo, e non sostituiscono l'aggiornamento.
In breve: Il programma CVE esiste, oggi su cve.org (MITRE). CMS, estensioni, librerie, OS e runtime vanno aggiornati. Le critiche si trattano subito, il resto in una finestra pianificata, prima in staging, poi in produzione. OWASP, nella categoria A06:2021 Vulnerable and Outdated Components, mette i componenti non aggiornati tra i rischi della Top 10. Qui non si cita la statistica da bar "la maggior parte degli hack è un plugin non patchato": senza un report nominato, non si pubblica.
Cosa trovi in questo articolo
Cosa è una CVE, in pratica
Una CVE è un identificativo pubblico per una vulnerabilità nota. Il processo e il catalogo stanno sul CVE Program. Non è un giudizio sul tuo sito. È un nome condiviso, così vendor, scanner e chi opera possono dire la stessa cosa. Accanto arrivano un avviso del produttore, a volte un punteggio CVSS, a volte un exploit. Si legge l'avviso del vendor sul componente che usi, non un titolo di aggregatore.
Non tutte le CVE ti toccano. Una vulnerabilità in un plugin che non hai, o in una versione che non giri, è rumore. Una CVE sul CMS, su una libreria in produzione, su PHP o sul kernel della macchina, è lavoro. Il primo passo è l'inventario: cosa gira, in quale versione, chi la aggiorna. Senza inventario ogni alert è un'emergenza, o viene ignorato. Tutti e due gli esiti sono scadenti.
OWASP Top 10, voce A06, descrive proprio questo: componenti con vulnerabilità note, senza un processo per tenerli correnti. Non è un dettaglio da sysadmin. È un rischio di applicazione. Nel cluster Sicurezza le patch stanno prima dei gadget.
Cosa si patcha su un sito
Sistema operativo e pacchetti del server, se li amministri. Runtime (PHP, Node, JVM, Python). Il CMS. Temi e plugin. Librerie del progetto (composer, npm, pip). Dipendenze transitive, quelle che non hai scelto tu e che arrivano con un pacchetto. Il pannello. L'agente di backup. Ogni pezzo ha un vendor e un canale di aggiornamento. Se un pezzo non ne ha, è già un problema: o lo sostituisci, o accetti di non poter patchare.
Su WordPress, la documentazione ufficiale su Updating WordPress e gli avvisi in Security esistono per essere usati, non per "quando il sito è fermo". Core, plugin e temi hanno ritmi diversi. Un plugin abbandonato non riceve la CVE con un aggiornamento: riceve un inventario che dice "va tolto". Il costo nascosto dei plugin è anche questo: ogni estensione è una superficie con un autore che può sparire.
Stesso schema su altri CMS e su stack custom. La libreria nel lockfile è produzione, non "un include". npm audit e composer audit non patchano da soli: elencano. Poi qualcuno applica, testa, rilascia.
Critiche subito, il resto in finestra
Due code, non una. Le critiche con exploit già in circolazione, o con impatto alto sul componente esposto in rete, vanno in produzione appena hai un pacchetto e un test minimo. Aspettare il "prossimo giro mensile" su una RCE autenticata da internet è una scelta, non un calendario. Si documenta, si fa, si verifica.
Il resto (minori, dipendenze interne, aggiornamenti di feature) sta in una finestra. Giornaliera, settimanale, a sprint: conta che esista, con un owner, non la marketing-word "continuo". In quella finestra si aggiorna, si guarda lo staging, si rilascia, si legge l'error log. Senza finestra, le patch si accumulano e il rilascio diventa un salto di dieci versioni il venerdì sera. Quello sì che rompe il sito. Il ritmo piccolo rompe meno.
Chi non ha in casa questo mestiere lo affida. I servizi di sviluppo web di Keidea coprono manutenzione e sviluppo gestiti: inventario, finestre, staging, rilascio. Non è "sicurezza extra". È operatività. L'articolo resta in piedi senza quel nome: se nessuno ha il ritmo, il sito invecchia, CVE o non CVE.
Staging prima della produzione
Una patch è un cambio di codice o di binario. Può rompere un checkout, un form, un gateway. Staging (o un canary) non è un vezzo: è il posto dove la toppa incontra il tuo tema, i tuoi plugin, i tuoi hook. Copia di dati mascherata, stessa versione runtime, stesso web server. Poi un percorso utente corto: home, una scheda, login, un postback che conta.
Non sempre lo staging replica tutto (pagamenti in sandbox, cron, cache CDN). Si sa cosa non replica, e in produzione si osserva dopo il rilascio. Rollback pronto: backup recente, o artefatto precedente. Patchare senza poter tornare indietro trasforma un aggiornamento in una scommessa. Nel cluster Operatività backup e monitoring stanno proprio a questo passaggio, non in un cassetto.
Auto-update del CMS: utile sui minor e sulle patch di sicurezza del core, se il vendor lo sostiene e se hai comunque backup e alert. Meno utile se un major parte da solo il sabato su un tema incompatibile. Si sceglie per componente, non per fede. WordPress documenta gli aggiornamenti; non obbliga a premere "tutto, sempre, in produzione, senza copia".
Cosa non sostituisce una patch
Un WAF può virtual-patchare una firma nota. È tempo comprato, non debito estinto. La regola va mantenuta, l'exploit può variare, il componente resta vecchio. Scanner e pentest trovano; non applicano. Il backup ripristina dopo. HTTPS cifra il transito. Nessuno di questi è l'aggiornamento del binario vulnerabile.
Chiudere un ticket "mitigato in WAF" e togliere la patch dalla coda è il modo di ritrovare la stessa CVE sei mesi dopo, con la regola WAF disattivata in un cleanup. La mitigazione si data, si rivede, si chiude quando il componente è aggiornato. Prima, il ticket resta aperto.
Errori da evitare
Aspettare il redesign per aggiornare. La CVE non aspetta il nuovo tema.
Aggiornare tutto il venerdì senza staging. Si accumula rischio su rischio.
Tenere plugin e librerie senza maintainer. Non riceverai la toppa. L'inventario deve dirlo.
Confondere uno scan verde con un sito aggiornato. Lo scan vede ciò che vede. L'inventario vede ciò che gira.
Usare il WAF come scusa per non patchare. È un filtro, non un vendor.
Citare percentuali di "attacchi da plugin" senza un report. O c'è la fonte, o si omette.
In sintesi
Le patch sono un ritmo: inventario, CVE del vendor, coda critica e coda pianificata, staging, produzione, sguardo ai log. cve.org dà i nomi. OWASP A06 dà il perché. WordPress e gli altri CMS danno i canali di update. Il WAF compra ore, il backup compra un restore, nessuno dei due sostituisce la versione nuova. Si patcha perché il sito deve restare in piedi, non per uno slogan sulla sicurezza. Meno rumore, più calendario.
Fonti
OWASP, Top 10 e A06:2021 Vulnerable and Outdated Components.
WordPress, Updating WordPress e Security.
WordPress.org, Security (policy del progetto).
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
