Penetration test e Direttiva UE 2024/2853: evidenze difendibili per software e IA

La Direttiva (UE) 2024/2853 classifica software e sistemi di intelligenza artificiale come “prodotti” soggetti a responsabilità oggettiva. Questo cambia concretamente il profilo di rischio delle software house: in caso di danno causato da una vulnerabilità, il fabbricante risponde anche senza colpa, salvo riesca a dimostrare che il difetto non era individuabile con le conoscenze tecniche disponibili al momento dell’immissione sul mercato. Il penetration test è lo strumento che produce quella dimostrazione in forma documentata e difendibile.

Questo articolo fa parte della miniguida sulla Direttiva (UE) 2024/2853. Per il quadro generale consulta l’hub della direttiva, oppure approfondisci i capitoli su prodotti digitali e responsabilità del software.

Quando un prodotto software è considerato difettoso

La direttiva definisce difettoso il prodotto che non offre la sicurezza che il pubblico può legittimamente attendersi, tenendo conto anche dei requisiti di cibersicurezza applicabili. Per il software, questo significa che una vulnerabilità sfruttabile — anche se non ancora sfruttata — può essere sufficiente a qualificare il prodotto come difettoso al momento del rilascio.

Il penetration test, eseguito prima dell’immissione sul mercato e dopo ogni modifica sostanziale, consente di documentare che le difese del prodotto sono state verificate in modo sistematico e che le vulnerabilità note o ragionevolmente individuabili sono state affrontate. Senza questa documentazione, il fabbricante si trova a dover dimostrare l’assenza di difetti senza prove concrete.

Onere della prova e documentazione tecnica

La direttiva introduce un meccanismo di accesso alle prove che può obbligare il fabbricante a produrre la documentazione tecnica in sede di contenzioso. Se quella documentazione non esiste o è incompleta, il difetto si presume. Se invece esiste ed è aggiornata, il fabbricante può invocare l’esimente dello “stato delle conoscenze tecniche”: al momento del rilascio, il difetto non era individuabile con i metodi disponibili.

Un report di penetration test datato, firmato da un team indipendente e correlato alle versioni del software testate, è la forma più diretta di questa documentazione. Non è sufficiente un’analisi automatizzata: serve un’attività manuale e creativa che simuli il comportamento di un attaccante reale.

Responsabilità quando interviene un attaccante esterno

La direttiva mantiene la responsabilità del fabbricante anche quando il danno è causato congiuntamente dal difetto del prodotto e dall’azione di un terzo — per esempio un attaccante che sfrutta una vulnerabilità non corretta. La presenza di un hacker nella catena causale non esonera il produttore.

Il penetration test serve proprio a simulare questo scenario: se una vulnerabilità è individuabile con tecniche offensive standard, il fabbricante non può sostenere che fosse imprevedibile. Documentare che il test è stato eseguito — e che le vulnerabilità emerse sono state corrette — riduce concretamente l’esposizione a richieste di risarcimento per danni fisici, psicologici o distruzione di dati.

Penetration test o vulnerability assessment: quale serve alla direttiva

Il vulnerability assessment identifica le vulnerabilità note attraverso scansioni automatizzate e confronto con database pubblici. È utile per il monitoraggio continuo, ma non produce le evidenze che la direttiva richiede in sede di contenzioso.

Il penetration test aggiunge la componente manuale e offensiva: un tester esperto verifica se le vulnerabilità sono effettivamente sfruttabili nel contesto specifico del prodotto, concatena più debolezze per simulare un attacco reale e documenta il percorso seguito. È questa profondità di analisi — e la sua tracciabilità — che rende il penetration test lo strumento adeguato per rispondere alle richieste di prova previste dalla direttiva.

Per i prodotti software e le applicazioni web, il Web Application Penetration Testing di ISGroup copre questa esigenza con metodologie OSSTMM e OWASP, report strutturati e supporto alla remediation.

Approfondimenti utili

• Guida alla Direttiva (UE) 2024/2853 — il quadro completo sulla responsabilità oggettiva per i prodotti, inclusi software e IA.
• Prodotti digitali e direttiva UE — come la direttiva si applica a software, app e componenti digitali integrati.
• Responsabilità del software — analisi degli obblighi specifici per i fabbricanti di software.
• Vulnerability assessment e direttiva UE — quando il VA è sufficiente e quando serve il penetration test.

Domande frequenti

• Con quale frequenza va eseguito il penetration test per essere utile ai fini della direttiva?
• La direttiva non fissa una cadenza, ma il criterio è la modifica sostanziale: ogni rilascio che cambia funzionalità rilevanti per la sicurezza richiede un nuovo test. Un test eseguito su una versione precedente non copre le vulnerabilità introdotte successivamente.
• Il penetration test deve essere eseguito da un soggetto esterno?
• La direttiva non lo impone esplicitamente, ma in sede di contenzioso un report prodotto da un team indipendente ha un peso probatorio significativamente maggiore rispetto a un’analisi interna. L’indipendenza del tester rafforza la credibilità della documentazione.
• Il penetration test copre anche i sistemi di intelligenza artificiale?
• Sì, nella misura in cui il sistema IA è classificato come prodotto ai sensi della direttiva. Per i componenti IA integrati in software, il test deve includere i vettori di attacco specifici del modello — come l’iniezione di prompt o la manipolazione degli input — oltre alle vulnerabilità applicative tradizionali.
• Cosa succede se il penetration test individua vulnerabilità che non vengono corrette prima del rilascio?
• Il report documenta le vulnerabilità note al momento del rilascio. Se il fabbricante sceglie di rilasciare comunque il prodotto senza correggere quelle vulnerabilità, la documentazione diventa una prova a suo sfavore: dimostra che il difetto era noto e non è stato affrontato.