Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime, Analisi Vulnerabilità e Intelligenza Artificiale
L'articolo spiega le sette richieste che i clienti soggetti a NIS2 dovranno fare ai fornitori di software, dalla composizione del codice alle dipendenze, ai controlli di accesso, ai log delle attività, ai tempi di aggiornamento, ai test di sicurezza e alla continuità operativa. Vengono illustrate le prove pratiche da fornire, come elenchi di dipendenze, matrici ruoli‑permessi, log dettagliati, procedure di aggiornamento, pipeline CI, report di penetration test e contratti di proprietà del codice. Prepararsi a queste domande riduce i rischi e i costi di manutenzione.
NIS2 dalla parte di chi scrive il software: le sette cose che il cliente ti chiederà
Il 7 settembre su queste pagine si è detto ai responsabili delle aziende soggette a NIS2 di guardare ai fornitori come a un rischio da gestire. Giusto. Ma io il software lo scrivo e lo vendo, e la domanda che mi arriva è l’altra: “Il mio cliente è soggetto a NIS2. Cosa mi chiederà, e cosa devo essere in grado di mostrargli?”
La direttiva (UE) 2022/2555, recepita in Italia con il D.Lgs. 138/2024, mette nero su bianco tra le misure obbligatorie la sicurezza della catena di approvvigionamento e la sicurezza nell’acquisizione, nello sviluppo e nella manutenzione dei sistemi, compresa la gestione delle vulnerabilità. Il cliente non può più dire “il gestionale ce l’ha fatto una ditta esterna”. Deve dimostrare di aver verificato quella ditta. E la ditta, cioè noi, deve avere qualcosa da fargli vedere.
Non serve una certificazione. Servono sette risposte, ognuna con una prova che si può produrre in mezz’ora. Le elenco nell’ordine in cui le chiedono di solito.
Un gestionale moderno è per il 90% codice di altri: il framework, le librerie, i pacchetti del frontend. Se una di quelle librerie ha una vulnerabilità nota, il cliente ce l’ha in casa e non lo sa. Il rischio che le attenzioni si concentrino sull’anello più debole della catena lo ha ricordato l’attacco alla supply chain di npm dell’anno scorso.
La prova: l’elenco delle dipendenze con le versioni, generato dal gestore dei pacchetti (`composer show` per PHP, `npm ls` per JavaScript), e il risultato di `composer audit` e `npm audit` datato. Se si vuole fare una cosa in più, una SBOM in formato CycloneDX, che è un file e non un progetto. Costo: dieci minuti, ripetuti ogni mese in CI.
È la vulnerabilità più diffusa al mondo, e l’ho descritta qui a marzo: il Broken Access Control, cioè l’utente che cambia un numero nell’indirizzo e vede la fattura di un altro cliente. Il firewall non lo ferma, perché è un utente legittimo che fa una richiesta legittima.
La prova: la matrice ruoli-permessi (chi può leggere, chi può modificare, chi può cancellare, per ogni tipo di dato), e un test automatico per ogni riga di quella matrice che prova a fare la cosa vietata e verifica di ricevere un rifiuto. Se il test esiste, il controllo esiste. Se il test non esiste, il controllo è un’opinione.
NIS2 chiede di gestire gli incidenti e di notificarli in tempi stretti. Senza log applicativi non si notifica niente, perché non si sa cosa è successo. Il log del server web dice che qualcuno ha chiamato un indirizzo. Non dice che l’utente Rossi ha esportato l’anagrafica clienti alle 23:40 di domenica.
La prova: un log delle azioni sui dati sensibili (chi, cosa, quando, da dove), conservato fuori dal server dell’applicazione, con una durata dichiarata. E una dimostrazione: si chiede al fornitore “mostrami tutte le esportazioni dell’ultimo mese” e si guarda quanto ci mette.
La gestione delle vulnerabilità è scritta nella direttiva. Una vulnerabilità in una libreria viene pubblicata; da quel momento parte un cronometro. Il cliente vuole sapere chi lo guarda e cosa succede.
La prova: una procedura scritta di una pagina. Chi riceve gli avvisi (GitHub, Packagist, le mailing list del framework), entro quanti giorni si aggiorna in caso di gravità alta, come si rilascia (ambiente di prova, poi produzione, con la possibilità di tornare indietro), e come viene avvisato il cliente. Con la data dell’ultimo aggiornamento di sicurezza effettivamente fatto. Una procedura senza date è un modulo.
Qui il cliente si aspetta una risposta tecnica e di solito non la sa valutare. Aiutarlo è nel nostro interesse.
La prova: la pipeline di integrazione continua che si vede. Test automatici che girano a ogni modifica, con la percentuale di codice coperta; analisi statica (per PHP, PHPStan a un livello dichiarato) che blocca la pubblicazione se trova un errore; revisione del codice da parte di una seconda persona, tracciata. Non serve che il cliente capisca cosa fa PHPStan. Serve che veda che esiste, che è verde, e che quando è rosso il codice non esce.
Un penetration test applicativo non è un obbligo letterale della NIS2, ma è la risposta più corta alla domanda “come sapete che le misure funzionano”, che invece nella direttiva c’è: le procedure per valutare l’efficacia delle misure.
La prova: il rapporto dell’ultimo test, con la data, l’ambito (quali funzioni, quali ruoli utente), le vulnerabilità trovate, e per ognuna la correzione con la data. Un rapporto con zero vulnerabilità trovate su un’applicazione di dieci anni non è una buona notizia: è un test fatto male. Un rapporto con otto vulnerabilità corrette in tre settimane è quello che tranquillizza un cliente serio.
La continuità operativa è nell’articolo 21, e il cliente la applica anche al fornitore. Un gestionale che vive solo sui server di chi lo ha scritto, con dati che si esportano solo chiedendo per favore, è un rischio che il cliente adesso deve mettere per iscritto.
La prova: il contratto dice a chi appartiene il codice e dove sta; i dati si esportano in un formato aperto, dal pannello, senza chiedere; esiste una copia del codice sorgente accessibile al cliente, o depositata presso terzi, per il caso peggiore. Non è una clausola contro il fornitore. È la clausola che fa firmare il contratto.
Nessuna di queste sette cose è nuova. Sono quello che un team serio faceva già nel 2015. Quello che cambia con NIS2 è che il cliente le chiede per iscritto, e le tiene nel fascicolo per quando ACN o un auditor gliele chiederanno a sua volta, con le scadenze per le misure di base che ACN ha fissato per l’autunno 2026.
Per chi vende software a queste aziende il conto è semplice. Prepararsi costa qualche giornata: un pomeriggio per l’inventario delle dipendenze e la procedura di aggiornamento, qualche giorno per portare i test e l’analisi statica in CI se non ci sono, un penetration test a intervalli. Non prepararsi costa il cliente, perché il suo responsabile della sicurezza, con la direttiva in mano, preferirà il fornitore che ha le sette risposte pronte.
E c’è un effetto collaterale che nessuno mette nel preventivo: un software con i test verdi, le dipendenze aggiornate e i log a posto si rompe meno, si modifica più in fretta, e costa meno da mantenere. La NIS2 è la scusa. Il beneficio ce lo si tiene dopo.
Sono aperte le iscrizioni al corso in Live Class “AGENTIC AI CYBER OPERATIONS (AACO)”. La cybersecurity sta entrando nell'era degli AI Agent: sistemi capaci di ragionare, utilizzare strumenti, orchestrare attività e portare avanti operazioni complesse. Ma come funzionano davvero dal punto di vista tecnico? Con AACO, Red Hot Cyber porta i professionisti della cybersecurity a toccare con mano gli strumenti agentici, attraverso una Live Class in italiano con 15 ore di formazione, laboratori pratici e scenari reali. Agentic AI, Tool Calling, MCP, orchestrazione di agenti, OSINT, Threat Intelligence, vulnerability assessment e automazione delle operazioni di cybersecurity. Non un corso per imparare a usare un chatbot, ma un percorso per capire, costruire e governare sistemi agentici applicati alla sicurezza informatica.
Partenza: Sabato 7 novembre
Programma completo e iscrizioni: https://www.redhotcyber.com/linksSk2L/academy-agentic-ai
Per info: 379 163 8765 [email protected]