Go 漏洞資料庫

返回 Go 漏洞管理

概觀

Go 漏洞資料庫 (https://vuln.go.dev) 提供符合開放原始碼漏洞 (OSV) 架構的 Go 漏洞資訊。

您也可以瀏覽 pkg.go.dev/vuln 中資料庫中的漏洞。

不要依賴 x/vulndb Git 儲存庫中的內容。此儲存庫中的 YAML 檔案使用可能在沒有警告的情況下變更的內部格式來維護。

貢獻

我們熱烈歡迎所有 Go 套件維護人員貢獻自己專案中公開漏洞的資訊，並更新關於 Go 套件中漏洞的現有資訊。

我們目標在於讓回報變成一個無摩擦的程序，所以歡迎您傳送您的建議。

請不要使用上述表單回報 Go 標準函式庫或子儲存庫中的漏洞。反之，請遵循 go.dev/security/policy 中關於 Go 專案漏洞的程序。

API

正式的 Go 漏洞資料庫 https://vuln.go.dev 是 HTTP 伺服器，可以回應以下指定的端點的 GET 要求。

端點沒有查詢參數，而且沒有特定標頭需求。由於這樣的情況，即使從固定檔案系統（包括 file:// URL）提供服務的網站，也能執行此 API。

每個端點傳回 JSON 編碼的回應，採用未壓縮（如果要求為 .json）或 gzip 形式（如果要求為 .json.gz）。

以下是端點

/index/db.json[.gz]

傳回關於資料庫的元資料
```
{
  // The latest time the database should be considered
  // to have been modified, as an RFC3339-formatted UTC
  // timestamp ending in "Z".
  "modified": string
}
```
請注意，不應將修改時間與實際時間進行比較，例如，用於快取失效，原因是資料庫修改可能會有延遲才會實際生效。

請參閱 /index/db.json 以取得即時範例。

/index/modules.json[.gz]

傳回包含資料庫中每個模組元資料的清單

[ {
  // The module path.
  "path": string,
  // The vulnerabilities that affect this module.
  "vulns":
    [ {
      // The vulnerability ID.
      "id": string,
      // The latest time the vulnerability should be considered
      // to have been modified, as an RFC3339-formatted UTC
      // timestamp ending in "Z".
      "modified": string,
      // (Optional) The module version (in SemVer 2.0.0 format)
      // that contains the latest fix for the vulnerability.
      // If unknown or unavailable, this should be omitted.
      "fixed": string,
    } ]
} ]

請參閱 /index/modules.json 以取得即時範例。

/index/vulns.json[.gz]

傳回包含資料庫中每個漏洞元資料的清單

 [ {
     // The vulnerability ID.
     "id": string,
     // The latest time the vulnerability should be considered
     // to have been modified, as an RFC3339-formatted UTC
     // timestamp ending in "Z".
     "modified": string,
     // A list of IDs of the same vulnerability in other databases.
     "aliases": [ string ]
 } ]

請參閱 /index/vulns.json 以取得即時範例。

/ID/$id.json[.gz]

傳回 ID 為 $id 漏洞的個別報告，採用 OSV 格式（如以下 Schema 所述）。

請參閱 /ID/GO-2022-0191.json 以取得即時範例。

大量下載

為了讓下載整個 Go 漏洞資料庫更簡單，可以在 vuln.go.dev/vulndb.zip 找到包含所有索引和 OSV 檔案的 zip 檔案。

在 `govulncheck` 中使用

預設情況下，govulncheck 使用 vuln.go.dev 中的正規 Go 漏洞資料庫。

可以使用 -db 標記，將指令配置為連絡不同的漏洞資料庫，此標記會接受漏洞資料庫 URL，其中協定為 http://、https:// 或 file://。

為與 govulncheck 正確運作，指定的漏洞資料庫必須執行上述 API。當從 http(s) 來源讀取時，govulncheck 指令會使用壓縮的「.json.gz」端點，當從檔案來源讀取時，會使用「.json」端點。

舊版 API

正規資料庫包含一些是舊版 API 一部分的其他端點。我們計畫盡快移除對於這些端點的支援。如果您依賴舊版 API 並需要額外的時間來遷移，請告知我們。

Schema

報告使用開源漏洞 (OSV) schema。Go 漏洞資料庫會對欄位指派下列意義

id

id 欄位是漏洞條目的唯一識別碼。它是 GO-<YEAR>-<ENTRYID> 格式的字串。

affected

受影響的欄位是包含物件的 JSON 陣列，用來描述包含漏洞的模組版本。

affected[].package

affected[].package 欄位是 JSON 物件，用來識別受影響的 模組。 物件有兩個必填欄位

ecosystem：永遠為「Go」
name：這是 Go 模組路徑
- 標準函式庫中的可導入套件會有名稱 stdlib。
- go 指令會有名稱 toolchain。

affected[].ecosystem_specific

affected[].ecosystem_specific 欄位是 JSON 物件，其中包含有關漏洞的額外資訊，這些資訊會由 Go 的漏洞偵測工具使用。

目前 ecosystem specific 永遠會是具有單一欄位的物件，即 imports。

affected[].ecosystem_specific.imports

affected[].ecosystem_specific.imports 欄位是 JSON 陣列，其中包含受漏洞影響的套件和符號。陣列中的每個物件都會有這兩個欄位

路徑：包含漏洞的套件的匯入路徑字串
符號：包含漏洞的符號 (函式或方法) 名稱字串陣列
goos：符號出現的執行作業系統字串陣列 (如果已知)
goarch：符號出現的架構字串陣列 (如果已知)

database_specific

database_specific 欄位包含特定於 Go 漏洞資料庫的客製化欄位。

database_specific.url

database_specific.url 欄位是表示 Go 漏洞報告完整 URL 的字串，例如，「https://pkg.go.dev/vuln/GO-2023-1621"」。

database_specific.review_status

database_specific.review_status 欄位是表示漏洞報告審查狀態的字串。如果不存在，應將報告視為 REVIEWED。可能的值為

UNREVIEWED：報告是根據另一個來源 (例如 CVE 或 GHSA) 自動產生的。其資料可能有限，且尚未經 Go 團隊驗證。
REVIEWED：報告來自 Go 團隊，或基於外部來源產生。Go 團隊的成員已審查報告，並在適當情況下新增額外資料。

如需了解架構中其他欄位的資訊，請參閱 OSV 規範。

版本注意事項

我們的工具會嘗試根據標準的 Go 模組版本號碼，自動將來源通告中的模組和版本對應到標準的 Go 模組和版本。像 govulncheck 這樣的工具，會根據這些標準的版本判定 Go 專案是否受到相依性的漏洞影響。

在某些情況下，例如當 Go 專案使用自己的版本編號方案時，可能會無法對應到標準的 Go 版本。當發生此情況時，Go 漏洞資料庫報告可能會保守地將所有 Go 版本列為受影響版本。這可確保像 govulncheck 這樣的工具，不會因無法辨識的版本範圍而導致漏洞報告失敗（偽負面）。不過，若保守地將所有版本都列為受影響版本，可能會導致工具錯誤地報告模組已修復的版本中仍包含漏洞（偽正面）。

如果你認為 govulncheck 錯誤地報告（或未報告）漏洞，請建議編輯漏洞報告，我們會審查它。

範例

Go 漏洞資料庫中的所有漏洞，都採用上述的 OSV 架構。

請參閱以下連結，取得不同 Go 漏洞範例

Go 標準函式庫漏洞 （GO-2022-0191）：JSON，HTML
Go 工具鏈漏洞 （GO-2022-0189）：JSON，HTML
Go 模組中的漏洞 （GO-2020-0015）：JSON，HTML

已排除報告

Go 漏洞資料庫中的報告，是由不同的來源蒐集，並由 Go 安全團隊策劃的。我們可能會發現漏洞通告（例如 CVE 或 GHSA），並因各種原因決定將其排除。在這些情況下，會在 x/vulndb 儲存庫中的 x/vulndb/data/excluded 下，建立一份簡要的報告。

報告可能會因以下原因而被排除。

NOT_GO_CODE：漏洞並非在 Go 套件中，但它被其他來源標記為 Go 生態系的安全性通告。這個漏洞不會影響任何 Go 套件。（例如，C++ 函式庫中的漏洞。）
NOT_IMPORTABLE：此漏洞發生於套件 main，這是由套件 main 獨家輸入的 internal/ 套件，或是一些永遠不會被其他模組輸入的其他位置。
EFFECTIVELY_PRIVATE：雖然此漏洞發生於可由其他模組輸入的 Go 套件中，此套件不打算供外部使用，且不太可能會在定義此套件的模組外輸入。
DEPENDENT_VULNERABILITY：此漏洞是資料庫中另一漏洞的子集。舉例來說，如果套件 A 包含漏洞，套件 B 仰賴套件 A，且套件 A 和 B 有個別的 CVE ID，我們可能會將 B 的報告標記為完全由 A 的報告取代的仰賴漏洞。
NOT_A_VULNERABILITY：雖然已指派 CVE ID 或 GHSA，但尚無與其相關聯已知的漏洞。

目前，已排除的報告未透過 vuln.go.dev API 顯示。不過，如果您有特定使用案例，且希望能透過 API 存取此資訊，請告知我們。