I can confidently tell you that your understanding of security mitigations is flawed. And I say that based on experience not just a baseless opinion. Silver bullets in security don't exist.
Let's every moveit instance was run in a container in a vm and in a dmz (actually moveit transfer is usually deployed in a dmz, isolated from everything else). But the entire purpose of the software is to contain all these important files and expose them to authorized parties, basically a file server (even has sftp!). The threat actors in this case didn't even bother compromising the OS, they just got a session id as a result of abusing sqli and .net deserialization flaw and logged into the webui and downloaded the files. At no point could a vm have stopped any of this.
I said your undersranding is flawed because you mindset is solution centric not data centric. If all an attacker cares about is access to your gmail, a qubes VM with strict selinux rules is useless if they get you to click on a link that exploits firefox to steal your gmail cookies, defeating any yubikey 2fa you may have.
You are too confident. First, Qubes does not use VMware. It uses Xen, which has way less vulnerabilities, most of which do not affect Qubes [0]. And none of them have led to arbitrary code execution in host since 2006, except maybe for VMs with PCI passthrough [1].
Also, Qubes does not trust the hardware emulation [2]. It keeps the trusted computing base as small as possible. Of course, the covert-channel attacks are still possible [3], but they are much weaker and can be mitigated through isolation. Qubes does not implement an ordinary copy-paste functionality; it's implementation is much more secure, see [4,5].
Hardware-virtualized VMs without any devices attached are extremely hard to escape from or access for other VMs. I am not aware of any successful attempts in the last >10 years.
> qubes VM with strict selinux rules is useless if they get you to click on a link that exploits firefox to steal your gmail cookies
This is wrong, because clicking on a link in my email would open a broswer in a dedicated, disposable VM. Also any attachment would also open in a disposable VM.
Having said that, you are probably right that in this case Qubes itself would not help as the whole database had to be available online.
I'll just say that the entire point of zero-day is that you are not aware of it now and that zero-click attacks exist and also that while your selection of a product based on historical performance under scrutiny is valid, you cannot use that as evidence to claim an attack is not possible.
And again, you miss the whole point of zero-day, it is an unknown. You can create an attacker-hostile environment but you cannot make guarantees or claim a solution is best practice against an unknown/undefined.
As far as I am aware for example, spectre/meltdown or *-hammer attacks could have been used against your disposable vm to read your email vm's memory. There are also hardware attacks against radio controllers/chips that could be used to wirelessly dump memory without your interaction.
You know, I was just telling someone how I thought those scenes in movies where the hacker guy types really fast and hacks everything were silly when I started working in security. Now, I know that if he is just the guy buying/trading exploits and spent a lot of time automating stuff and setting up infra,it is indeed possible to make it all look so easy (but still, some movies/shows take it too far). Especiallu in government work, the guys using the tools are rarely the guys that develop them or maintain their infra. The guys who develop access might also be different from the guys who action objectives or work on exfil or shell management.
I do know what zero-days are. And I do not solely use the historical performance as evidence for strong security.
Did you ever think that such a good performance that Xen and Qubes have is not a mere coincidence? What if I tell you that it is not just a pure luck? It just can't be luck statistically: in the Linux kernel, serious vulnerabilities are found all the time, whereas here they're extremely rare.
Let me tell you that it is actually a result of a good architecture. You know, in Xen, the trusted computing base, i.e., the code responsible for isolation and security is really small: it's of the order of 100k lines of code. In Linux it's millions of lines. Every code has bugs, it's unavoidable, but you simply can't have a similar number of bugs in 100k lines as in millions of lines. There are no "guarantees" here, just pure statistics.
In addition, Xen is very popular among big companies, so its code is constantly checked for bugs by the best people in the field. And zero-days in it are so expensive that you would not waste one on leaking personal data of people for no reason. Security is not about guarantees, it's about probabilities. And they are very small in Qubes, if you are not a big target. Even if you are, they are smaller than for any other system, thanks to the security-oriented design and reliance on compartmentalization.
Yes, Qubes is vulnerable to Spectre, Meltdown, *-hammer attacks. But it never attempted to protect the user against the hardware it runs on. It is physically impossible. Also, hardware attacks like these are exception, not the rule. And even they usually don't lead to VM escapes.