La responsabilità penale dell’ethical hacker: confini incerti tra ricerca e reato

In assenza di una disciplina organica sulla responsible disclosure*, il ricercatore di sicurezza italiano opera in una zona grigia normativa che la Legge 90/2024 ha reso, paradossalmente, ancora più insidiosa.

Un mestiere che inizia dove finisce la legge

Esiste una figura professionale che compie ogni giorno, deliberatamente, atti che il codice penale descrive come reati. Lo fa per proteggere sistemi, utenti e infrastrutture. Lo fa, spesso, senza che nessuno glielo abbia chiesto. E lo fa sapendo che, al termine del proprio lavoro, potrebbe ricevere non un ringraziamento ma un avviso di garanzia.

Il ricercatore di sicurezza informatica, l’ethical hacker, il penetration tester indipendente, il bug hunter, opera in Italia in uno spazio normativo che non è mai stato davvero regolamentato. Non esiste, nel nostro ordinamento, alcuna norma che definisca cosa sia la “ricerca di sicurezza” in senso giuridicamente rilevante. Non esiste una procedura codificata per la divulgazione responsabile delle vulnerabilità. Non esiste un porto sicuro. Esiste soltanto l’art. 615-ter del codice penale, pensato oltre trent’anni fa per punire i criminali informatici, che nella sua formulazione universale abbraccia indistintamente il black hat malevolo e il white hat che, trovata una falla in un sistema pubblico, vorrebbe segnalarla a chi di competenza.

Questo articolo analizza quella zona grigia: la giurisprudenza che ha cercato di tracciarvi dei confini, la riforma del 2024 che quei confini ha ulteriormente spostato verso l’incertezza, i modelli esteri che indicano percorsi alternativi e le clausole contrattuali dei programmi di bug bounty che cercano di supplire, con strumenti privatistici, a ciò che il legislatore non ha ancora fatto.

L’art. 615-ter e il problema strutturale della fattispecie

L’art. 615-ter del codice penale, introdotto dalla legge n. 547 del 1993 in attuazione della Raccomandazione del Consiglio d’Europa n. R(89)9 del 13 settembre 1989 sulla criminalità informatica, punisce con la reclusione fino a tre anni «chiunque abusivamente si introduce in un sistema informatico o telematico protetto da misure di sicurezza ovvero vi si mantiene contro la volontà espressa o tacita di chi ha il diritto di escluderlo».

La norma è disegnata attorno a due concetti chiave: l’abusività dell’accesso e la tutela dello ius excludendi del titolare. L’accesso al sistema è protetto non quale dato puramente tecnico, ma quale proiezione del “domicilio informatico”, con tutela derivante indirettamente dagli artt. 14 e 15 Cost. Ciò significa che la norma protegge, prima ancora che i dati, la volontà del titolare di ammettere o escludere soggetti dal proprio spazio informatico.

Su questo punto la giurisprudenza ha conosciuto una lunga storia di oscillazioni, risolta almeno parzialmente da due fondamentali interventi delle Sezioni Unite della Corte di Cassazione.

La giurisprudenza delle Sezioni Unite: due principi, un paradosso

Il primo intervento è la sentenza SS.UU. “Casani” del 27 ottobre 2011 (n. 4694, dep. 7 febbraio 2012). La questione era se integrasse il reato la condotta del soggetto autorizzato all’accesso che vi si introduce per finalità diverse o illecite.

Le Sezioni Unite stabilirono un principio di portata generale: «integra la fattispecie criminosa di accesso abusivo ad un sistema informatico o telematico protetto la condotta di accesso o di mantenimento nel sistema posta in essere da soggetto che, pure essendo abilitato, violi le condizioni ed i limiti risultanti dal complesso delle prescrizioni impartite dal titolare del sistema per delimitarne oggettivamente l’accesso. Non hanno rilievo, invece, per la configurazione del reato, gli scopi e le finalità che soggettivamente hanno motivato l’ingresso al sistema».

