The official Go blog describes their mitigations against supply chain attacks. It is said that Go's toolchain and design incorporates considerations to reduce the risk of attacks at various stages.
All builds are "locked"
External changes (such as publishing new versions of dependencies) do not affect Go builds .
Unlike configuration files used by most other package managers, Go modules do not have a separate list of constraints and a lock file for locking a specific version. The version of each dependency participating in a Go build is go.moddetermined entirely by the main module's files.
As of Go 1.16, the above operations are performed by default, and the go.modbuild command will fail if incomplete. The only command that will change go.modis go getand go mod tidy. These commands are usually not run automatically or in CI, so such changes to the dependency tree are usually intentional and can be discovered during the code review phase.
This is very important for security, if a module is compromised and a new malicious version is released, no one will be affected until that dependency is explicitly updated, giving the ecosystem time to review changes and detect incidents .
Version content never changes
Another key property to ensure that third parties do not affect the build is that the contents of the module version are immutable . Because if an attacker who breaks a dependency can reupload an existing version, they can automatically break all projects that depend on that dependency.
That's exactly what go.sumfiles are for. It contains a list of cryptographic hashes for each dependency that contributes to the build. Also, incomplete go.sumleads to errors, and it can only be used go getand go mod tidymodified. Therefore, any modification to it will be accompanied by subjective dependency changes.
VCS is the source of truth
Most projects use a version control system (VCS) during development, and in other ecosystems, these projects also need to be uploaded to a central package repository (such as npm). This means that there are two accounts that could be compromised, the VCS host and the central package repository. The latter is used less often and is easier to ignore. It also means it's easier to hide malicious code in versions uploaded to the repository, especially if the source code is routinely modified as part of the upload.
Go has no such thing as a central package repository account. A package's import path embeds the information needed to get its module directly from VCS go mod download , where a label on VSC defines the module version.
Only build code, but not execute
The Go toolchain has a clear security design goal: neither fetching nor building code will allow that code to execute , regardless of whether the code is untrusted or malicious.
This is a meaningful risk mitigation if you are executing a binary or testing a dependency that uses only a subset of package modules. For example, if you example.com/cmd/devtoolxbuild and execute on macOS, there is no chance of a Windows-specific dependency or example.com/cmd/othertooldependencies compromising your machine.
In Go, modules that do not provide code for a particular build have no security impact on the build.
"Copying is better than relying"
The last (and probably most important) supply chain attack risk mitigation is also the least technical: Go has a culture of rejecting large dependency trees, and prefers copying rather than adding new dependencies .
This goes back to a Go proverb: "a little copying is better than a little dependency" .
Go modules are very proud of their "zero dependencies" label. If a developer needs to use a library, he will find that the library will not let him depend on dozens of modules of other authors and owners.
This means that rich, complex applications can be built with only a few dependencies. After all, no matter how good a tool is, it cannot eliminate the risks involved in reusing code, so the strongest mitigation is always to have only a small dependency tree .