Go 漏洞管理

返回 Go 安全

概覽

Go 幫助開發者檢測、評估和解決可能被攻擊者利用的錯誤或弱點。在後臺,Go 團隊執行一個管道來整理關於漏洞的報告,這些報告儲存在 Go 漏洞資料庫中。各種庫和工具可以讀取和分析這些報告,以瞭解特定的使用者專案可能受到何種影響。此功能已整合到 Go 包發現網站 和新的 CLI 工具 govulncheck 中。

本專案仍在進行中,並處於積極開發階段。我們歡迎您的反饋,以幫助我們改進!

注意:要報告 Go 專案中的漏洞,請參閱 Go 安全策略

架構

Go Vulnerability Management Architecture

Go 中的漏洞管理包括以下高階元件

  1. 一個資料管道從各種來源收集漏洞資訊,包括 美國國家漏洞資料庫 (NVD)GitHub Advisory Database 以及直接來自 Go 包維護者
  2. 一個漏洞資料庫使用來自資料管道的資訊填充。資料庫中的所有報告都經過 Go 安全團隊的審查和整理。報告以開放原始碼漏洞 (OSV) 格式進行格式化,並且可以透過API訪問。
  3. pkg.go.dev 和 govulncheck 的整合,使開發者能夠在其專案中查詢漏洞。 govulncheck 命令會分析您的程式碼庫,並根據您的程式碼中哪些函式遞迴呼叫了易受攻擊的函式,僅顯示真正影響您的漏洞。Govulncheck 提供了一種低噪音、可靠的方式來查詢您專案中的已知漏洞。

資源

Go 漏洞資料庫

除了 Go 包維護者直接報告外,Go 漏洞資料庫還包含來自許多現有來源的資訊。資料庫中的每個條目都經過審查,以確保漏洞的描述、包和符號資訊以及版本詳細資訊準確無誤。

有關 Go 漏洞資料庫的更多資訊,請參閱 go.dev/security/vuln/database,並透過 pkg.go.dev/vuln 在瀏覽器中檢視資料庫中的漏洞。

我們鼓勵包維護者貢獻有關其自身專案中公開漏洞的資訊,並向我們傳送建議,以減少摩擦。

Go 的漏洞檢測

Go 的漏洞檢測旨在為 Go 使用者提供一種低噪音、可靠的方式來了解可能影響其專案的已知漏洞。漏洞檢查已整合到 Go 的工具和服務中,包括新的命令列工具 govulncheckGo 包發現網站,以及 VS Code 和 Go 擴充套件等主流編輯器

要開始使用 govulncheck,請在您的專案目錄中執行以下命令:

$ go install golang.org/x/vuln/cmd/govulncheck@latest
$ govulncheck ./...

要啟用編輯器中的漏洞檢測,請參閱編輯器整合頁面中的說明。

Go CNA

Go 安全團隊是CVE 編號權威機構。有關更多資訊,請參閱 go.dev/security/vuln/cna

反饋

我們非常希望您能透過以下方式為我們做出貢獻和改進

常見問題解答

如何報告 Go 專案中的漏洞?

請透過電子郵件 security@golang.org 報告 Go 專案中的所有安全錯誤。有關我們的流程的更多資訊,請閱讀Go 安全策略

如何將公開漏洞新增到 Go 漏洞資料庫?

要請求將公開漏洞新增到 Go 漏洞資料庫,請填寫此表單

如果一個漏洞已經公開披露,或者存在於您維護的包中(並且您已準備好公開披露),則該漏洞被認為是公開的。此表單僅適用於 Go 標準庫、Go 工具鏈和 golang.org 模組之外的可匯入 Go 包中的公開漏洞。

該表單還可用於請求新的 CVE ID。有關 Go CVE 編號權威機構的更多資訊,請在此處閱讀

如何建議修改漏洞?

要建議修改 Go 漏洞資料庫中現有報告,請在此填寫表單

如何報告 govulncheck 的問題或提供反饋?

請在Go 問題跟蹤器上提交您的問題或反饋。

我在另一個數據庫中發現了此漏洞。為什麼它不在 Go 漏洞資料庫中?

報告可能因各種原因被排除在 Go 漏洞資料庫之外,包括相關的漏洞不在 Go 包中、漏洞存在於可安裝的命令而不是可匯入的包中,或者漏洞已被資料庫中已存在的另一個漏洞所涵蓋。您可以在此處瞭解有關 Go 安全團隊排除報告原因的更多資訊。如果您認為某個報告被錯誤地排除在 vuln.go.dev 之外,請告知我們

為什麼 Go 漏洞資料庫不使用嚴重性標籤?

大多數漏洞報告格式都使用“低”、“中”和“嚴重”等嚴重性標籤來指示不同漏洞的影響,並幫助開發者確定安全問題的優先順序。然而,出於幾個原因,Go 避免使用此類標籤。

漏洞的影響很少是普遍的,這意味著嚴重性指標通常會產生誤導。例如,解析器中的崩潰可能是嚴重級別的漏洞,如果它用於解析使用者提供的輸入並且可以被利用進行拒絕服務攻擊;但如果解析器用於解析本地配置檔案,即使將其嚴重性標記為“低”也可能言過其實。

嚴重性的標記也必然是主觀的。即使是CVE 專案也是如此,該專案提出了一個公式來分解漏洞的相關方面,例如攻擊向量、複雜性和可利用性。然而,所有這些都需要主觀評估。

我們認為,對漏洞的良好描述比嚴重性指標更有用。良好的描述可以詳細說明問題是什麼、如何觸發以及消費者在確定對自身軟體的影響時應考慮哪些因素。

如果您想與我們分享您對此話題的想法,請隨時提交問題