NIS2 e il tuo software: cosa controlla davvero un penetration test
La NIS2 chiede misure entro il 31 ottobre 2026. Cosa guarda un penetration test applicativo su un gestionale Laravel, quanto dura, cosa resta in mano dopo.
- ✓ La NIS2 chiede misure entro il 31 ottobre 2026.
- ✓ Cosa guarda un penetration test applicativo su un gestionale Laravel, quanto dura, cosa resta in mano dopo.
La NIS2 (Direttiva UE 2022/2555, in Italia D.Lgs. 138/2024) è arrivata sulle scrivanie come un adempimento organizzativo: registri, responsabili, procedure. Ma il software che tratta i dati dei clienti è la prima cosa che un attaccante prova. Un penetration test applicativo è il modo più concreto per sapere come sta, e per dimostrarlo.
Chi è obbligato, e quando?
La NIS2 riguarda le medie e grandi imprese dei settori elencati (energia, trasporti, sanità, digitale, manifattura di certi prodotti, alimentare e altri) e i loro fornitori critici. Molte PMI ci entrano dalla porta dei fornitori: se il tuo software gestisce dati per un cliente soggetto, il cliente ti chiederà garanzie. Le misure di sicurezza vanno in atto entro il 31 ottobre 2026; un incidente significativo va notificato al CSIRT entro 24 ore.
Cosa c'entra il software con la NIS2?
La direttiva chiede, fra le altre cose, gestione delle vulnerabilità, controllo degli accessi, sicurezza nello sviluppo e nella catena di fornitura, e la capacità di sapere chi ha fatto cosa. Tradotto per un gestionale Laravel: dipendenze aggiornate, accessi controllati, dati protetti, log che dicono la verità, e una prova scritta che qualcuno ha controllato. Il penetration test è quella prova.
Cosa controlla un penetration test applicativo, punto per punto?
- Autenticazione: password, sessioni, reset, secondo fattore, blocco dei tentativi.
- Autorizzazione: un utente può vedere o modificare dati di un altro cambiando un numero nell'indirizzo? (È il difetto più comune nei gestionali.)
- Input: injection SQL, comandi, upload di file, HTML non filtrato.
- Assegnazione di massa: in Laravel, campi che si possono scrivere dalla richiesta senza che nessuno lo volesse.
- Dati sensibili: cosa passa in chiaro, cosa resta nei log, cosa si esporta.
- Dipendenze: pacchetti PHP e JavaScript con vulnerabilità note.
- Configurazione: debug acceso in produzione, chiavi nel repository, cartelle esposte.
- API e integrazioni: chiavi, limiti di chiamata, cosa vede un partner.
- Log e tracciabilità: si ricostruisce chi ha fatto cosa, e quando?
- Ripetizione: dopo le correzioni, si rifà il test sui punti trovati.
Quanto dura e cosa resta in mano?
Da tre a dieci giornate, a seconda della superficie dell'applicazione: schermate, ruoli, API, integrazioni. Alla fine resta un report scritto con i punti trovati ordinati per gravità, la prova di ogni punto, la correzione proposta, e una seconda verifica dopo le correzioni. A giornate, da 600 a 750 € al giorno, report compreso; il listino è pubblico.
Cosa fa un pentest applicativo che uno scanner non fa?
Lo scanner trova le versioni vecchie e le configurazioni sbagliate: utile, e va fatto. Non trova l'utente che vede la fattura di un altro, il ruolo che può fare più di quanto dovrebbe, il flusso di reset password che si può aggirare. Quelli richiedono qualcuno che conosca il codice, in questo caso Laravel, e che sappia dove i gestionali sbagliano di solito. Quattordici anni di gestionali in produzione servono a questo.
E dopo il test: come non tornare al punto di partenza?
- PHPStan e test automatici in CI, così le correzioni non si perdono al rilascio successivo: la pagina PHPStan su codice legacy spiega come si fa senza fermare i rilasci.
- Dipendenze controllate a ogni build.
- Un test ripetuto a ogni cambiamento grande, non una volta ogni tre anni.
- Log che rispondono a "chi, cosa, quando": è la stessa cosa che chiede la NIS2 e che serve il giorno dell'incidente.
Siamo sotto attacco adesso: cosa faccio?
Isolare il sistema, conservare i log (non cancellarli per "ripulire"), cambiare le credenziali esposte, avvisare chi di dovere: per chi è soggetto alla NIS2, il CSIRT entro 24 ore. Poi analisi e correzione, con un report. La pagina NIS2 lato software e penetration test ha le domande frequenti, compreso il Cyber Resilience Act per chi vende software.
Il prossimo passo sensato
Non serve decidere oggi. 30 minuti gratuiti sui tuoi dati: ne esce un documento con i numeri di oggi, tuo anche se non prosegui. Le partenze sono a calendario, una per volta.
NIS2 e il tuo software: cosa controlla davvero un penetration test
La NIS2 chiede misure entro il 31 ottobre 2026. Cosa guarda un penetration test applicativo su un gestionale Laravel, quanto dura, cosa resta in mano dopo.
La NIS2 (Direttiva UE 2022/2555, in Italia D.Lgs. 138/2024) è arrivata sulle scrivanie come un adempimento organizzativo: registri, responsabili, procedure. Ma il software che tratta i dati dei clienti è la prima cosa che un attaccante prova. Un penetration test applicativo è il modo più concreto per sapere come sta, e per dimostrarlo.
Chi è obbligato, e quando?
La NIS2 riguarda le medie e grandi imprese dei settori elencati (energia, trasporti, sanità, digitale, manifattura di certi prodotti, alimentare e altri) e i loro fornitori critici. Molte PMI ci entrano dalla porta dei fornitori: se il tuo software gestisce dati per un cliente soggetto, il cliente ti chiederà garanzie. Le misure di sicurezza vanno in atto entro il 31 ottobre 2026; un incidente significativo va notificato al CSIRT entro 24 ore.
Cosa c'entra il software con la NIS2?
La direttiva chiede, fra le altre cose, gestione delle vulnerabilità, controllo degli accessi, sicurezza nello sviluppo e nella catena di fornitura, e la capacità di sapere chi ha fatto cosa. Tradotto per un gestionale Laravel: dipendenze aggiornate, accessi controllati, dati protetti, log che dicono la verità, e una prova scritta che qualcuno ha controllato. Il penetration test è quella prova.
Cosa controlla un penetration test applicativo, punto per punto?
- Autenticazione: password, sessioni, reset, secondo fattore, blocco dei tentativi.
- Autorizzazione: un utente può vedere o modificare dati di un altro cambiando un numero nell'indirizzo? (È il difetto più comune nei gestionali.)
- Input: injection SQL, comandi, upload di file, HTML non filtrato.
- Assegnazione di massa: in Laravel, campi che si possono scrivere dalla richiesta senza che nessuno lo volesse.
- Dati sensibili: cosa passa in chiaro, cosa resta nei log, cosa si esporta.
- Dipendenze: pacchetti PHP e JavaScript con vulnerabilità note.
- Configurazione: debug acceso in produzione, chiavi nel repository, cartelle esposte.
- API e integrazioni: chiavi, limiti di chiamata, cosa vede un partner.
- Log e tracciabilità: si ricostruisce chi ha fatto cosa, e quando?
- Ripetizione: dopo le correzioni, si rifà il test sui punti trovati.
Quanto dura e cosa resta in mano?
Da tre a dieci giornate, a seconda della superficie dell'applicazione: schermate, ruoli, API, integrazioni. Alla fine resta un report scritto con i punti trovati ordinati per gravità, la prova di ogni punto, la correzione proposta, e una seconda verifica dopo le correzioni. A giornate, da 600 a 750 € al giorno, report compreso; il listino è pubblico.
Cosa fa un pentest applicativo che uno scanner non fa?
Lo scanner trova le versioni vecchie e le configurazioni sbagliate: utile, e va fatto. Non trova l'utente che vede la fattura di un altro, il ruolo che può fare più di quanto dovrebbe, il flusso di reset password che si può aggirare. Quelli richiedono qualcuno che conosca il codice, in questo caso Laravel, e che sappia dove i gestionali sbagliano di solito. Quattordici anni di gestionali in produzione servono a questo.
E dopo il test: come non tornare al punto di partenza?
- PHPStan e test automatici in CI, così le correzioni non si perdono al rilascio successivo: la pagina PHPStan su codice legacy spiega come si fa senza fermare i rilasci.
- Dipendenze controllate a ogni build.
- Un test ripetuto a ogni cambiamento grande, non una volta ogni tre anni.
- Log che rispondono a "chi, cosa, quando": è la stessa cosa che chiede la NIS2 e che serve il giorno dell'incidente.
Siamo sotto attacco adesso: cosa faccio?
Isolare il sistema, conservare i log (non cancellarli per "ripulire"), cambiare le credenziali esposte, avvisare chi di dovere: per chi è soggetto alla NIS2, il CSIRT entro 24 ore. Poi analisi e correzione, con un report. La pagina NIS2 lato software e penetration test ha le domande frequenti, compreso il Cyber Resilience Act per chi vende software.
Il prossimo passo sensato
Non serve decidere oggi. 30 minuti gratuiti sui tuoi dati: ne esce un documento con i numeri di oggi, tuo anche se non prosegui. Le partenze sono a calendario, una per volta.
- ✓ La NIS2 chiede misure entro il 31 ottobre 2026.
- ✓ Cosa guarda un penetration test applicativo su un gestionale Laravel, quanto dura, cosa resta in mano dopo.
Articoli correlati
Rifiuti, legno e pacchi batteria: tre produzioni che non si somigliano, tracciate con lo stesso metodo. Etichette con QR, eventi per fase, g...
Come si passa da fogli Excel e WhatsApp a un gestionale senza perdere clienti, listini e storico: mappa, pulizia, importazione in due tempi,...
Controllo qualità visivo con modelli addestrati solo sui pezzi buoni: cosa abbiamo trovato in 23.194 foto di saldature, la catena a sei pass...