Un tempo i software non sicuri costavano di più. Ora non possono più essere venduti.

Due domande, in ordine. Controllare la sicurezza alla fine di uno sviluppo funziona davvero? E se no, cosa deve succedere invece?

CVE-1999-0001, la prima voce dell’elenco Common Vulnerabilities and Exposures, il registro pubblico in cui vengono annotate le vulnerabilità software divulgate, è stata la prima vulnerabilità mai registrata. Una sola voce. Nel 2025 quel database ne ha registrate 48.185 nuove in un solo anno, un record, con un aumento di oltre il 20% rispetto all’anno precedente, secondo il 2025 CVE Data Review di JerryGamblin. La superficie di attacco non è semplicemente cresciuta. È esplosa, e gran parte di essa risale a requisiti di sicurezza che nessuno ha mai messo per iscritto.

La regolamentazione è cresciuta di pari passo, ma più lentamente, e poi all’improvviso non più lentamente affatto. Il GDPR è arrivato nel 2018 con un principio: la protezione dei dati fin dalla progettazione. Era legge, ma suonava come un buon consiglio con una sanzione allegata. Poi sono arrivati la NIS2, vincolante da ottobre 2024, e il Cyber Resilience Act, in vigore in modo graduale fino a dicembre 2027. Questi non suonano come consigli. La NIS2 rende i dirigenti personalmente responsabili delle carenze nella gestione del rischio di cybersicurezza, secondo la Commissione europea. Il Cyber Resilience Act va oltre: da dicembre 2027, un prodotto privo di una marcatura CE che dimostri che è stato progettato in modo sicuro fin dall’inizio non potrà essere venduto legalmente in nessun paese dell’UE, secondo la sintesi del CRA pubblicata dalla stessa Commissione europea. Non una multa. Non un avvertimento. Nessun accesso al mercato.

L’anno scorso un ospedale ha lanciato un nuovo portale per i pazienti. Dopo tre settimane, un ricercatore ha scoperto che modificando un solo numero nella barra degli indirizzi del browser si potevano visualizzare le cartelle cliniche di un altro paziente. Il documento dei requisiti conteneva una riga per il «login del paziente». Non conteneva nessuna riga su cosa quel login potesse esporre. Nessuno aveva messo per iscritto quella parte, quindi nessuno l’ha realizzata.

Controllare la sicurezza alla fine funziona davvero?

No, e il motivo è strutturale, non una questione di impegno. Un documento dei requisiti dice agli ingegneri cosa costruire. Se non specifica cosa il software non deve mai fare, esporre dati, omettere un audit trail, non rispettare uno standard di crittografia, allora nulla a valle verifica nemmeno queste cose. I test individuano i bug rispetto a una specifica. Non possono individuare l’assenza di una regola che non è mai stata scritta.

Questo è il divario tra «testare la sicurezza prima del rilascio» e «specificare la sicurezza prima di costruire», e la maggior parte delle aziende fa ancora la prima cosa. Sembra diligenza. Il risultato è un report di penetration test una settimana prima del lancio, un elenco di rilievi e una corsa per correggere ciò che l’architettura dà già per scontato. A quel punto il modello dei dati è definito, le integrazioni di terze parti sono collegate e metà dei rilievi ottiene una deroga invece di una correzione, perché ricostruire costa caro e la data di lancio non si sposta.

Nelle motivazioni della proposta originale del Cyber Resilience Act del 2022, la Commissione europea citava dati secondo cui circa il 60% dei prodotti sul mercato veniva rilasciato con vulnerabilità note già presenti al lancio, e due terzi degli attacchi informatici risalivano a una vulnerabilità che avrebbe potuto essere eliminata in fase di progettazione. «L’Europa è forte solo quanto il suo anello più debole», ha dichiarato Thierry Breton, Commissario europeo per il Mercato interno, quando è stato proposto il Cyber Resilience Act. Non stava parlando di costi. Stava parlando di quali prodotti possono esistere sul mercato europeo.

Come si presenta concretamente la specifica in fase di definizione dei requisiti?

