PLD 2024: Vulnerability management e gestione CVE.

Cosa è "diligenza ragionevole", quali tempi sono difendibili in giudizio, cosa si può e non si può trasferire al cliente.

Quarto articolo della serie sulla PLD 2024 e le software house italiane.

Nota epistemica: ricostruzione del testo della direttiva applicato a modelli operativi tipici. Non costituisce parere legale.

Nei primi tre articoli della serie ho mappato i cambi strutturali, gli scenari di sviluppo e l'asse temporale decennale. In quel quadro ho introdotto, nel secondo articolo, le tre situazioni operative trasversali che ogni software house affronta nel decennio di responsabilità: cosa fare quando emerge una CVE, cosa fare se il cliente rifiuta la patch, cosa fare se un componente open source viene abbandonato.

Quell'introduzione era cosa fare. Questo articolo è con quale rigore, in quali tempi, fino a che punto contrattualizzabile. Tre dimensioni che decidono se la gestione CVE di una SH è difendibile in giudizio o se è esposizione costruita senza accorgersene.

La prima dimensione è lo standard giuridico della "diligenza ragionevole" come parametro PLD. Non è una postura, non è "abbiamo fatto quello che potevamo": è uno standard oggettivo che il giudice ricostruisce ex post sulla base di pratiche di settore documentate.

La seconda dimensione è il tempo. La direttiva non scrive numeri. La pratica sì. E sono numeri che la giurisprudenza in formazione userà come parametro per misurare la diligenza, indipendentemente da quello che la SH avrebbe voluto fare.

La terza dimensione è il perimetro del trasferibile. Una parte del lavoro di vulnerability management si può legittimamente contrattualizzare in capo al cliente. Una parte no, e una clausola che ci provi è inopponibile in giudizio. Il confine è nell'Art. 15 della direttiva, e va conosciuto prima di scrivere la prossima offerta commerciale.

"Diligenza ragionevole" non è "buona volontà"

L'esonero di responsabilità del fabbricante in PLD passa per due articoli principali della direttiva 2024/2853. L'articolo 11 disciplina i casi in cui il fabbricante è esonerato — tra cui, alla lettera e), il caso in cui "lo stato delle conoscenze scientifiche e tecniche al momento in cui il prodotto è stato immesso sul mercato non era tale da permettere di scoprire l'esistenza del difetto", noto in dottrina come development risks defence. L'articolo 9 disciplina la prova: nei contenziosi PLD c'è un sistema di presunzioni che agevola il danneggiato, ed è il fabbricante che deve dimostrare di rientrare in una delle ipotesi di esonero.

Il punto su cui la pratica italiana tende a sbagliare è il significato concreto del termine "diligenza ragionevole". Non è una formula di stile. È uno standard oggettivo, ricostruibile ex post dal giudice sulla base di pratiche di settore documentate. Significa due cose simultaneamente.

Prima: la diligenza non è quello che il fabbricante intendeva fare. È quello che il fabbricante ha effettivamente fatto, dimostrato con evidenza documentale. Una SH che gestisce CVE "con cura" senza traccia documentale del processo non ha gestito CVE — ha gestito CVE in modo non dimostrabile, che ai fini PLD coincide con non averle gestite.

Seconda: il livello di diligenza richiesto non è quello che il fabbricante ritiene proporzionato alla propria struttura. È quello esigibile da un operatore competente nel settore. Una SH italiana piccola non si difende mostrando di aver fatto quello che fanno le SH italiane piccole. Si difende mostrando di aver fatto quello che è ragionevolmente esigibile da chi sviluppa software in quel segmento di mercato a livello europeo, secondo lo stato dell'arte disponibile.

Questa distinzione ha conseguenze pratiche dirette. Se il segmento di riferimento della SH è poco maturo nella gestione vulnerabilità — ed è il caso del segmento PMI italiano dello sviluppo software — la diligenza ragionevole non è la media del segmento. È lo standard di pratica accessibile a un operatore competente, che è significativamente più alto. La SH diligente è quella che eccede la media del segmento, perché la media del segmento è strutturalmente sotto la soglia di adempimento PLD.

