Benvenuto. Un prodotto software si può valutare in due modi. Il primo è chiedersi se funziona: fa quello che promette, non si blocca, piace a chi lo usa. Il secondo è chiedersi che cosa succede quando qualcuno prova a fargli fare quello che non deve: leggere dati altrui, aprire una porta che doveva restare chiusa, diventare il punto da cui si entra nella rete di un cliente. Per decenni il mercato ha premiato quasi solo il primo modo, e il secondo è stato trattato come un costo da rimandare a dopo il rilascio.

Quel "dopo" sta finendo. Il Cyber Resilience Act, il Regolamento (UE) 2024/2847, fa della sicurezza un requisito per mettere in vendita un prodotto con elementi digitali nell'Unione, come lo è da tempo la sicurezza elettrica: requisiti essenziali, valutazione della conformità, marcatura CE, documentazione tecnica, obblighi che continuano per tutto il periodo di assistenza. Il regolamento è in vigore dal 10 dicembre 2024 e una parte si applica già: dall'11 settembre 2026 i fabbricanti devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che riguardano i loro prodotti. Il resto si applica dall'11 dicembre 2027.

Questo percorso insegna a fare il lavoro che quegli obblighi presuppongono, ed è lo stesso lavoro che i riferimenti tecnici descrivono da anni: il Secure Software Development Framework del NIST, i progetti OWASP, la classificazione delle debolezze del software di MITRE. Non è un corso di diritto per sviluppatori né un catalogo di strumenti: è un metodo, applicato a ogni fase in cui una decisione rende il prodotto più o meno difendibile.

Attraversa tutto il percorso una domanda sola, la stessa che porrebbe un cliente attento, un'autorità di vigilanza o un attaccante: come fai a sapere che è sicuro, e come lo dimostri? Ogni modulo produce un pezzo della risposta - la valutazione del rischio, i requisiti, le scelte nel codice, la distinta dei componenti, le prove, la politica sulle vulnerabilità - e alla fine quei pezzi sono la documentazione tecnica che il regolamento chiede.

Le esercitazioni seguono un caso unico: Lariotech, un fabbricante italiano di serrature connesse con applicazione e servizio cloud, alle prese con il suo primo prodotto da mettere in regola. Un caso costruito, ma con i problemi veri di chi sviluppa oggi.

Obiettivi del percorso

Al termine del percorso sarai in grado di:

• spiegare perché i difetti di sicurezza arrivano in produzione e che cosa significa sicurezza fin dalla progettazione, e collocare un prodotto e un'organizzazione nel quadro del Cyber Resilience Act, della NIS2 e della responsabilità per danno da prodotti difettosi (Modulo 1);
• condurre e documentare una valutazione del rischio di cybersicurezza di un prodotto e trasformarla in requisiti di sicurezza verificabili (Modulo 2);
• modellare le minacce di un sistema con diagrammi dei flussi di dati e STRIDE, e ricavarne contromisure e impostazioni sicure per impostazione predefinita (Modulo 2);
• riconoscere e prevenire nel codice le classi di difetti più frequenti e più gravi, usando correttamente le classifiche OWASP e CWE, e condurre una revisione del codice orientata alla sicurezza (Modulo 3);
• governare i componenti di terzi: dovuta diligenza, analisi della composizione, distinta dei componenti software, integrità della build e della pipeline (Modulo 4);
• scegliere e combinare le tecniche di verifica sapendo che cosa ciascuna non trova, e costruire una pipeline con soglie di rilascio sostenibili e prove conservate (Modulo 5);
• gestire le vulnerabilità dopo il rilascio - divulgazione coordinata, triage, correzione, avvisi, aggiornamenti - e rispettare tempi e contenuti delle segnalazioni obbligatorie del Cyber Resilience Act (Modulo 6).

A chi si rivolge e prerequisiti