Non un documento dei requisiti più lungo. Uno diverso, scritto con i responsabili della sicurezza e della conformità presenti nella stanza, non che lo revisionano dopo.

1. Scrivete il vincolo accanto alla funzionalità, non in un documento separato che nessuno legge. «Gli utenti possono reimpostare la propria password» sta accanto a «i token di reimpostazione scadono dopo 15 minuti e vengono registrati con un timestamp e l’ID del richiedente», perché la seconda riga è ciò che gli obblighi di notifica degli incidenti della NIS2 richiedono effettivamente, e non può essere ricostruita a posteriori dal codice funzionante.
2. Indicate la normativa da cui deriva il requisito. Non «crittografare i dati sensibili», ma «crittografare i dati in transito e a riposo, ai sensi dell’Allegato I del Cyber Resilience Act, perché questo prodotto viene fornito con una connessione di rete». Un requisito senza una fonte indicata è il primo a essere tagliato quando la scadenza si sposta.
3. Coinvolgete nella revisione dei requisiti, non solo nella revisione di sicurezza, qualcuno che conosca la normativa. Quando un responsabile della conformità vede una specifica, l’architettura è di solito già stata scelta, e a quel punto «aggiungere questo» significa sempre «ricostruire questo».
4. Trattate il documento dei requisiti come la prova, non solo come il piano. Ai sensi del CRA, i produttori devono dimostrare in che modo un prodotto soddisfa i propri requisiti essenziali. Un documento dei requisiti che indica già il vincolo e la sua fonte normativa costituisce gran parte di quella prova, scritta una volta sola e non ricostruita sotto scadenza prima di un audit.

È proprio per questo livello che è stata creata la practice AI-Driven Compliance di Calsoft: monitoraggio continuo dei controlli e automazione delle evidenze che continuano a dimostrare che un requisito è ancora soddisfatto molto tempo dopo il lancio, anziché un controllo una tantum prima di esso. Una volta che un vincolo è scritto nei requisiti, è così che si dimostra, in modo continuativo, che il sistema lo rispetta ancora, e non solo che lo rispettava il giorno in cui qualcuno ha dato l’approvazione.

L’ospedale di questa storia alla fine ha corretto il bug nel controllo degli accessi. La correzione ha richiesto un pomeriggio. Riconquistare la fiducia dei pazienti le cui cartelle cliniche erano state esposte ha richiesto molto più tempo, e nessuna patch può intervenire su quella parte.

Le aziende che gestiranno bene tutto questo nel 2027 non saranno quelle che avranno superato la revisione di conformità. Saranno quelle per cui la revisione non avrà trovato nulla da segnalare, perché i requisiti lo avevano già detto per primi.

FAQ

Perché i requisiti di sicurezza dovrebbero essere definiti nelle prime fasi dell’SDLC?

I test verificano solo ciò che è stato costruito rispetto a una specifica. Se i requisiti di sicurezza non compaiono mai in quella specifica, nulla a valle ne rileva l’assenza. Ai sensi del Cyber Resilience Act, un requisito mancante non è un bug scoperto tardi, ma una lacuna di conformità che può escludere completamente un prodotto dal mercato dell’UE.

Come si trasformano i requisiti di conformità in requisiti software?

Scrivete il linguaggio della normativa direttamente nella specifica, non come nota a piè di pagina. Invece di «crittografare i dati sensibili», scrivete «crittografare i dati in transito e a riposo, ai sensi dell’Allegato I del Cyber Resilience Act». Un requisito senza una fonte normativa indicata è di solito il primo a essere tagliato quando una scadenza si sposta.

Come si mantengono aggiornati i requisiti di sicurezza e conformità quando le normative cambiano?

Trattate il documento dei requisiti come una prova viva, non come un’approvazione una tantum. La NIS2 e il Cyber Resilience Act introducono gli obblighi gradualmente nell’arco di diversi anni, quindi è il monitoraggio continuo, non la revisione periodica, a dimostrare che un sistema soddisfa ancora un requisito dopo che la normativa su cui si basa è cambiata.