They're buying the version of the website as it exists at the point of time when they buy it. The assumption being that it works for them now, it should continue working for them in the future, regardless of what direction the .com goes.
In this case, we're talking about software built on the Microsoft stack, so most of that is Windows Update's job (patching servers manually isn't really something that needs to happen in this world).
As to vulnerabilities in the handful of 3rd party libraries that we use? In the 10 years that Twiddla has been around, we've had exactly zero cases where we had to patch something from our end for security reasons.
I guess there's something to be said about avoiding the tall skinny (and wobbly) tower of 3rd party dependencies that seems to be the norm these days in web app development.
If you're deploying a SaaS system on premises, because a particular company needs it, then it's quite likely that this is also the same type of company that would have a standard procedure to expose only a single port of that server to a specific list of internal computers only on a network level.
The kind of companies that don't have everything behind a firewall / VPN would also just use SaaS directly, instead of requesting the hassle of an on-premise setup.
They're buying the version of the website as it exists at the point of time when they buy it. The assumption being that it works for them now, it should continue working for them in the future, regardless of what direction the .com goes.