Go 漏洞管理
概觀
Go 協助開發人員偵測、評估和解決有遭受攻擊者利用風險的錯誤或弱點。幕後，Go 團隊執行一項自動化程序來整理有關漏洞的報告，這些報告會儲存在 Go 漏洞資料庫中。各個函式庫和工具可以讀取和分析這些報告，以了解特定使用者專案可能會受到哪些影響。這項功能已整合至 Go 套件探索網站 和一款新的 CLI 工具 govulncheck。
這個專案正在進行中並積極開發。我們歡迎您提供 回饋 以協助我們改進！
注意：如要回報 Go 專案中的漏洞，請參閱 Go 安全政策。
架構
Go 中的漏洞管理包含下列高階區塊
- 資料管線會從各種來源蒐集漏洞資訊，包括 國家漏洞資料庫 (NVD)、GitHub 公告資料庫，以及 來自 Go 套件維護人員的直接回報。
- 漏洞資料庫採用資料管線的資訊填入報告，其中資料庫中的所有報告都由 Go 安全團隊檢閱和整理。報告都使用 開源漏洞 (OSV) 格式 編寫，並可透過 API 存取。
- 與 pkg.go.dev 和 govulncheck 整合，讓開發人員能找出專案中的漏洞。 govulncheck 指令 會分析您的程式碼庫，並僅指出實際會影響您的漏洞，根據您程式碼中會轉址呼叫漏洞功能的函式。Govulncheck 提供可靠的低雜訊方法，可在您的專案中找出已知的漏洞。
資源
Go 漏洞資料庫
Go 漏洞資料庫 除了 Go 套件維護人員直接向 Go 安全團隊回報的資訊外，還包含許多現有來源的資訊。資料庫中的每個項目都會經過檢閱，以確保漏洞的描述、套件和符號資訊，以及版本詳細資料的正確性。
請參閱 go.dev/security/vuln/database 以進一步了解 Go 漏洞資料庫，並參閱 pkg.go.dev/vuln，在瀏覽器中檢視資料庫中的漏洞。
我們鼓勵套件維護人員 提供 自己專案中公開漏洞的資訊，並 向我們傳送建議，告知如何降低摩擦。
針對 Go 的漏洞偵測
Go 的漏洞偵測旨在提供可靠的低雜訊方法，讓 Go 使用者能了解可能會影響其專案的已知漏洞。漏洞檢查整合在 Go 的工具和服務中，包括新的命令列工具 govulncheck、Go 套件探索網站、配合 Go 擴充功能的 主要編輯器，例如 VS Code。
若要開始使用 govulncheck，請從專案中執行下列命令
$ go install golang.org/x/vuln/cmd/govulncheck@latest
$ govulncheck ./...
若要在編輯器中啟用漏洞偵測，請參閱 編輯器整合 頁面中的說明。
Go CNA
Go 安全團隊是 CVE 編號管理機關。請參閱 go.dev/security/vuln/cna 以進一步了解。
意見回饋
非常歡迎您透過以下方式提供貢獻並幫助我們進行改善
常見問答集
我如何回報 Go 專案中的漏洞？
透過電子郵件將所有 Go 專案中的安全性漏洞回報給 security@golang.org。閱讀 Go 的安全性政策 來取得關於我們流程的更多資訊。
我如何將公開漏洞新增到 Go 漏洞資料庫中？
若要要求新增公開漏洞到 Go 漏洞資料庫，請填寫這份表單。
如果漏洞已經公開揭露，或存在於你維護的套件中（且你準備要揭露），則漏洞可被視為公開的。此表單僅適用於可匯入的 Go 套件，且並未由 Go 團隊所維護的公開漏洞（Go 標準程式庫、Go 工具鏈和 golang.org 模組以外的所有內容）。
此表單也可拿來要求取得新的 CVE ID。請在此處閱讀關於 Go CVE 編號管理單位的更多資訊。
我如何建議修改漏洞？
若要建議修改 Go 漏洞資料庫中的現有報告，請填寫此處的表單。
我如何回報問題或提供關於 govulncheck 的回饋？
在 Go 問題追蹤器中提出你的問題或回饋。
我在其他資料庫中找到這個漏洞，為什麼它不在 Go 漏洞資料庫中？
報告可能會因為各種原因而被排除在 Go 漏洞資料庫之外，包括相關漏洞並不存在於 Go 套件中、漏洞存在於可安裝指令而非可匯入套件中，或漏洞已被資料庫中已存在的其他漏洞所包含。你可以在這裡進一步瞭解 Go 安全團隊排除報告的原因。如果你認為某個報告被不正確地排除在 vuln.go.dev 之外，請讓我們知道。
為什麼 Go 漏洞資料庫不使用嚴重性標籤？
大多數漏洞回報格式使用像「低」、「中」和「嚴重」等嚴重性標籤來顯示不同漏洞的影響，以協助開發人員將安全性問題的優先順序排序。然而，基於以下數個原因，Go 避免使用此類標籤。
漏洞的影響很少具有普遍性，這意味著嚴重性指標往往具有欺騙性。例如，解析器出現當機問題，如果這個解析器用於解析使用者提供的輸入，且可用於阻斷服務攻擊，這可能會成為一項重大嚴重性問題。但是，如果這個解析器用於解析本機設定檔，即使將其嚴重性評為「低」也可能會誇大其詞。
對嚴重性進行標籤分類必定是主觀的。即使對於CVE 計畫來說也是如此，該計畫提出了分解漏洞相關層面的公式，例如攻擊媒介、複雜性、可利用性。但是，所有這些都需要主觀評估。
我們認為良好的漏洞描述比嚴重性指標更為有用。良好的描述可以分解問題是什麼、它是如何觸發的，以及消費者在決定對其自己的軟體影響時應該考慮什麼。
如果你希望針對此主題與我們分享你的想法，請隨時提交問題。