Il questionario di sicurezza del tuo cliente è già arrivato? Entro il 31 ottobre 2026 serve una risposta anche nel software

Ti riconosci in almeno due di queste?

• Un cliente grande ti ha mandato un questionario di sicurezza con domande sul software, e hai risposto "in corso".
• Il consulente NIS2 ha fatto registro, referente e procedure, ma sul gestionale ha scritto "verificare con il fornitore".
• Il gestionale che usi (o che vendi) lo ha scritto qualcuno anni fa, e nessuno sa se un utente può vedere i dati di un altro.
• PHP o Laravel sono a una versione che non riceve più aggiornamenti di sicurezza.
• Nessuno ha mai provato ad attaccare il software prima di un cliente, o di un dipendente scontento.

Se hai detto sì almeno due volte sei nella situazione più comune: la parte organizzativa della NIS2 è coperta, la parte dentro il software no. E l'audit guarda entrambe.

Cosa costa scoprirlo dopo

La direttiva europea NIS2, recepita in Italia con il decreto legislativo 138/2024, obbliga le aziende dei settori essenziali e importanti (energia, trasporti, sanità, acqua, rifiuti, manifattura di dispositivi e macchinari, servizi digitali) a misure minime di sicurezza entro il 31 ottobre 2026 (determinazione ACN 379907/2025). Molte PMI ci rientrano come fornitori: se un cliente ti chiede un questionario, è già cominciata.

• Una vulnerabilità di controllo degli accessi (un utente che vede o modifica dati di altri) è la più comune nei gestionali e la più grave: dati di clienti e dipendenti esposti, notifica al Garante, cliente perso.
• Un questionario fornitori con risposte vaghe pesa nella scelta del prossimo ordine, anche se nessuno te lo dice.
• Se il software lo vendi, dal 2027 il Cyber Resilience Act aggiunge obblighi di sicurezza per progettazione e aggiornamenti.

Se il prossimo questionario lo compilassi con un report in mano?

Immagina di rispondere con una pagina: cosa è stato verificato nel gestionale, quando, con quale metodo, con quale esito, e cosa è stato corretto. È quello che il tuo consulente NIS2 vuole allegare, e quello che il tuo cliente grande vuole leggere.

Il penetration test applicativo con metodo OWASP guarda proprio dove stanno i problemi dei gestionali:

• Autorizzazioni: un utente vede o modifica dati di altri?
• Input: iniezioni SQL, XSS, upload di file, parametri manipolati.
• Sessioni e autenticazione: password, token, reset, sessioni che non scadono.
• Dipendenze: librerie con vulnerabilità note, versioni di PHP e Laravel non più supportate.
• Configurazione: debug attivo in produzione, segreti nel repository, backup esposti.

Quali domande ti farà il cliente sul software, e con quale prova rispondi?

Un cliente soggetto a NIS2 deve dimostrare di aver verificato i suoi fornitori, quindi le domande arrivano a chi scrive il software. Di solito sono sette, e per ognuna serve una prova che si prepara in poco tempo:

1. Di cosa è fatto il software? L'elenco delle dipendenze con le versioni e il risultato datato di composer audit e npm audit.
2. Chi può vedere cosa? La matrice ruoli-permessi e un test automatico per ogni riga, che prova l'azione vietata e si aspetta un rifiuto.
3. Si ricostruisce chi ha fatto cosa? Un log delle azioni sui dati sensibili (chi, cosa, quando, da dove), conservato fuori dal server dell'applicazione.
4. Come e in quanto tempo arrivano gli aggiornamenti? Una procedura scritta di una pagina, con la data dell'ultimo aggiornamento di sicurezza fatto davvero.
5. Il codice viene controllato prima della produzione? La pipeline di integrazione continua: test, analisi statica a un livello dichiarato, revisione di una seconda persona.
6. Qualcuno ha provato a entrare? Il rapporto dell'ultimo penetration test, con ambito, ruoli provati, vulnerabilità trovate e data di ogni correzione.
7. E se il fornitore sparisce? Il contratto che dice di chi è il codice, i dati esportabili dal pannello in un formato aperto, una copia dei sorgenti accessibile al cliente.

Le ho spiegate per esteso in un articolo su Red Hot Cyber: NIS2, il cliente ti farà 7 domande sul software: e dovrai avere le prove. Il penetration test è la sesta; le altre sei le preparo insieme a te, sul tuo codice.

La differenza con un pentester che non programma

Un test da solo ti lascia con una lista. Qui la lista si chiude nel codice, perché chi fa il test sviluppa Laravel da quattordici anni e negli ultimi anni ha trovato e chiuso vulnerabilità di controllo degli accessi in gestionali di organizzazioni con migliaia di utenti, con zero regressioni grazie ai test aggiunti prima di ogni modifica. Cosa ricevi:

1. Report con ogni vulnerabilità, gravità, come riprodurla e come correggerla.
2. Correzioni nel codice con test automatici che impediscono la regressione.
3. Analisi statica (PHPStan) e controllo delle dipendenze inseriti nella tua CI, così il controllo resta anche dopo.
4. Una pagina per il tuo consulente NIS2: cosa è stato verificato, quando, con che esito, pronta per l'audit.

Tempi, costi e il primo passo

Un penetration test applicativo su un gestionale web richiede da 3 a 8 giornate a seconda delle funzioni, a tariffa da 600 a 750 € al giorno, report compreso; le correzioni si preventivano dopo il report, per iscritto. Tra la richiesta e il 31 ottobre 2026 c'è meno tempo di quanto sembri: i test si mettono a calendario uno per volta.

Il primo passo è gratuito e non impegna: un'analisi per capire se sei nel perimetro NIS2, quale software è esposto e da dove partire. Ne esci con una lista scritta, anche se poi fai fare il test ad altri.

Contattaci.