Il principio è tecnicamente preciso ma produce conseguenze problematiche per i ricercatori di sicurezza: ciò che rileva non è l’intenzione dell’agente (buona o cattiva che sia) ma la violazione oggettiva delle condizioni di accesso poste dal titolare. Per l’ethical hacker che accede a un sistema senza un’esplicita autorizzazione scritta del titolare, la mancanza di quella volontà espressa è di per sé sufficiente a configurare il reato, indipendentemente dal fatto che egli non abbia copiato nulla, non abbia arrecato danni e intenda segnalare responsabilmente la vulnerabilità trovata.

Il secondo intervento è la sentenza SS.UU. “Savarese” del 18 maggio 2017 (n. 41210), che per i pubblici ufficiali ha introdotto il concetto di “ragioni ontologicamente estranee”: integra il delitto di cui all’art. 615-ter, secondo comma n. 1, c.p. la condotta del pubblico ufficiale che, pur essendo abilitato e pur non violando le prescrizioni formali impartite dal titolare, acceda o si mantenga nel sistema per ragioni ontologicamente estranee rispetto a quelle per le quali la facoltà di accesso gli è attribuita.

Per il ricercatore di sicurezza, la combinazione di questi due principi crea un labirinto: se accede senza autorizzazione esplicita viola le condizioni del titolare (Casani); se accede con credenziali lecite ma per testare la sicurezza invece di svolgere la funzione per cui le credenziali furono concesse, compie operazioni “ontologicamente estranee” (Savarese). In entrambi i casi la legge non distingue tra chi vuole fare un danno e chi vuole evitarlo.

Il caso Catania 2019: un’archiviazione istruttiva, non una regola

Un provvedimento che ha catalizzato l’attenzione degli specialisti è il decreto del GIP del Tribunale di Catania del 15 luglio 2019 (Giudice dott. Rizza), che ha disposto l’archiviazione di un procedimento penale per il reato di accesso abusivo a sistemi informatici o telematici (art. 615-ter c.p.). I fatti si inseriscono in un contesto di sviluppo di un’applicazione per smartphone: il ricercatore, dotato di notevoli competenze tecniche, si era introdotto nel sistema aziendale individuando vulnerabilità che aveva poi segnalato responsabilmente. Il giudice ha ritenuto che tale condotta, qualificabile come responsible disclosure volta alla “tutela dei consumatori”, non potesse essere censurata penalmente.

Il provvedimento è storicamente significativo: è tra le prime archiviazioni italiane esplicitamente motivate con il riconoscimento della responsible disclosure. Non costituisce però un precedente vincolante né una causa di giustificazione sistematica. È il risultato di una valutazione discrezionale, irripetibile nella sua struttura procedurale, che non risolve il problema strutturale: in assenza di una norma che definisca le condizioni di liceità della ricerca di sicurezza, ogni caso deve essere valutato individualmente, con esiti imprevedibili.

La Legge 90/2024: più pene, nessuna protezione

Se la giurisprudenza si era almeno sforzata di cercare criteri interpretativi di contenimento, il legislatore del 2024 ha scelto una direzione opposta: più sanzioni penali, nessun safe harbor.

La Legge 28 giugno 2024, n. 90, “Disposizioni in materia di rafforzamento della cybersicurezza nazionale e di reati informatici”, si compone di 24 articoli e introduce obblighi di segnalazione degli incidenti per pubbliche amministrazioni e operatori essenziali (art. 1), rafforza il ruolo dell’Agenzia per la Cybersicurezza Nazionale (ACN) e inaspisce in modo significativo le sanzioni penali per i reati informatici.

Sul piano del diritto penale sostanziale, l’art. 16 della legge modifica in modo estensivo il codice penale. Per quanto riguarda specificamente l’art. 615-ter c.p.:

Il primo comma (ipotesi base) rimane invariato: reclusione fino a tre anni, procedibile a querela della persona offesa. Il secondo comma (ipotesi aggravate, tra cui il fatto commesso da pubblico ufficiale o in danno di pubblico ufficiale) subisce modifiche alle circostanze aggravanti, con procedibilità d’ufficio. Il terzo comma (sistemi informatici di interesse militare, ordine pubblico, sicurezza pubblica, sanità, protezione civile, interesse pubblico) vede le pene elevarsi sensibilmente: da «reclusione da uno a cinque anni e da tre a otto anni» a «reclusione da tre a dieci anni e da quattro a dodici anni», con procedibilità d’ufficio.