Il percorso si rivolge a chi progetta, scrive, verifica o mette in vendita software: sviluppatori e capi progetto, architetti, responsabili di prodotto e di qualità, ingegneri DevOps e di piattaforma, responsabili della sicurezza di aziende che producono software, applicazioni o dispositivi connessi. È utile anche a chi, in un soggetto essenziale o importante ai sensi della NIS2, deve valutare il software che acquista o che sviluppa internamente.

Prerequisiti. Serve saper leggere del codice e conoscere a grandi linee come funziona un'applicazione web o un servizio in rete; gli esempi sono brevi e commentati, e non richiedono un linguaggio in particolare. I concetti di base di rischio e di minaccia li danno i Fondamenti di Information Security. Chi deve governare la conformità più che scrivere il codice trova il Cyber Resilience Act, dal lato della governance, anche nel Modulo 9 di Cybersecurity Governance, Risk & Compliance; la gestione degli incidenti in generale è materia di Gestione e risposta agli incidenti.

Modalità di svolgimento

Il percorso si svolge interamente online, in modalità asincrona: puoi studiare quando vuoi, al tuo ritmo, da qualsiasi dispositivo. La durata complessiva stimata è di 26 ore, da distribuire entro il termine di completamento indicato più avanti.

Ogni modulo è organizzato in quattro lezioni e due verifiche:

1. Lezione. Una trattazione ragionata dell'argomento, con schemi, esempi e casi concreti.
2. Test di verifica. Domande a risposta chiusa sull'intero modulo. Il superamento richiede almeno il 70%; i tentativi sono illimitati e vale il voto migliore. Al termine di ogni tentativo ricevi la spiegazione puntuale di ogni risposta, anche di quelle corrette.
3. Esercitazione. Un caso da attraversare scegliendo: ogni decisione apre una strada diversa e l'esito dipende da quello che hai scelto, con la spiegazione di che cosa sarebbe successo altrimenti. La valutazione è automatica e si può rifare quante volte si vuole.

Progressione. I 6 moduli si affrontano in sequenza: ciascun modulo si sblocca soltanto dopo aver superato il test del modulo precedente. Le esercitazioni non bloccano l'avanzamento, ma sono parte integrante del percorso e della valutazione complessiva.

Test finale e certificato

Superati i test di tutti i moduli si sblocca il test finale: 30 domande estratte casualmente dagli argomenti dell'intero percorso, con la stessa soglia del 70%. I tentativi sono tre, a distanza di almeno una settimana l'uno dall'altro: se nessuno raggiunge la soglia, il percorso riparte dal primo modulo. Al superamento ottieni il certificato del percorso, scaricabile in PDF, con un codice univoco che ne consente la verifica di autenticità.

Avvertenza

I contenuti sono aggiornati a ottobre 2026. Tre avvertenze specifiche di questa materia.

La prima, sul regolamento. Il Cyber Resilience Act si applica per intero dall'11 dicembre 2027 e molti dei suoi strumenti di attuazione - norme armonizzate, orientamenti della Commissione, il decreto italiano di adeguamento - sono ancora in lavorazione. Il percorso dice per ciascuno che cosa esiste e che cosa no, con la data della verifica; prima di una decisione di conformità si controlla lo stato corrente. Il percorso non costituisce consulenza legale.

La seconda, sugli standard. Le classifiche e i framework citati cambiano edizione: si cita sempre l'edizione, e si legge per quello che misura. Una classifica di debolezze non è un elenco di requisiti, e nessuna lista di controllo da sola rende un prodotto conforme.

La terza, sugli esempi. I frammenti di codice servono a far vedere un difetto e la sua correzione, non a essere copiati in produzione; il percorso nomina categorie di strumenti e non prodotti. Gli scenari delle esercitazioni sono costruiti; i casi reali sono verificati alla fonte e collegati.

Supporto

Nel forum Annunci trovi le comunicazioni del docente. Per domande sui contenuti o sulle esercitazioni usa i canali indicati dal tuo referente per la formazione.