Reverse engineering per la ricerca di vulnerabilità: cosa è legale e cosa no
Questa è una delle zone grigie più significative nel campo, e trattarla con leggerezza è un rischio genuino, non solo un tecnicismo.
Cosa è generalmente chiaramente accettabile
Testare il proprio software, o software per cui hai autorizzazione scritta esplicita a testare, è la scelta predefinita sicura. Tutto diventa significativamente più rischioso al di fuori di quel confine.
- Il tuo codice o sistemi — nessun diritto altrui è coinvolto.
- Un penetration test o una valutazione di sicurezza autorizzati con un accordo di ambito firmato.
- Un programma bug bounty, strettamente entro il suo ambito definito — la maggior parte dei principali programmi (tramite piattaforme come HackerOne o Bugcrowd) pubblica regole esatte su cosa è dentro e fuori dall'ambito, e seguire quelle regole è ciò che fornisce il porto sicuro legale.
Cosa è generalmente chiaramente non accettabile
- Fare reverse engineering di software commerciale specificamente per aggirare licenze, DRM, o paywall.
- Testare sistemi di produzione o software che non possiedi e per cui non hai autorizzazione a testare, anche "solo per vedere".
- Continuare a sondare un sistema dopo aver trovato una vulnerabilità, oltre a quanto necessario per dimostrarla e segnalarla (questo può passare dalla ricerca all'accesso non autorizzato).
- Divulgare pubblicamente una vulnerabilità prima di dare al fornitore tempo ragionevole per risolverla, dove ciò viola i termini di divulgazione del programma applicabile.
Le zone grigie che inciampano le persone
- Accordi di licenza che vietano interamente il reverse engineering — alcune giurisdizioni e contesti permettono il reverse engineering per interoperabilità o ricerca di sicurezza nonostante tali clausole (questo varia significativamente per paese e contesto); altri no. Questo dipende genuinamente dalla giurisdizione e vale la pena verificarlo piuttosto che assumere in un modo o nell'altro.
- Trovare una vulnerabilità al di fuori dell'ambito dichiarato di un programma mentre si testa al suo interno — segnalala responsabilmente, ma capisci che potresti non avere la stessa protezione legale che il test nell'ambito forniva.
- Testare un sistema a cui eri una volta autorizzato ad accedere ma non lo sei più (i sistemi di un ex datore di lavoro, per esempio) — un'autorizzazione scaduta non si porta avanti.
Una checklist pratica prima di iniziare qualsiasi ricerca di vulnerabilità
- Hai un'autorizzazione esplicita e attuale per questo obiettivo specifico?
- Se è un programma bug bounty, ciò che stai per fare rientra nel suo ambito pubblicato?
- Hai un piano di divulgazione responsabile se trovi qualcosa?
- Sei pronto a fermarti a "trovato e dimostrato" piuttosto che continuare a esplorare ulteriore accesso?
Niente di tutto ciò è consulenza legale per la tua situazione specifica — le leggi variano significativamente per giurisdizione e i dettagli contano. Quando sei genuinamente incerto se un obiettivo o un'attività sono autorizzati, la scelta predefinita più sicura è non procedere finché non l'hai chiarito.
Domande frequenti
È legale fare reverse engineering di un software per trovare bug di sicurezza?
Dipende molto dalla giurisdizione, dai termini di licenza del software, e se hai un'autorizzazione esplicita (come l'ambito definito di un programma bug bounty). Non c'è una singola risposta globale — verifica i termini specifici e la legge applicabili alla tua situazione prima di iniziare.
Un programma bug bounty rende automaticamente legale il reverse engineering?
Autorizza l'attività entro l'ambito specificamente definito di quel programma — testare al di fuori dell'ambito dichiarato, o contro sistemi/versioni non coperti, non è automaticamente protetto solo perché l'azienda gestisce un programma bug bounty in generale.
Cos'è la 'divulgazione responsabile' e perché conta legalmente ed eticamente?
È la pratica di segnalare privatamente una vulnerabilità trovata al fornitore interessato e dargli tempo ragionevole per risolverla prima di qualsiasi divulgazione pubblica — questa è sia la norma etica nella ricerca di sicurezza sia, in molti termini bug bounty, una condizione del porto sicuro legale offerto.