> as stated above, if the code is that important to you then create a fork, update as necessary.
I do not know about this specific case, relating to a Go user.
For Node projects however, which tend to be quite heavy users of web-based dependencies, what you describe is sort of how it works.
During a (pristine) build, npm downloads the relevant version of all leaves in your dependency tree, which then reside in the build computer. Unless you are doing something exotic (and in production you probably won't) whatever happens to your dependencies in GitHub or elsewhere does not affect your deployments.
If a dependency breaks for whatever reason, such as the developer pulling the repository, then your next pristine build is going to fail, you will spot the problem and then do something about it. I have seen this in a personal project once, not long ago, I can't remember what it was but it was just a transient issue, which meant my continuous integration server (which always does pristine builds) was paused for an hour or so until everything came back online. In the event of a more permanent issue you would eventually replace the dependency with another alternative, find a fork, host it yourself, or rewrite as appropriate. It seldom happens, it does not affect production deployments, and frankly it is not the end of the world.
It is totally a bazaar (if not a brothel) rather than a cathedral approach, but it does the job very nicely, much as it may shock a few parishioners.