The security researcher warning is right, but you must put this warning on the context of your application to know if it is relevant.
You listed the "root detection" as an important security feature of your app.
Being a security expert myself, I would point out that root detection can be easily bypassed. Not only on virtual machines: but in physical devices as well. Many frameworks that claim to do root detection do not detect many rooted devices and detect some normal ones as rooted. Even if was the case, the client-side of any application can be easily reverse-engineered. A motivated attacker will be able to access your back-end interface bypassing the client-side app altogether. This means that any checks on the client-side can be bypassed and any calculation messed with. No client-side check or calculation can be trusted.
It is possible to create a trusted client, but it requires proprietary hardware, proprietary operating system and software. Game consoles and cable networks do that, but still suffers a lot with piracy which should count as a good example of how difficult is to tamper-proof a device. This strategy is theoretically possible, but fails on practice because it is too expensive, steal and prevent investments on the product functionality that becomes weak and obsolete in front of its competition.
How secure does it need to be?
There is no such thing as a secure/safe app. Security is about understanding the risks, the likelihood and size of the losses it can cause and identify contingencies and mitigation strategies to keep a healthy profit margin. The questions you should be asking are:
- what happens when the "root detection" fails?
- what kinds of attacks the "root detection" is supposed to protect against?
- what is the likelihood of that to happen?
- what kinds of losses can a "root detection" fail cause?
- are there other protections against that?
- is it possible to detect those kinds of violations fast?
- is it possible to trigger contingencies that reduce or eliminate the losses?
- will the company still be profitable with those losses?
All important logic must be server-side
You seem bothered with the possibility of an attacker being able to install your app in a virtual environment. I suspect that many of the security checks and important calculations are on the client-side. If it is the case, you really need to redesign your app to move all controls to the server-side:
The back-end interface APIs exposed to the user networks must require authentication of the user.
The back-end interface APIs must limit what the user can see and do. The access limits should be imposed by the server-side, never by the client-side. With the exception, of course, of services that do not include sensitive information and commands;
The back-end interface APIs must account for the possibility of brute-force attacks. An attacker can download huge portions of your database and guess weak passwords and confirmation codes by attempting them all.
The internal APIs - those used by the back-end and not exposed to the user networks - compose an inner service layer that should use service users or client certificates to authentication. The information of the real user should be propagated to those services for logging purposes.
I know that this is very disappointing. With those restrictions, the back-end interface APIs must be very specific to the app workflows and therefore less reusable. Unfortunately, only internal APIs can be reusable. This also means the back-end developers will need to understand very well the user experience, the designed workflows and work closely with the front-end teams which are things most developers do not like or are prepared to do.
Even with all the important logic on the server, it is necessary to design the workflows to account for other risks
If the app follows the guidelines mentioned above, it does not matter if the client-side app is tampered with on an attacker's device. He or she will not be able to do anything other than what the user credentials they have would allow them to do via the official client-side app.
But if a real user device is rooted, malware will be able to:
- bypass rooted device detection;
- capture user credentials;
- redirect the user to a false page;
- redirect the user to a false app;
- remote control the device;
Those attacks are not very common. Those are difficult because usually require the user to do complicated procedures. But if the product is expensive or the information is too sensitive, those attacks must be taken seriously.
If your concern is because your "salespeople" deal with expensive products in which losses are large and not easily recoverable, you must consider secondary barriers such as:
- supervisor validation on larger operations;
- validate the delivery address with several external databases;
- improve tracking of the deliveries;
- impose time constraints on deliveries according to the risk.
If this still not enough, you may choose to provide a company-owned device that is locked to prevent external app installation and have the USB locked only to charge. I know a few people that walk around with three corporate phones of different companies all the time: it is still a thing.
Develop good logs and monitor them
Monitoring is also a good strategy to avoid many losses. Backtracking the losses on the logs allows better understanding on how they happen and what have failed, propose changes to the products or at least monitor that situations to get early warnings of similar situations on the future.
If the logs are detailed enough, there are techniques of behavior biometry that are easy to implement and can detect many kinds of intrusions and some kinds of operational mistakes early enough to prevent losses.
You have a desktop version?
When you said "We have a mobile version of the product", it sounded like you have another. Do you have a desktop version? Desktop operating systems are rooted by default and there is no app isolation. If you can live with a desktop version, you probably do not even need root detection in the first place.
It is a good thing to continuously improve security, and you should do it, but you can expect the mobile version to be safer than the desktop one unless you make a horrible mistake in the new development.