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 访问这些信息，请告知我们。