L’inasprimento del terzo comma è particolarmente rilevante per i ricercatori di sicurezza: i sistemi che presentano le vulnerabilità più critiche (quelli di interesse pubblico, sanitario o infrastrutturale) sono proprio quelli per cui la legge ora prevede le pene più severe, senza che esista alcuna causa di giustificazione per il ricercatore in buona fede. La Legge 90/2024 ha anche introdotto, all’art. 623-quater c.p., circostanze attenuanti per chi si adoperi per evitare che l’attività delittuosa sia portata a conseguenze ulteriori, con riduzione di pena dalla metà a due terzi. Si tratta però di un istituto pensato per la collaborazione investigativa, non per la tutela del ricercatore preventivo.

Come analizzato su ICT Security Magazine, alcuni esperti temono che la normativa possa ostacolare il lavoro di chi si occupa di bug bounty programs o di ricerca indipendente sulla sicurezza informatica. Il timore non è peregrino: in assenza di cause di giustificazione specifiche, l’aumento delle pene produce un effetto deterrente che ricade sull’intera comunità della sicurezza, non solo sugli attori malintenzionati. Le Camere Penali Italiane, nelle proprie osservazioni al testo, hanno rilevato come alcune nuove disposizioni introducano ipotesi di reato e circostanze aggravanti inadeguate a fornire una risposta efficace alle esigenze di sicurezza e che la partecipazione dell’ACN nelle indagini (art. 22 co. 4-bis) sollevi preoccupazioni sull’indipendenza delle procedure giudiziarie.

La legge ha il merito di rafforzare l’ACN come interlocutore per la gestione delle vulnerabilità e di istituire il Centro Nazionale di Crittografia, ma non trae le conseguenze necessarie per il quadro della ricerca di sicurezza indipendente. Come illustrato in precedenti analisi, l’inasprimento delle pene non è sempre efficace come deterrente se non accompagnato da una robusta capacità di enforcement e da un equilibrato riconoscimento delle condotte lecite.

I tentativi di riforma: verso una responsible disclosure normata

Il vuoto normativo non è passato inosservato. A livello parlamentare, la proposta di legge a prima firma dell’on. Riccardo Magi (nelle sue diverse formulazioni a partire dal 2022) ha avuto il merito di portare la questione al centro del dibattito: il testo prevedeva l’introduzione di una causa di non punibilità per il ricercatore di sicurezza che avesse operato rispettando criteri di buona fede, proporzionalità e notifica tempestiva delle vulnerabilità scoperte all’organizzazione interessata o all’ACN. La proposta non è mai giunta all’approvazione, ma ha catalizzato un dibattito accademico e tecnico di grande rilievo, a cui si è aggiunta l’attività di soggetti come la fondazione GCSEC, promotrice del Manifesto italiano di Coordinated Vulnerability Disclosure.

La questione centrale, sul piano dogmatico, è se sia più opportuno introdurre una causa di giustificazione (che esclude l’illiceità del fatto), una causa di non punibilità (che esclude la pena pur riconoscendo l’illiceità) o una vera e propria riformulazione delle fattispecie incriminatrici che escluda ab origine dalla tipicità le condotte di ricerca in buona fede. Sarebbe opportuno che il legislatore intervenisse introducendo una vera e propria causa di non punibilità, distinta dal consenso dell’avente diritto. Quest’ultimo, infatti, non può operare per il reato di cui all’art. 615-ter c.p. nell’ipotesi base, poiché il mancato consenso è elemento costitutivo della fattispecie.

Ciascuna opzione presenta profili tecnici diversi. La causa di giustificazione si inserirebbe nella struttura del reato e avrebbe effetti più pervasivi, ma richiederebbe criteri applicativi rigorosi per evitare che diventi uno scudo per condotte in realtà offensive. La causa di non punibilità è più cauta sul piano sistematico ma non risolve il problema del procedimento che viene comunque avviato e delle misure cautelari che possono essere disposte nel frattempo. La modifica tipizzante è la più garantista ma anche la più difficile da formulare con precisione sufficiente.

Il modello olandese: pragmatismo istituzionale senza immunità assoluta

