Quanti siti sono CMS e quanti sono applicazioni su misura

I numeri di W3Techs dicono che circa il 68% dei siti con un CMS riconosciuto usa WordPress, Shopify o una piattaforma simile. Il resto, poco più di un terzo del web pubblico monitorato, non usa nessuno dei CMS che quelle statistiche tracciano. Dentro ci sono siti statici, ma anche moltissime applicazioni custom. Non è un dato perfetto. “Nessun CMS rilevato” non equivale esattamente a “applicazione su misura”. Ma la direzione è chiara: le web app fatte a mano restano una fetta enorme di internet.

Tra i framework PHP usati per queste applicazioni, Laravel è oggi il più diffuso. Il sondaggio State of PHP 2025 di JetBrains, su oltre 1.700 sviluppatori, riporta il 64% di utilizzo per Laravel. Symfony segue, ma più indietro. Sui miei hosting la situazione è coerente con questo trend. Le applicazioni custom che gestisco per i clienti, quando non sono WordPress, sono quasi sempre progetti Laravel. Qualche cliente arriva già con un progetto esistente da mantenere. Altri me lo chiedono da zero, sapendo che è la scelta più comune sul mercato. I conteggi assoluti di siti, da fonti come BuiltWith, vanno presi con cautela: Laravel include al suo interno diversi componenti di Symfony, e questo confonde un po’ le statistiche basate solo sui pacchetti installati. Ma il quadro generale non cambia: per chi scrive applicazioni PHP su misura, oggi Laravel è il punto di partenza più comune, non l’eccezione.

Come monitoro gli aggiornamenti di sicurezza Laravel

Un progetto Laravel in produzione non è mai “finito e fermo”. Il framework, i suoi componenti e le decine di pacchetti Composer che porta con sé ricevono patch quando viene trovata una falla. Se nessuno controlla, un sito può restare vulnerabile per mesi. Il cliente spesso non se ne accorge nemmeno. È lo stesso principio che ho applicato quando ho dovuto gestire un attacco in corso su un server durante un’emergenza di sicurezza PHP: meglio prevenire con un controllo regolare, che correre dietro al problema dopo che è già scoppiato.

Per questo ho scritto uno script bash semplice. Lo faccio girare via cron su ogni progetto Laravel che gestisco. Lo integro anche nelle pipeline di deploy, quando il cliente ne ha una. Non fa magie: legge il file di lock di Composer e lo confronta con i database di vulnerabilità note. Eccolo, esattamente come lo uso io, senza modifiche.

Lo script di audit

#!/usr/bin/env bash
set -euo pipefail

PROJECT_DIR="${1:-.}"
cd "$PROJECT_DIR"

echo "==> Project: $(pwd)"

if [[ ! -f composer.lock ]]; then
  echo "SKIP: composer.lock non trovato (non sembra un progetto composer installato)."
  exit 0
fi

echo ""
echo "==> Composer audit (vulnerabilità note)"
# --no-interaction utile in CI; fallisce (exit code != 0) se trova advisory
composer audit --no-interaction

echo ""
echo "==> Pacchetti outdated (info)"
composer outdated --direct || true

echo ""
echo "==> Laravel version (se presente)"
php -r '
$lock=json_decode(file_get_contents("composer.lock"), true);
$pkgs=array_merge($lock["packages"] ?? [], $lock["packages-dev"] ?? []);
$laravel=null;
foreach ($pkgs as $p) { if (($p["name"] ?? "")==="laravel/framework") { $laravel=$p["version"] ?? null; break; } }
echo $laravel ? "laravel/framework: $laravel\n" : "laravel/framework non trovato nel lock\n";
'

Avviso: lo script è fornito così com’è, a scopo informativo. L’uso è sotto la tua esclusiva responsabilità: non mi assumo alcuna responsabilità per perdita di dati, interruzioni di servizio, o qualsiasi errore generato da un utilizzo scorretto o da un contesto diverso da quello in cui lo eseguo io stesso. Fai sempre un backup indipendente prima di eseguirlo in produzione.