Lo stato dell'arte come parametro misurabile

Lo stato dell'arte non è un concetto astratto. È costruito dai framework operativi riconoscibili e dai riferimenti tecnici pubblici che il settore della sicurezza adotta come pratica corrente. Per il vulnerability management ci sono quattro famiglie di riferimento che definiscono lo standard concreto.

ISO/IEC 27001:2022 include controlli specifici sul tema. Il controllo A.5.7 (Threat intelligence), nuovo nella revisione 2022, richiede di raccogliere e analizzare informazioni sulle minacce di sicurezza in modo strutturato. Il controllo A.5.30 (ICT readiness for business continuity) richiede di mantenere la capacità di rispondere agli eventi di sicurezza. Il controllo A.8.8 (Management of technical vulnerabilities) è il riferimento puntuale: il fabbricante deve identificare le vulnerabilità tecniche dei propri sistemi, valutarne il rischio, e adottare misure appropriate. Una SH certificata ISO 27001:2022 ha un riferimento documentale forte. Una SH non certificata può comunque dimostrare di seguire equivalenti, ma deve avere il processo strutturato e tracciato.

La NIS2 (direttiva UE 2022/2555), dove applicabile alla SH o ai suoi clienti, prevede obblighi specifici di gestione del rischio cyber e di reporting degli incidenti. Anche per le SH non direttamente soggette, la NIS2 contribuisce a costruire lo stato dell'arte perché definisce pratiche che il regolatore europeo ha qualificato come standard minimo per i settori critici.

Il CVSS (Common Vulnerability Scoring System) sviluppato da FIRST è il sistema di scoring standard delle vulnerabilità. Ogni CVE riceve uno score CVSS che ne misura severity da 0.0 a 10.0. È il riferimento che il giudice userà per stabilire se una vulnerabilità era critica, alta, media o bassa al momento della pubblicazione.

Il CISA Known Exploited Vulnerabilities (KEV) catalog mantenuto dall'agenzia di cybersecurity statunitense lista le vulnerabilità per cui è documentato un exploit attivo in the wild. Una CVE che è in KEV catalog non è una vulnerabilità teorica: è una vulnerabilità attivamente sfruttata. Ignorarla per settimane non è gestione: è esposizione consapevole. ENISA, l'agenzia europea per la cybersecurity, pubblica advisories e linee guida che sono riferimento parallelo a livello europeo.

Questi quattro riferimenti — ISO 27001:2022, NIS2, CVSS+KEV, ENISA — costruiscono insieme lo stato dell'arte del vulnerability management su cui il giudice misurerà la diligenza ragionevole della SH. La SH che non li conosce non sta facendo gestione delle vulnerabilità in senso PLD-rilevante. Sta facendo qualcos'altro, che verrà valutato per quello che è: assenza di processo.

Tempi difendibili: quanto è "tempestivo"

La direttiva non quantifica i tempi di risposta alle vulnerabilità. La pratica sì. E i tempi che la pratica considera difendibili sono ricavati dai framework di riferimento, calibrati per severity. Vale la pena renderli espliciti, perché sono i numeri su cui il giudice ragionerà.

Quattro classi operative basate sulla combinazione di CVSS score e flag KEV.

Classe 1 — Critical attiva. CVSS 9.0 o superiore, e CVE presente nel KEV catalog (exploit attivo documentato). È lo scenario di massima urgenza. I tempi difendibili sono: notifica formale al cliente entro 24-48 ore dalla pubblicazione della CVE, messa a disposizione di una mitigazione tecnica (workaround, configurazione difensiva) entro 7 giorni, patch applicata entro 30 giorni. Una SH che gestisce uno scenario Classe 1 in due settimane senza mitigazione intermedia è esposta. Una SH che documenta intervento entro 48 ore con audit trail è difendibile.

