Software can pass a technical assessment and still leave a crucial question unanswered: who really controls it? The Oxygen Forensics case brings that question into a particularly sensitive field: tools used to extract and analyse data from digital devices.

What US prosecutors allege

According to prosecutors, Lee Reiber and Oleg Davydov allegedly concealed from the US government that Oxygen Forensics was controlled by Russian nationals and that code development, review and management continued in Russia. News reports describe a corporate structure that also involved a Cypriot holding company and statements that allegedly presented the business as American.

The software was sold to federal bodies, including organisations involved in security and defence. Courthouse News also reports a five-year contract with the National Computer Forensics Institute, with a ceiling of $12 million. That ceiling does not indicate how much was actually spent.

Built in the US does not mean developed in the US

One of the most revealing details concerns the build: the process that turns source code into the program distributed to customers. Prosecutors allege that compilation moved to cloud infrastructure in the United States in 2022, while work on the code remained in Russia.

This distinction matters beyond this case. The location where the final package is produced does not, on its own, tell us who writes the code, who approves changes, who can influence updates or which jurisdiction affects the people involved. The software supply chain extends beyond the address on an invoice.

The risk goes beyond finding malware

OCCRP and The Record highlight an important limit: the publicly disclosed allegations do not claim that the software contained malicious code or had been used to gain unauthorised access to customers' systems. Presenting the case as an already proven Russian backdoor would therefore be inaccurate.

The risk described is primarily one of governance and the reliability of representations. When a tool handles digital evidence, sensitive data or investigative work, beneficial ownership and control over development can change the assessment even without a known vulnerability.

Due diligence must continue after purchase

Asking who owns the supplier is only the beginning. Buyers need to understand where teams work, who signs updates, which subcontractors contribute to development, how builds are controlled and how corporate or operational changes are communicated.

These checks do not provide an absolute guarantee. They do make it harder to entrust critical processes to an incomplete picture of a supplier. The useful question is not just “Does the product work?” but “Are the conditions on which we chose it still true and verifiable?”

Sources and references