I Paesi Bassi rappresentano il riferimento europeo più maturo in materia di responsible disclosure istituzionalizzata. Il National Cyber Security Centre olandese (NCSC) ha pubblicato le proprie linee guida sul Coordinated Vulnerability Disclosure (CVD) nel 2013, poi aggiornate nel 2018 sulla base dell’esperienza maturata.

Il modello olandese deve essere descritto con precisione, perché spesso viene frainteso come un “porto sicuro” assoluto: non lo è. Le linee guida non modificano il quadro giuridico vigente. Il codice penale olandese (artt. 138ab e 161 sexies) non distingue tra hacker malintenzionato ed ethical hacker: la decisione se trattare un soggetto come tale è rimessa alla Procura della Repubblica e al giudice. La Procura olandese ha tuttavia pubblicato una lettera di indirizzo nel 2013 (il Board of Procurators General), stabilendo che non si procederà penalmente in presenza di “ripristino dei diritti” tra il segnalante e l’organizzazione colpita, pur mantenendo la facoltà di agire quando la condotta abbia ecceduto i limiti di proporzionalità.

Il meccanismo funziona perché poggia su tre pilastri complementari. Il primo è procedurale: le organizzazioni che adottano una politica CVD si impegnano formalmente a non sporgere denuncia contro i ricercatori che rispettino determinate condizioni (nessuna copia o modifica di dati, disclosure confidenziale, proporzionalità dei test, finestra temporale concordata per la correzione prima della pubblicazione). L’NCSC raccomanda un termine di 60 giorni per le vulnerabilità software e di sei mesi per quelle hardware più complesse.

Il secondo è istituzionale: l’NCSC agisce da intermediario quando la vulnerabilità viene segnalata direttamente all’ente, e si impegna a tenere informato il ricercatore sullo stato di risoluzione. Il terzo è normativo-orientativo: la lettera di indirizzo della Procura offre ai ricercatori criteri ex ante di comportamento protetto, riducendo l’incertezza giuridica senza richiedere una modifica legislativa.

Il sistema olandese non garantisce immunità: la Procura mantiene sempre la facoltà di perseguire. Un ricercatore che abbia reso pubblica la vulnerabilità prima della correzione o che abbia effettuato ricerche sui dati personali di soggetti terzi è stato condannato, proprio perché aveva ecceduto i limiti di proporzionalità. Ma l’esistenza di criteri chiari e di un orientamento esplicito della magistratura requirente ha creato un ecosistema in cui la ricerca di sicurezza può prosperare in condizioni di ragionevole prevedibilità giuridica.

Il caso americano: il CFAA, Van Buren e il dibattito sulla riforma

Negli Stati Uniti il problema è strutturalmente analogo. Il Computer Fraud and Abuse Act del 1986 (CFAA) punisce chiunque “intentionally accesses a computer without authorization or exceeds authorized access”, e la vaghezza della nozione di exceeds authorized access aveva generato un lungo contrasto giurisprudenziale tra i circuiti di appello federali.

La svolta è arrivata con la sentenza Van Buren v. United States della Corte Suprema del 3 giugno 2021 (593 U.S. 374). La Corte, in una decisione 6-3 redatta dalla Justice Barrett, ha adottato un’interpretazione di tipo “gates-up-or-down”: si “eccede l’autorizzazione” soltanto quando si accede a file, cartelle o database a cui il proprio accesso non si estende affatto, non quando si usa un accesso altrimenti lecito per uno scopo improprio.

Il fine dell’accesso (anche se illecito) è giuridicamente irrilevante se le credenziali permettevano l’accesso a quell’area del sistema. La Electronic Frontier Foundation, che aveva depositato un amicus brief nel caso, definì la pronuncia “una vittoria per tutti gli utenti di Internet e in particolare per i ricercatori di sicurezza”.

Van Buren non ha risolto però il problema dell’accesso inizialmente non autorizzato, che rimane il caso più comune per il ricercatore indipendente. E non elimina il rischio di azione civile: come segnalato da diversi esperti del settore, il timore principale dei ricercatori non è la responsabilità penale ma quella civile, cioè essere citati in giudizio dalla stessa azienda che ha la vulnerabilità nel proprio sistema.

