In the bad old days, if your company-internal tools were full of XSS bugs, fixing them wasn't a priority, because the tools could only be accessed with a login and VPN connection.
So outside attackers have already been foiled, and insider threats have a million attack options anyway, what's one more? Go work on features that increase revenue instead.
In principle the idea of "zero trust" was to write your internal-facing webapps to the same high standards as your externally-facing code. You don't need the VPN, because you've fixed the many XSS bugs.
In practice zero trust at most companies means buying something extremely similar to a VPN.
> In principle the idea of "zero trust" was to write your internal-facing webapps to the same high standards as your externally-facing code. You don't need the VPN, because you've fixed the many XSS bugs.
But why stop there? If these apps are not required to be accessed from public world, by setting up VPN you need to exploit both VPN and and the service to have an impact. Denial of specific service is harder and exploiting known CVEs is harder.
Because the protection that the VPN provides decreases the risk of having bugs to the point where they won't get prioritized, ever.
That is just bad management, to be fair. Companies need to intentionally increase risks before they can fix them?
Eh, at the same time VPNs can be a huge mess of problems on top of all the other problems that exist. Async routing is always a fun one in complex topologies.