Sounds exactly like what we do for medical device software.

Version pinning, self-managed forks and code reviews of the dependency on upgrade.

How do you get informed about whether a high-priority issue exists?

In particular, who is auditing the old version of the code that you happen to be running to make sure it doesn't have vulnerabilities that are now gone after a non-security-motivated change like a refactoring or a feature removal? Probably not the upstream maintainers, who generally only maintain HEAD.

Security mailing lists. GitHub has security alerts. Good old fashioned RSS. For example, rubygems.org supports RSS for releases. GitHub Release pages also support RSS. An easy way to create a shared RSS feeds is to create a #news channel in Slack that has all the feeds.

It can be a pain but that pain might be motivation to not pull in dependencies with little thought.

Again, how does any of that tell you whether a high-priority issue exists in the old version of the code that you're running, as opposed to in the latest release?

I understand your point. I'd expect the old version to have been reviewed when it was introduced into the system just as the new version should be. Of course, that doesn't guarantee something won't slip in.

Running private package infrastructure with audited dependencies isn't a panacea to stopping supply chain attacks. I do believe it's an effective defense-in-depth tactic for the reasons others have discussed.

An additional supporting tactic that should be done is to tightly control egress traffic. Like ingress traffic, all egress traffic should be denied by default. From there, traffic should be whitelisted. That makes it more difficult to exfiltrate data or communicate with command and control infrastructure. Tight control on egress traffic also makes it easier to alert on unexpected connection attempts. That all said, locking down egress traffic can be a pain. It also isn't a panacea. Where there’s a will there’s a way.