composer audit è un comando integrato in Composer dalla versione 2.4. Legge le versioni esatte dei pacchetti dentro composer.lock. Le confronta con un database di advisory di sicurezza pubblicate. Il database arriva tramite Packagist, che a sua volta si appoggia al repository FriendsOfPHP/security-advisories e al GitHub Advisory Database. Se trova una corrispondenza, elenca il pacchetto, la versione vulnerabile e l’advisory collegato. Poi termina con un codice di uscita diverso da zero. È questo il dettaglio che mi interessa di più. Un exit code non-zero è quello che permette a un cron o a una pipeline di capire da solo che qualcosa va rivisto. Non devo leggere ogni riga di log a mano.

Sui progetti in produzione lo lancio una volta al giorno via cron, con l’output mandato per email se il comando fallisce. Su qualche cliente più strutturato l’ho integrato anche nella pipeline di deploy. Se composer audit trova un advisory bloccante, il deploy si ferma prima di arrivare in produzione. Meglio fermarsi lì che scoprirlo dopo, con il sito già online. Questo controllo quotidiano, ripetuto su ogni progetto, è il cuore pratico degli aggiornamenti di sicurezza Laravel che applico davvero, non solo quando mi ricordo di farlo a mano.

La seconda riga dello script, composer outdated --direct, mostra solo le dipendenze dichiarate a mano nel composer.json. Non mostra l’intero albero delle dipendenze transitive. Un progetto Laravel medio porta con sé centinaia di pacchetti indiretti. Se li elencassi tutti, l’output sarebbe illeggibile. Finirei per ignorarlo, come capita con troppi avvisi automatici. Guardando solo le dipendenze dirette, vedo in un colpo d’occhio cosa ho scelto io. Posso decidere con calma cosa aggiornare e quando farlo.

L’ultima parte dello script stampa la versione di laravel/framework presente nel lock file. Lo faccio perché il ciclo di vita delle versioni Laravel ha scadenze precise. Le voglio sapere senza aprire ogni progetto a mano, uno per uno. Secondo la tabella ufficiale di supporto pubblicata da Laravel, le patch di sicurezza per la versione 11 sono terminate il 12 marzo 2026. La versione 12 le riceve fino al 24 febbraio 2027. Dal primo trimestre 2026 la versione corrente è Laravel 13. Pianificare gli aggiornamenti di sicurezza Laravel per tempo significa anche questo: sapere su quale versione è fermo ogni progetto, prima che scada il supporto.

I limiti onesti di questo controllo

composer audit non è un antivirus. Non legge il codice dell’applicazione. Segnala solo vulnerabilità note e già pubblicate in un advisory. Contro una falla zero-day, scoperta ma non ancora divulgata, non serve a niente. Per questo lo considero un controllo di igiene di base, non una garanzia assoluta. Gli aggiornamenti regolari dei pacchetti restano la pratica più efficace, anche senza un advisory in corso. La documentazione ufficiale di Laravel consiglia di restare sulla versione corrente del framework. Consiglia anche di automatizzare i test prima di ogni aggiornamento di major. Serve a rendere l’aggiornamento un’abitudine, non un’emergenza dell’ultimo minuto.

Resta il fatto che uno script di poche righe, lanciato ogni giorno, mi avrebbe fatto risparmiare più di un’email imbarazzante ai clienti, negli anni in cui non lo usavo ancora. Oggi fa parte della routine di manutenzione di ogni progetto Laravel che seguo. Lo affianco al monitoraggio dei log e dei tentativi di accesso sui server. Gli aggiornamenti di sicurezza Laravel non eliminano il rischio. Lo riducono parecchio. E costano pochissimo, rispetto a un sito compromesso e a un cliente che perde fiducia.

The post Aggiornamenti di sicurezza Laravel: come li monitoro first appeared on Matteo Cisilino.