It’s good to think through the risks here for your own use case, but ultimately, as the article points out, there’s no way to entirely avoid the problem for Go

It’s good to think through the risks here for your own use case, but ultimately, as the article points out, there’s no way to entirely avoid the problem for Go or any other language. So you just have to figure out how to best manage your own risks for your own required level of assurance. Luckily the go ecosystem has a number of tools for dealing with this. You can set up a local trusted proxy of all the code you use internally and point your builds to that instead of Google’s default proxy or just doing direct pulls. Or you can vendor the code you’re using into your own repository. You can also easily alias specific libraries to point elsewhere if specific ones are problematic, without having to change the code directly.