If you're using Go, you should already have the infrastructure to do this. Everything we have gets rebuilt for each go release anyway, so this is no different, just a little more immediate.
Unless you're using packages in an APT or Yum repo. You instead get to wait for packages to come downstream, almost certainly not in anything approaching synchronicity. Awesome.
We got away from statically linked monoliths for a reason.
It's been particularly bad in the past for things like nginx, where we've known about memory corruption bugs for multiple days and had clients who were incapable of patching because they only had infrastructure for downloading packages.
You should have tools in place to build, from source, anything that might be a significant security issue.
And while I 100% agree about the optimal case, in practical terms you're going to see a lot better turnaround from the maintainers of Debian's OpenSSL than, say, the third-party Docker repo. A sane system not reliant on static linking 'til the cows come home is not a cure-all, but it's better than the Go situation, and is a part of why I'm super not thrilled with Go-as-infrastructure. (Go-as-app, whatever, people take that problem on themselves.)