Go 漏洞資料庫

返回 Go 漏洞管理

概覽

Go 漏洞資料庫（https://vuln.go.dev）以 OSV 架構 的形式提供 Go 漏洞資訊。

您還可以瀏覽資料庫中的漏洞，網址是 pkg.go.dev/vuln。

請勿依賴 x/vulndb Git 倉庫的內容。該倉庫中的 YAML 檔案是使用內部格式維護的，可能會在未通知的情況下更改。

Contributing

我們希望所有 Go 包維護者都能 貢獻 其自身專案中的公開漏洞資訊，並 更新 其 Go 包中現有漏洞的資訊。

我們的目標是讓報告過程儘可能地簡便，因此請隨時 向我們傳送您的建議。

請不要使用上述表單報告 Go 標準庫或子倉庫中的漏洞。而是按照 go.dev/security/policy 中的流程處理 Go 專案相關的漏洞。

API

規範的 Go 漏洞資料庫 https://vuln.go.dev 是一個 HTTP 伺服器，可以響應以下端點定義的 GET 請求。

這些端點沒有查詢引數，也不需要特定的標頭。因此，即使是來自固定檔案系統（包括 file:// URL）的服務也可以實現此 API。

每個端點都返回一個 JSON 編碼的響應，可以是未壓縮的（如果請求為 .json）或壓縮的（如果請求為 .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]

  以 OSV 格式（將在 架構 中進一步說明）返回 ID 為 $id 的漏洞的單個報告。

  請參閱 /ID/GO-2022-0191.json 的即時示例。

批次下載

為了更方便地下載整個 Go 漏洞資料庫，包含所有索引和 OSV 檔案的 zip 檔案可在 vuln.go.dev/vulndb.zip 下載。

在 govulncheck 中的用法

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

可以使用 -db 標誌配置該命令以連線到不同的漏洞資料庫。該標誌接受一個協議為 http://、https:// 或 file:// 的漏洞資料庫 URL。

為了與 govulncheck 正確配合使用，指定的漏洞資料庫必須實現上述 API。govulncheck 命令在從 http(s) 源讀取時使用壓縮的 “.json.gz” 端點，在從檔案源讀取時使用 “.json” 端點。

舊版 API

規範資料庫包含一些作為舊版 API 一部分的附加端點。我們計劃很快移除對這些端點的支援。如果您依賴舊版 API 並需要額外時間遷移，請告知我們。

架構

報告使用 OSV 架構。Go 漏洞資料庫對這些欄位賦予以下含義：

id

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

affected

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 陣列，包含受漏洞影響的包和符號。陣列中的每個物件將包含這兩個欄位：

• path: 一個字串，包含包含漏洞的包的匯入路徑
• symbols: 一個字串陣列，包含包含漏洞的符號（函式或方法）的名稱
• 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 欄位是一個字串，表示漏洞報告的審查狀態。如果不存在，則應認為報告已審查。可能的值為：

• 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：漏洞發生在 package main、僅由 package main 匯入的 internal/ 包，或任何其他無法被其他模組匯入的位置。
• EFFECTIVELY_PRIVATE：雖然漏洞發生在可被其他模組匯入的 Go 包中，但該包不打算供外部使用，並且不太可能在定義它的模組之外被匯入。
• DEPENDENT_VULNERABILITY：此漏洞是資料庫中另一個漏洞的子集。例如，如果包 A 包含漏洞，包 B 依賴於包 A，並且包 A 和包 B 有單獨的 CVE ID，我們可能會將包 B 的報告標記為完全被包 A 的報告所取代的依賴漏洞。
• NOT_A_VULNERABILITY：雖然已分配 CVE ID 或 GHSA，但與之關聯的已知漏洞不存在。
• WITHDRAWN：漏洞已由其來源撤回。

目前，排除的報告未透過 vuln.go.dev API 提供。但是，如果您有特定的用例，並且希望透過 API 訪問這些資訊，請告知我們。