How does go reduce supply chain attacks?

author | Filippo Valsorda

translator | Sambodhi

planning | Yuying

Modern software engineering is collaborative , And based on the reuse of open source software . This exposes the target to supply chain attacks , Software projects will be attacked because their dependencies are broken .

No matter what process or technical means are used , Every dependency must have a relationship of mutual trust . however ,Go The tools and design help reduce the risk of all stages .

All builds have been “ lock ”

Changes in the outside world , For example, release new versions of dependencies , It doesn't affect Go The construction of .

Unlike most package manager files ,Go The module does not have a separate constraint list and lock file , But it locks a particular version . whatever Go The version of each dependency built depends entirely on the main module go.mod file .

from Go 1.16 Start , This determinism will be enforced , And in go.mod In case of incompleteness , Build command （gobuild、gotest、goinstall、gorun……） Will fail . The only thing that will change go.mod（ So it also changes the build ） The order is goget and gomodtidy. These commands will not be automatically or in CI Run in , So the change to the dependency tree must be intentional , And have the opportunity to pass code review .

This is very important for safety , Because when CI When the system or new machine is running , Check in (checked-in) The source code is final and complete , The code will explain what will be built , The third party has no way to influence it .

Besides , When used goget When adding dependencies , Due to the choice of the smallest version , Its cross dependencies will follow the dependent go.mod Add the version specified in the file , Instead of following the latest version . The same happens when calling goinstallexample.com/cmd/[email protected] Under the circumstances , In some ecosystems , Its equivalent will bypass pinning. stay Go in ,example.com/cmd/devtoolx The latest version of will be obtained , But all dependencies will be determined by its go.mod File settings .

If a module is broken , A new malicious version has been released , Before they explicitly update the dependency , Will not be affected in any way , This provides an opportunity to review the changes , And give the ecosystem enough time to detect events .

The content of the version will never change

Another key attribute of ensuring that third parties cannot influence the build is , The content of the module version cannot be changed . If the attacker breaks the dependency , You can upload the existing version again , They can automatically destroy all projects that depend on it .

This is it. go.sum Role of documents . It contains a list of encrypted hashes for each dependency needed to build . Again , An incomplete go.sum Can cause errors , And only goget and gomod tidy Will modify it , Therefore, any modification to it will be accompanied by intentional dependency changes . Other builds are guaranteed to have a complete set of checksums .

This is a common feature of most lock files .Go adopt Checksum Database（ abbreviation sumdb） Beyond it , It is a global 、 Only encryption verifications that can be attached go.sum List of items . When goget Need to be in go.sum When adding an entry to a file , It is from sumdb Get the entry in , Also on sumdb The integrity of the encryption is proved . This ensures that the first mock exam relies on the same dependency content for each module. , It also ensures that each module uses the same dependencies .

sumdb Make dependent content destroyed , Even Google runs Go Infrastructure cannot be modified （ for example backdoored） Source code for specific dependencies . Ensure that the code you use is consistent with other uses, such as example.com/modulex Of v1.9.2 People use exactly the same code , And has passed the review .

Last , I like the most sumdb Its characteristic is ： It does not require any key management from the module author , And can seamlessly communicate with Go The decentralization of the module is used in conjunction with .

Headline VCS Is the source of truth

Most projects are through some version control system （VCS） Developed , Then in other ecosystems , Upload to package Repository . This means that two accounts may be compromised , namely VCS Host and package Repository , The latter is used less , Easier to ignore . This also means that it is easier to hide malicious code in the version uploaded to the repository , Especially when the source code is often modified during uploading , For example, minimize it .

stay Go in , There is no such thing as a package repository account . The import path of the package is embedded with gomoddownload Information needed , So as to directly from VCS Get its module from , Where the label defines the version .

We do have Go Module Mirror, But it's just an agent . Module authors do not need to register an account , There is no need to upload the version to the agent . Agent use and go Tools have the same logic （ in fact , The agent runs gomoddownload） To get and cache versions . Because the verification database ensures that a given module version can only have one source tree , Everyone who uses an agent will see that bypassing the agent directly from VCS The results obtained are the same .（ If this version is in VCS Is no longer available in , Or its content has changed , Getting directly will result in an error , And getting from the agent may still be valid , Improves availability and protects ecosystems from “ left-click ” Impact of the problem ）.

Run on client VCS The tool will expose a considerable attack surface . This is also Go Module Mirror Another function of ： On the agency Go The tool runs in a powerful sandbox , And is configured to support all VCS Tools , The default is to support only two main VCS System （git and Mercurial）. The proxy can still be used by anyone who is not the default VCS Code released by the system , However, these codes are not accessible to attackers in most installations .

Just build code , But will not execute it

Go A clear safety design goal of the tool chain is , Even if the code is untrusted and malicious , Nor can you get or build code to execute it . This is different from most ecosystems , Many of these ecosystems provide first-class support for running code when acquiring packages . these “ After installation ” In the past, the hook was used as the most convenient way to attack ： Attack the developer's machine through the attacked dependency , And pass module The author carried out a worm attack .

To be fair , If you want to get some code , It is often implemented soon , Or as part of testing on the developer's machine , Or as part of the binary file in production , Therefore, the lack of post installation hooks will only slow down the attacker .（ There are no security boundaries in the build process ： Any software package that helps build can define an initial function ）. However , This is also a meaningful risk mitigation , Because you may be executing a binary or testing a package , Only a subset of module dependencies is used . for example , If you are in the macOS Build and execute on example.com/cmd/devtoolx, Then only Windows Dependence or example.com/cmd/othertool It's impossible for your dependence to harm your machine .

stay Go in , Modules that do not provide code for a particular build have no security impact on them .

“ A little replication is better than a little dependence ”

stay Go In ecosystem , The last and perhaps the most important software supply chain risk mitigation measure is the one with the least technical content ：Go There is a culture that rejects large dependence on trees , I'd rather copy it than add new dependencies . It goes back to Go A proverb of ：“ A little replication is better than a little dependence ”. High quality reusable Go The module is proudly worn “ Zero depends on ” The label of . If you find yourself needing a library , You'll probably find that it won't lead you to rely on dozens of modules from other authors and owners .

Rich standard libraries and other modules （golang.org/x/…… Module ） And I support that , These modules provide common high-level building blocks , Such as HTTP Stack 、TLS library 、JSON Coding, etc .

All this means that you can build rich with a small amount of dependencies 、 Complex applications . No matter how good the tools are , It doesn't eliminate the risk of reusing code , So the most powerful mitigation measure is always a small dependency tree .

Link to the original text ：

https://go.dev/blog/supply-chain