Un software può superare una valutazione tecnica e lasciare ancora aperta una domanda decisiva: chi lo controlla davvero? Il caso Oxygen Forensics porta questa domanda dentro un settore particolarmente delicato, quello degli strumenti usati per estrarre e analizzare dati da dispositivi digitali.

Che cosa contestano i procuratori statunitensi

Secondo l’accusa, Lee Reiber e Oleg Davydov avrebbero nascosto al governo statunitense che Oxygen Forensics era controllata da cittadini russi e che sviluppo, revisione e gestione del codice continuavano in Russia. Le ricostruzioni giornalistiche citano una struttura societaria passata anche da una holding cipriota e dichiarazioni che avrebbero presentato l’attività come statunitense.

Il software è stato venduto a enti federali, inclusi organismi legati a sicurezza e difesa. Courthouse News riferisce inoltre di un contratto quinquennale con il National Computer Forensics Institute, con un tetto massimo di 12 milioni di dollari. Quel massimale non indica quanto sia stato effettivamente speso.

Compilato negli USA non significa sviluppato negli USA

Uno dei passaggi più interessanti riguarda la build, cioè il processo che trasforma il codice sorgente nel programma distribuito ai clienti. I procuratori sostengono che nel 2022 la compilazione sia stata spostata su infrastruttura cloud negli Stati Uniti, mentre il lavoro sul codice sarebbe rimasto in Russia.

È una distinzione utile anche fuori da questo caso. Il luogo in cui nasce il pacchetto finale non dice, da solo, chi scrive il codice, chi approva le modifiche, chi può intervenire sugli aggiornamenti o quale giurisdizione incide sulle persone coinvolte. La filiera software non coincide con l’indirizzo indicato in fattura.

Il rischio non è soltanto trovare malware

OCCRP e The Record sottolineano un limite importante: le accuse rese pubbliche non sostengono che il software contenesse codice malevolo o fosse stato utilizzato per entrare senza autorizzazione nei sistemi dei clienti. Presentare il caso come una backdoor russa già dimostrata sarebbe quindi scorretto.

Il rischio descritto è prima di tutto di governance e affidabilità delle dichiarazioni. Quando uno strumento tratta prove digitali, dati sensibili o attività investigative, proprietà effettiva e controllo dello sviluppo possono modificare la valutazione anche in assenza di una vulnerabilità conosciuta.

La due diligence deve continuare dopo l’acquisto

Chiedere chi possiede il fornitore è soltanto l’inizio. Occorre capire dove lavorano i team, chi firma gli aggiornamenti, quali subfornitori partecipano allo sviluppo, come vengono controllate le build e come sono comunicate variazioni societarie o operative.

Queste verifiche non producono una garanzia assoluta. Rendono però più difficile affidare processi critici a una rappresentazione incompleta del fornitore. La domanda utile non è soltanto “il prodotto funziona?”, ma “le condizioni sulla base delle quali lo abbiamo scelto sono ancora vere e verificabili?”.

Fonti e riferimenti