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 格式（在下面 架构 中描述）。

  请参阅 /ID/GO-2022-0191.json 获取实时示例。

批量下载

为了更轻松地下载整个 Go 漏洞数据库，可以在 vuln.go.dev/vulndb.zip 获取包含所有索引和 OSV 文件的 zip 文件。

在 govulncheck 中使用

默认情况下，govulncheck 使用 vuln.go.dev 上的规范 Go 漏洞数据库。

可以使用 -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 的漏洞检测工具将使用这些信息。

目前，生态系统特定将始终是一个具有单个字段的对象，即 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 字段是一个字符串，表示漏洞报告的审查状态。如果不存在，则应将报告视为 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 中，一个 internal/ 包，只能由包 main 导入，或者其他永远不会被其他模块导入的位置。
• 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 访问此信息将有所帮助，请告诉我们。