Classe 2 — Critical o High. CVSS 7.0-8.9, oppure CVSS 9.0+ non in KEV. Vulnerabilità seria ma senza exploit documentato attivo. Tempi: notifica al cliente entro 5 giorni lavorativi, patch disponibile entro 60-90 giorni a seconda della complessità di sviluppo della patch.

Classe 3 — Medium. CVSS 4.0-6.9. Notifica nel ciclo regolare di comunicazione (mensile o trimestrale a seconda del contratto), patch nel ciclo manutentivo programmato.

Classe 4 — Low. CVSS sotto 4.0. Gestione di routine, documentata negli stessi cicli di Classe 3. La rilevanza PLD è marginale ma la traccia documentale comunque richiesta.

Queste classi non sono regole rigide. Sono parametri orientativi che riflettono la pratica del settore della sicurezza. Possono essere modificate dal contesto: una CVE Classe 3 su un sistema sanitario in produzione può richiedere tempi Classe 1; una CVE Classe 2 su un componente non esposto a internet può tollerare tempi più ampi. Il punto non è applicare i numeri come tabella: il punto è avere parametri scritti e documentare l'aderenza, o lo scostamento motivato.

Una nota essenziale sulla documentazione. I tempi difendibili sono difendibili in giudizio. Significa che la SH deve poter esibire: il momento di pubblicazione della CVE (data e fonte), il momento della valutazione interna di rilevanza per il sistema cliente (data e responsabile), il momento e il contenuto della notifica al cliente (formale, scritta), il momento di disponibilità della mitigazione e della patch (e relativa comunicazione al cliente), il momento di applicazione effettiva (e se il cliente ha rifiutato, il rifiuto documentato per iscritto). Senza questa catena documentale, i tempi non si dimostrano. E se non si dimostrano, in giudizio sono come se non fossero mai stati rispettati.

Cosa si può legittimamente trasferire al cliente

L'autonomia contrattuale ha uno spazio. Non tutto il lavoro di vulnerability management va sostenuto gratuitamente dalla SH. Una parte del lavoro è legittimamente trasferibile al cliente come prestazione separata, oppure come operatività che il cliente assume con il proprio team.

Si possono trasferire al cliente, come prestazione separata pagata, le attività di esecuzione tecnica successive alla notifica. L'applicazione della patch sull'ambiente cliente, il testing in produzione, il rollback in caso di regressioni, la comunicazione strutturata agli utenti finali del cliente: sono prestazioni di delivery, hanno un costo specifico, e possono essere contrattualizzate. La distinzione che conta è: la SH come fabbricante mette a disposizione la patch e le istruzioni tecniche; l'esecuzione sull'ambiente cliente è prestazione professionale separata, da remunerare se non coperta da un contratto di manutenzione attivo.

Si può trasferire al cliente, come responsabilità, la decisione informata di non applicare la patch, con tutte le conseguenze. Il cliente che, dopo notifica formale che include severity, rischio specifico, finestra di vulnerabilità e proposta operativa, decide di non procedere alla patch, assume il rischio del proprio rifiuto. La SH che ha documentato notifica + acquisizione del rifiuto formale + (idealmente) controfirma del cliente sull'accettazione del rischio si è messa in posizione di esonero rispetto al danno che dovesse derivare dalla CVE non patchata. Non è automatico, ma è la condizione necessaria.

Si può trasferire al cliente, in scenari specifici, l'operatività del deploy delle patch. Caso frequente nel mercato enterprise: il cliente ha un team IT proprio che esegue il deploy delle patch nei propri ambienti, secondo le proprie procedure di change management. È contrattualizzabile, e in alcuni casi necessario, perché la SH non ha accesso operativo agli ambienti produttivi del cliente. Il delta che si trasferisce è il deploy operativo. La SH resta titolare degli atti a monte.

