Yes, that is the standard Go approach and the only real option at the moment.
That said, I'm not really a fan of the vendoring approach because it means that all of the dependencies have to be copied directly into the repository under a _workspace directory and all the import paths then have to be modified accordingly even though they are already in a separate repository under the organization. It also means updates to dependencies end up cluttering up the commit history of the main repository instead of being isolated to the core network/daemon development.
Eventually, I would like to see a btcd specific build tool that makes use of revision pinning (we already keep a deps.txt in the repository that has the revisions of all of the deps at each release) in order to obtain the specific revisions, validates the commit signatures, and then uses gb to do the deterministic build.
In my experience, most people don't actually ensure the signatures match, so I think having that happen as a part of the installation for releases (only release commits are signed) would be a big win.
I'm spitballing here, but it could look something like this:
For an update to this, we have been evaluating the glide tool in order to provide dependency locking. The tool is not quite ready for prime time yet, but it looks quite promising. Effectively, it allows revision pinning via a lock file and automatically fetches and checks out those revisions.