大家好，我是煎魚。

前段時間有一起比較嚴重的安全事故，引起了國內外的集中關注、討論和走查。聽說個別朋友在當時都加塞了新的活，得加班加點檢查一下。

這一連串事件，不禁讓我思考到 Go 是如何解決和防護攻擊相關的問題。周末翻到了《How Go Mitigates Supply Chain Attacks[1]》，內容物就是針對 Go 如何解決來自軟件依賴的惡意攻擊是相關的。基于此整理和調整后分享給大家。

安全事故：xz 核彈后門

這是今天內容的行業背景，如果沒提前了解的同學可以看看。@ZainanZhou 大佬的對這件事的概述。

如下圖：

圖片

什么是供應鏈攻擊

現代軟件工程是協作的，并且基于開源軟件（例如：GitHub）。這種做法使得目標容易受到供應鏈攻擊，即通過破壞軟件項目的依賴關系來進行攻擊。

通過軟件依賴項進行攻擊

盡管有任何流程或技術措施，每個依賴關系都不可避免地存在信任關系的疑慮。在這一塊領域，Go 工具做了許多的設計，有助于在不同階段降低攻擊的風險。

Go 對攻擊的防護措施

所有構建都是 “鎖定的”

外部世界的變化（例如：依賴項的新版本發布），不會自動影響 Go 的構建過程。

與其他大多數軟件包管理器文件不同，Go 模塊沒有單獨的約束列表和鎖定特定版本的鎖文件。任何 Go 構建所依賴的每個版本都完全由主模塊的 go.mod 文件決定。

自 Go 1.16 版起，這種確定性被默認執行，如果 go.mod 文件不完整，編譯命令（go build、go test、go install、go run 等）將會失敗。

唯一會改變 go.mod（進而改變編譯）的命令是：go get 和 go mod tidy。這些命令不會自動運行，也不會在 CI 中運行，需要人為控制。因此對依賴關系樹的修改必須經過深思熟慮，并有機會通過代碼審查發現。

這一點對安全性非常重要，因為當 CI 系統或新機器運行 go build 時，已簽入的源代碼是最終和完整的真實來源（即什么將被構建）。第三方無法對此產生影響。

此外，當使用 go get 添加依賴關系時，其傳遞依賴關系會按照依賴關系的 go.mod 文件中指定的版本添加，而不是按照它們的最新版本添加，這要歸功于 go mod 的最小版本選擇設計。

即使調用 go install example.com/cmd/devtoolx@latest也需要符合上述條件。在某些生態系統中，其配置的等效項會繞過固定版本。

在 Go 中，example.com/cmd/devtoolx 的最新版本將被獲取，但所有依賴關系將由其 go.mod 文件設置版本控制。

也就是說，如果某個模塊被入侵，并發布了新的惡意版本，在明確更新該依賴關系之前，任何人都不會受到影響，這就為生態系統提供了審查變更的機會和檢測事件的時間。

版本內容永不改變

確保第三方無法影響構建所需的另一個關鍵屬性是模塊版本的內容不可更改。如果攻擊者破壞了某個依賴項，并重新上傳了現有版本，那么他們就會自動破壞所有依賴于該依賴項的項目。

圖片

Kubernetes go.sum

這就是 go.sum 文件的作用。它包含了每個依賴項的加密哈希值列表，這些依賴項都對構建有貢獻。并且 go.sum 文件不完整會導致運行錯誤。

現階段 go.sum 文件只有 go get 和 go mod tidy 會修改它，因此對它的任何修改都會伴隨著有意的依賴關系變更。其編譯保證有完整的校驗和。

有了 sumdb（Checksum Database，簡稱 sumdb），被破壞的依賴關系，甚至谷歌運營的 Go 基礎架構都不可能用修改過（如被回溯過）的源代碼來攻擊特定的依賴關系。你所使用的代碼與其他正在使用 example.com/modulex v1.9.2 并已審核的人所使用的代碼完全相同。

VCS 是真相之源

大多數項目都是通過某種版本控制系統 (VCS) 開發的，然后在其他生態系統中上傳到軟件包倉庫。

圖片

最常見：git 和 svn

這意味著有兩個賬戶可能被入侵，一個是 VCS 主機，另一個是軟件包存儲庫，后者使用得更少，更容易被忽視。

這也意味著在上傳到軟件倉庫的版本中更容易隱藏惡意代碼，特別是如果源代碼在上傳過程中經常被修改，例如為了最小化惡意代碼。

在 Go 中，不存在軟件包版本庫賬戶。軟件包的導入路徑包含 go mod 下載所需的信息，以便直接從 VCS 獲取模塊，而 VCS 中的標簽定義了版本。

Go 模塊存在一個鏡像代理（例如：goproxy.cn），其在安全上有一個精妙之處：代理上的 go 工具在一個強大的沙箱中運行，并被配置為支持所有 VCS 工具，而默認情況下只支持兩個主要的 VCS 系統（git 和 Mercurial）。

使用代理的用戶仍然可以獲取使用非默認 VCS 系統發布的代碼，但在大多數安裝中，攻擊者無法獲取這些代碼。

構建代碼不會執行代碼

Go 工具鏈明確的安全設計目標是：無論是獲取代碼還是構建代碼，都不會讓代碼執行，即使它是不受信任的惡意代碼。

這一點與大多數其他生態系統不同，許多生態系統都能在獲取軟件包時運行代碼，并且支持的很好。但現實上，黑客常常會將受攻擊的依賴關系轉化為受攻擊的開發者機器，并對模塊作者進行各種危險的攻擊。

在 Go 中，不為特定模塊進行構建和運行代碼的話，不會對其產生安全影響。

少量復制勝過少量依賴

在 Go 生態系統中，最后也可能是最重要的軟件供應鏈風險緩解措施是最沒有技術含量的：Go 有一種拒絕大型依賴關系樹的文化，這種文化傾向于少量復制，而不是添加新的依賴關系。

這可以追溯到 Go 的一個諺語：“a little copying is better than a little dependency[2]”。高質量的可重用 Go 模塊自豪地貼上了 "零依賴" 的標簽。

如果你發現自己需要一個庫，你很可能發現它不會導致你依賴其他作者和所有者的數十個其他模塊。

這也得益于豐富的標準庫和附加模塊（golang.org/x/......），它們提供了常用的高級構建模塊，如 HTTP 棧、TLS 庫、JSON 編碼等。

這些意味著，只需少量的依賴關系，就能構建豐富、復雜的應用程序。無論多么優秀的工具都無法消除代碼重用的風險，因此最有力的緩解措施永遠是小型依賴關系樹。

總結

Go 這一門編程語言背靠 Google，其在企業內部有一定規模的使用了他。因此 Go 在這幾年中，Go 核心團隊的目標之一就是緩解供應鏈的攻擊，確保 Google 自身的軟件體系較為安全可靠。

今天我們了解 Go 模塊管理內的各種依賴庫的管理機制等，其通過鎖定構建的內容和版本、為 VCS 打造沙箱、構建工具的安全化等綜合手段，為 Go 提供了保障護航。

參考資料

[1]How Go Mitigates Supply Chain Attacks: https://go.dev/blog/supply-chain

[2]a little copying is better than a little dependency: https://www.youtube.com/clip/UgkxWCEmMJFW0-TvSMzcMEAHZcpt2FsVXP65