Tutti questi trasferimenti sono legittimi se rispettano due condizioni: sono scritti nel contratto in modo esplicito (non sottintesi, non desunti da prassi), e non superano il limite che la direttiva pone alla libertà contrattuale.

Cosa NON si può trasferire al cliente: l'Articolo 15

L'articolo 15 della direttiva 2024/2853 è il limite. La norma stabilisce che la responsabilità del fabbricante verso il danneggiato non può essere limitata o esclusa contrattualmente, e che ogni clausola in tal senso è nulla. È principio antico — c'era già nella direttiva del 1985 — ma con la PLD 2024 acquisisce rilievo nuovo perché il perimetro del prodotto, e quindi del fabbricante, si è esteso al software.

Tradotto sul vulnerability management: tra la SH e il cliente si può pattuire chi paga le prestazioni di delivery (l'esecuzione della patch, il deploy, il testing). Tra la SH e il consumatore finale danneggiato, il fabbricante resta fabbricante. Una clausola che dica "il monitoring CVE è in capo al cliente" o "la valutazione della rilevanza delle vulnerabilità è responsabilità del cliente" o "la notifica delle CVE rilevanti al cliente finale è competenza del cliente" è clausola che prova a escludere atti del fabbricante. Verso il consumatore finale è inopponibile, e in giudizio il fabbricante risponde come se la clausola non ci fosse.

Quattro atti del vulnerability management appartengono in modo strutturale al fabbricante e non sono contrattualmente trasferibili.

Il primo è il monitoring CVE attivo sui componenti del prodotto immesso. È atto di sorveglianza post-immissione che la direttiva richiede al fabbricante come parte della diligenza. Non si può scaricare sul cliente — il cliente in molti casi non ha nemmeno visibilità tecnica completa sui componenti incorporati.

Il secondo è la valutazione della rilevanza della CVE per la specifica installazione cliente. È valutazione tecnica del fabbricante, che conosce il prodotto, l'architettura, le dipendenze. Un cliente non ha gli elementi per fare questa valutazione, e una clausola che lo pretenda è clausola che sposta sul cliente una responsabilità di fatto inesigibile.

Il terzo è la notifica formale al cliente con descrizione del rischio specifico, severity, finestra temporale, opzioni di mitigazione. È atto di comunicazione del fabbricante verso il proprio cliente, è documentale, è la base di ogni successiva difesa di diligenza.

Il quarto è la messa a disposizione della patch o delle istruzioni di mitigazione quando tecnicamente disponibili. Se la patch esiste a monte (rilasciata dal vendor del componente), il fabbricante la mette a disposizione del cliente. Se la patch va prodotta dal fabbricante stesso (caso di fork, componente custom, integrazione propria), il fabbricante la produce nei tempi della classe di severity. Una clausola che dica "la disponibilità delle patch dipende dalla volontà del fabbricante e non è oggetto di obbligo" è clausola che esclude un atto strutturale del fabbricante. Inopponibile.

Il perimetro del trasferibile, in altre parole, è il delivery operativo. Il perimetro del non-trasferibile è la sorveglianza e la comunicazione strutturata. La distinzione va scritta nei contratti in modo che la separazione sia chiara. Senza separazione, si rischia di scrivere clausole che si pensano di trasferimento e sono in realtà clausole di esclusione — nulle in giudizio.

Il caso del cliente enterprise con IT proprio

Il caso pratico più frequente in cui si applica una contrattualizzazione corretta del trasferibile è quello del cliente enterprise con team IT interno. Il cliente ha amministratori di sistema, ha un processo di change management, ha finestre di manutenzione regolamentate, vuole gestire internamente il deploy delle patch.

La SH può assumere il deploy operativo come responsabilità del cliente. Ma la struttura del processo va scritta con cura. La sequenza che regge è questa.

Il fabbricante mantiene: monitoring CVE continuo sui componenti del prodotto, valutazione di rilevanza per ogni CVE pubblicata, notifica formale al cliente entro i tempi della classe di severity, messa a disposizione della patch o delle istruzioni di mitigazione tecniche complete (versioni, dipendenze, prerequisiti, test di regressione previsti).

Il cliente assume: presa in carico della notifica entro tempo definito, deploy della patch nelle proprie finestre di manutenzione, testing in ambiente cliente, comunicazione al fabbricante dell'esito (patch applicata, problemi riscontrati, motivazioni di mancata applicazione se è il caso). Il cliente può rifiutare il deploy, ma assume formalmente il rischio.

Cosa NON si scrive in questa contrattualizzazione: che il cliente è responsabile del monitoring, della valutazione, della notifica. Questi restano del fabbricante. Se il cliente ha competenze interne sufficienti per voler ricevere anche dati grezzi sul monitoring, può essere previsto come informazione aggiuntiva — ma il monitoring formale, l'atto, è del fabbricante.

In più, va prevista una clausola di terminazione della manutenzione per il caso in cui il cliente rifiuti sistematicamente le patch. A un certo punto, il fabbricante che mantiene attiva la propria responsabilità su un sistema che il cliente non aggiorna costruisce esposizione che non ha modo di ridurre. La clausola corretta prevede che dopo N rifiuti formali (di Classe 1 in particolare), il fabbricante può dichiarare cessata la manutenzione attiva per quel sistema specifico, con notifica formale e con assunzione del rischio residuo da parte del cliente. È la simmetria contrattuale che protegge il fabbricante dal cliente strutturalmente non collaborativo.

Tre domande per il GM

Prima domanda: hai un audit trail del processo CVE degli ultimi 12 mesi? Se la risposta è no — se la gestione CVE è frammentata tra email, conversazioni, decisioni informali — il tuo standard di diligenza non è dimostrabile. In giudizio, non dimostrabile coincide con non esistente.

Seconda domanda: hai parametri tempistici scritti per severity, e li applichi? Se la risposta è no — se i tempi di reazione dipendono dalla disponibilità degli sviluppatori, dalla pressione del cliente, dalla coincidenza con altri progetti — il giudice ricostruirà i tempi sui framework di riferimento, non sulle intenzioni della tua SH. E i framework di riferimento sono i numeri che ho enunciato sopra.

Terza domanda: le tue clausole CVE stanno dentro o fuori l'Art. 15 PLD? Se non lo sai, sono probabilmente fuori. Una revisione delle clausole standard delle SH italiane fatta con criterio Art. 15 fa emergere, nella maggior parte dei casi, formulazioni che tentano di trasferire al cliente atti strutturali del fabbricante. Quelle clausole non proteggono. Sono passibili di nullità, e in giudizio espongono la SH come se le clausole non ci fossero.

Considerazione di chiusura

La diligenza ragionevole non è una postura. È un processo strutturato, parametrato in tempi, documentato in audit trail, e supportato da contrattualistica che rispetta il perimetro dell'Art. 15. Le SH che oggi gestiscono CVE come reazione caso per caso costruiscono esposizione che si manifesta solo nel decennio successivo. Le SH che adottano un processo strutturato e una contrattualistica corretta escono dal regime PLD come operatori difendibili.

Il livello operativo è quello trattato in questo articolo. Il livello architetturale — come si progetta un sistema affinché il vulnerability management sia possibile e tracciabile in produzione — è altra materia, trattata da altre voci nel dibattito europeo. I due livelli si incontrano nei progetti concreti: l'architettura crea le condizioni di esercizio della diligenza, il processo operativo la realizza, la contrattualistica ne definisce il perimetro. Una SH che pensa di avere solo un problema tecnico, o solo un problema legale, o solo un problema di processo, sta sottostimando lo scope. Ne ha tre simultanei, e i tre dialogano.

Il prossimo articolo della serie affronta la RACI come strumento di governance interna alla software house: quanto protegge davvero la responsabilizzazione formale dei ruoli, e quanto invece è illusione che si dissolve nel primo contenzioso PLD reale.