Modernizzare un gestionale finanziario PHP 5.4 sotto vincolo NIS2: quattro mesi per portare a compliance un sistema di 93.000 righe con dati di 11.000 clienti
Gestionale PHP 5.4 di un intermediario creditizio: 93.000 righe, dati di 11.000 clienti, password in MD5, zero cifratura, backup su disco USB. NIS2 e DORA imponevano adeguamento immediato. Da settembre a dicembre 2025 ho portato il sistema a PHP 8.4 con cifratura, audit trail, 2FA e documentazione che ha superato la verifica dell'auditor. Continua a leggere
Ultima modifica:
Il codice generato da AI sembra pulito ma nasconde classi di vulnerabilità ricorrenti che il contesto non riesce a catturare: SQL injection con parametri concatenati, XSS in output non sanitizzati, API key committate, pattern anti-OWASP. Nella mia sandbox di audit su codice AI-generated ho analizzato 40 output di ChatGPT, Copilot e Claude: ecco il catalogo dei pattern pericolosi e la checklist che applico sistematicamente prima di mergiare qualsiasi codice AI-generated. 
Fail2ban installato su un VPS Digital Ocean con SaaS Laravel ma fermo da sei mesi - disabilitato durante un aggiornamento e mai riattivato. 14.000 tentativi SSH brute force al giorno, inoffensivi solo perché l'autenticazione era a chiave. Ma il login web Laravel non aveva nessuna protezione. Diagnosi, riattivazione, jail SSH, jail custom per login web e ban progressivo con recidive. 
Un portale B2B Laravel su Hetzner con certificato Let's Encrypt scaduto da 11 giorni - il rinnovo automatico di Certbot falliva perché la porta 80 era bloccata da una regola UFW aggiunta durante un hardening. HSTS attivo con max-age di un anno impediva il fallback a HTTP: il sito era un fantasma per tutti i browser. Diagnosi con openssl s_client, fix Certbot, rollout HSTS graduale e hardening Nginx per TLS 1.3 con A+ su SSL Labs. 
Su un VPS Hetzner AX41 con un e-commerce Laravel, MySQL 8.0 era raggiungibile da internet sulla porta 3306, l'utente root non aveva password, e l'applicazione usava root per tutte le operazioni - dal checkout alle migration. L'audit ha rivelato 14 violazioni del CIS Benchmark. Il protocollo di hardening che applico in due ore: mysql_secure_installation, segregazione utenti, bind su localhost, TLS obbligatorio, disabilitazione local_infile e audit log. 
Un VPS OVH con Debian 11 e Laravel 10 non vedeva un apt upgrade da 14 mesi. 247 pacchetti arretrati, 38 security patch mancanti, OpenSSH con regreSSHion non patchato. Il proprietario non lo sapeva - l'app funzionava. Il protocollo per aggiornare un server di produzione senza downtime: snapshot, dry run, upgrade in due fasi, needrestart, verifica applicativa e setup unattended-upgrades. 
Un CRM Laravel 9 per una PMI logistica veneta è stato compromesso perché un file .env con l'APP_KEY era stato committato su un repository GitHub pubblico due anni prima. L'attaccante ha sfruttato CVE-2018-15133 per ottenere esecuzione remota di codice tramite cookie deserializzato, ha piantato una backdoor in un comando Artisan e ha esfiltrato 4.200 record clienti. Cinque giorni di lavoro: contenimento senza distruzione delle prove, forensics applicativa, remediation e hardening permanente. 
Quando un'applicazione Laravel cresce oltre le capacità di un hosting condiviso, la migrazione verso un VPS diventa inevitabile. Il problema è che molte PMI la affrontano come un trasloco meccanico, quando in realtà è una transizione architetturale che richiede pianificazione, hardening e verifica. In questo articolo racconto il metodo che applico nelle migrazioni reali, con le trappole più comuni e le decisioni che fanno la differenza tra un passaggio pulito e settimane di problemi. 
CVE-2025-32433 ha colpito il server SSH di Erlang/OTP con un pre-auth RCE da CVSS 10.0. Non è memory corruption: è una logic flaw nello state machine, che accetta CHANNEL_OPEN prima dell'autenticazione. Anatomia del bug, mappa dei componenti Erlang nascosti in produzione PMI (RabbitMQ, CouchDB, ejabberd) e cinque mitigation che applico dal maggio 2025. 
regreSSHion (CVE-2024-6387) ha riaperto un buco nella sshd di OpenSSH 18 anni dopo che era stato chiuso. Anatomia del race condition nel signal handler SIGALRM, perché il refactor del 2020 ha rimosso la fix originale, quanto era realisticamente sfruttabile su 64-bit, e l'hardening SSH che applico oggi alle PMI dopo aver patchato circa 200 server in produzione la notte del 1 luglio 2024.