Le proposte di riforma più avanzate, elaborate da organizzazioni come Rapid7, EFF e Center for Democracy & Technology, convergono su alcuni elementi comuni: la definizione legislativa di good faith security research, che includa la minimizzazione dei danni e l’obbligo di disclosure al titolare del sistema; il divieto di utilizzo commerciale delle vulnerabilità scoperte prima della loro divulgazione; la limitazione del diritto di azione civile delle aziende nei confronti dei ricercatori che abbiano rispettato la procedura di disclosure.

I programmi di bug bounty: contratti che suppliscono alla legge

In assenza di una disciplina legislativa, il mercato ha sviluppato i propri strumenti di regolazione. I programmi di bug bounty (piattaforme gestite da HackerOne, Bugcrowd e operatori nazionali, o programmi diretti delle singole organizzazioni) rappresentano oggi la principale forma di legalizzazione contrattuale dell’ethical hacking.

Il meccanismo è semplice: l’organizzazione definisce un perimetro (scope) di sistemi su cui la ricerca è autorizzata, le tipologie di vulnerabilità ricercabili, le regole di comportamento per il ricercatore, la finestra temporale entro cui la vulnerabilità verrà corretta e la misura della ricompensa. In cambio, il ricercatore ottiene l’autorizzazione esplicita (la volontà espressa del titolare che l’art. 615-ter richiede) e una clausola contrattuale di safe harbor che lo protegge da azioni legali civili. Il Gold Standard Safe Harbor promosso da HackerOne è divenuto di fatto uno standard internazionale di riferimento, raccomandato anche dal Dipartimento di Giustizia degli Stati Uniti e dalla CISA nel proprio Vulnerability Disclosure Policy Template per le agenzie federali.

In Italia, il mercato dei bug bounty è in crescita ma strutturalmente fragile sul piano della tutela giuridica del ricercatore. Il problema fondamentale è che la clausola contrattuale di safe harbor non ha alcuna efficacia preclusiva nel sistema penale italiano.

Per le ipotesi base del reato (primo comma, procedibili a querela), il consenso e la mancata querela del titolare costituiscono di fatto un presidio: il titolare del sistema, potendo disporre del suo legittimo interesse, può scegliere di non sporgere denuncia o di ritirarla. Ma per le ipotesi aggravate del terzo comma (quelle relative a sistemi di rilevanza pubblica, sanitaria, militare o infrastrutturale, procedibili d’ufficio) il consenso del titolare è penalmente irrilevante, e la Procura può procedere indipendentemente dalla volontà della parte offesa.

Un ulteriore profilo critico riguarda la granularità tecnica degli ambienti informatici: se il ricercatore, operando nell’ambito di un programma di bug bounty aziendale, accede incidentalmente a dati di terzi o a sottosistemi non inclusi nello scope dichiarato, la copertura contrattuale cessa. Questa eventualità, tutt’altro che teorica in sistemi complessi e interconnessi, espone il ricercatore a un rischio che nessuna clausola contrattuale può eliminare in assenza di una norma primaria di tutela.

La Direttiva NIS2 e il diritto dell’Unione: un’occasione mancata

Il quadro normativo europeo offre spunti importanti ma non ha ancora tradotto la propria attenzione alla sicurezza informatica in una tutela esplicita per i ricercatori. La Direttiva NIS2 (Direttiva UE 2022/2555), recepita in Italia con il D.Lgs. n. 138/2024 in vigore dal 18 ottobre 2024, impone agli operatori essenziali e importanti di adottare politiche per la gestione delle vulnerabilità e processi di coordinated vulnerability disclosure. È un riconoscimento formale (il primo in uno strumento europeo vincolante) che le vulnerabilità esistono, che è utile che qualcuno le trovi e che deve esserci un processo per gestirne la comunicazione.

Tuttavia, la NIS2 non trae le conseguenze penalistiche di questi principi: non prevede alcuna protezione per chi, trovando una vulnerabilità al di fuori di un programma formale, la segnali spontaneamente. Il Cybersecurity Act europeo (Reg. UE 2019/881) ha istituito il quadro di certificazione della cybersecurity, ma riguarda prodotti e servizi, non la posizione giuridica dei ricercatori. L’ENISA ha pubblicato nel 2022 un rapporto sulle politiche CVD nell’UE documentando la frammentazione delle pratiche nazionali e raccomandando standard comuni, rilevando come l’assenza di framework nazionali chiari creasse “uncertainty and potential legal risk for security researchers across the EU”. Le raccomandazioni sono rimaste in larga parte disattese sul piano legislativo.

Le strade possibili: un’agenda di riforma

Il panorama tracciato consente di identificare alcune priorità di riforma che l’Italia, con la Legge 90/2024, ha scelto di non affrontare.

La prima priorità è legislativa: l’introduzione di una causa di non punibilità (o di una scriminante procedurale) per il ricercatore di sicurezza che abbia operato rispettando criteri di buona fede, proporzionalità e notifica tempestiva. Il modello olandese offre una traccia: non un’immunità assoluta, ma un processo strutturato che dia al ricercatore criteri chiari di comportamento protetto e orienti la discrezionalità della magistratura requirente verso la non azione in presenza di quei criteri. Sarebbe altresì utile definire esplicitamente cosa costituisce un’attività lecita di security testing.

La seconda priorità è istituzionale: l’ACN dovrebbe sviluppare un ruolo di intermediario analogo a quello svolto dall’NCSC olandese. La Legge 90/2024 le ha attribuito la funzione di ricevere e gestire le segnalazioni di vulnerabilità nei sistemi delle pubbliche amministrazioni e degli operatori essenziali: è il momento di costruire intorno a questa funzione un framework pubblico di responsible disclosure, con una policy ufficiale che definisca le regole del gioco per i ricercatori indipendenti che operano su sistemi italiani. In questa prospettiva sarebbe auspicabile anche l’introduzione di un registro nazionale di penetration tester certificati, con linee guida precise per le attività autorizzate e procedure chiare per ottenere autorizzazioni di testing.

La terza priorità è prosecutoriale: un orientamento esplicito del Consiglio Superiore della Magistratura o della Procura Generale della Cassazione sull’approccio da tenere nei casi di divulgazione responsabile (analogo alla lettera di indirizzo del Board of Procurators General olandese del 2013) non richiede una modifica legislativa ma può ridurre significativamente l’incertezza giuridica per i ricercatori in buona fede.

La quarta priorità è contrattuale e di sistema: la standardizzazione delle clausole di safe harbor nei programmi di bug bounty italiani, possibilmente con il supporto di ACN e di associazioni di categoria come Clusit, per ridurre l’asimmetria informativa che penalizza soprattutto i ricercatori più giovani e meno strutturati.

Conclusione: il costo dell’immobilismo

La zona grigia in cui opera il ricercatore di sicurezza italiano ha un costo concreto. Si misura nella vulnerabilità non segnalata perché il ricercatore non si fida del framework giuridico. Si misura nel talento che emigra verso Paesi con regole più chiare. Si misura nell’ecosistema della sicurezza informatica nazionale che fatica a strutturarsi intorno a pratiche di responsible disclosure condivise.

Il paradosso dell’attuale situazione italiana è che la stessa Legge 90/2024 che riconosce il valore della gestione strutturata delle vulnerabilità informatiche (che attribuisce all’ACN il compito di ricevere segnalazioni di vulnerabilità, che introduce obblighi di patching e aggiornamento) ha contemporaneamente inasprito le sanzioni per le condotte che stanno a monte di quelle segnalazioni: l’accesso al sistema, la verifica della vulnerabilità, la raccolta delle prove necessarie a dimostrarne l’esistenza. Chiedere ai ricercatori di trovare le vulnerabilità e al contempo minacciare chi le trova con pene fino a dodici anni di reclusione per i sistemi più critici è una contraddizione che il legislatore non può continuare a ignorare.

Una politica di sicurezza informatica coerente deve riconoscere che la sicurezza collettiva dei sistemi dipende anche, e talvolta soprattutto, dall’attività di chi, senza aspettare di essere commissionato, cerca le falle prima che lo facciano i criminali. Trovare l’equilibrio tra la necessaria protezione dei sistemi informatici e la necessaria libertà di chi lavora per renderli più sicuri non è un esercizio accademico: è una scelta di politica del diritto urgente e non più rinviabile.