Go 漏洞管理

返回 Go 安全

概述

Go 帮助开发人员检测、评估和解决可能被攻击者利用的错误或漏洞。在幕后,Go 团队运行一个管道来整理有关漏洞的报告,这些报告存储在 Go 漏洞数据库中。各种库和工具可以读取和分析这些报告,以了解特定用户项目可能受到的影响。此功能已集成到 Go 包发现站点 和一个新的 CLI 工具 govulncheck 中。

该项目正在开发中,我们欢迎您的 反馈 帮助我们改进!

注意:要报告 Go 项目中的漏洞,请参阅 Go 安全策略

架构

Go Vulnerability Management Architecture

Go 中的漏洞管理包括以下高级部分

  1. 一个数据管道从各种来源收集漏洞信息,包括 国家漏洞数据库 (NVD)GitHub 安全漏洞数据库 以及 直接来自 Go 包维护者
  2. 一个漏洞数据库使用来自数据管道的的信息填充报告。数据库中的所有报告都由 Go 安全团队进行审查和整理。报告采用 开放源代码漏洞 (OSV) 格式 格式,可以通过 API 访问。
  3. pkg.go.dev 和 govulncheck 的集成,使开发人员能够在他们的项目中查找漏洞。 govulncheck 命令 分析您的代码库,并且只显示实际上影响您的漏洞,具体取决于您的代码中的哪些函数会传递调用易受攻击的函数。Govulncheck 提供了一种低噪声、可靠的方式来查找项目中已知的漏洞。

资源

Go 漏洞数据库

Go 漏洞数据库 包含来自许多现有来源的信息,以及 Go 包维护者向 Go 安全团队直接报告的信息。数据库中的每个条目都经过审查,以确保漏洞的描述、包和符号信息以及版本详细信息准确无误。

请参阅 go.dev/security/vuln/database 以获取有关 Go 漏洞数据库的更多信息,以及 pkg.go.dev/vuln 以在浏览器中查看数据库中的漏洞。

我们鼓励包维护者 贡献 有关其自身项目中公开漏洞的信息,并 向我们发送建议 以便减少摩擦。

Go 漏洞检测

Go 的漏洞检测旨在为 Go 用户提供一种低噪声、可靠的方式来了解可能影响其项目的已知漏洞。漏洞检查已集成到 Go 的工具和服务中,包括一个新的命令行工具 govulncheckGo 包发现站点主要编辑器(如带有 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 项目中的所有安全漏洞报告给 [email protected]。阅读 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 计划 也是如此,该计划提出了一种公式来分解漏洞的相关方面,例如攻击向量、复杂性和可利用性。但是,所有这些都需要主观评估。

我们认为,对漏洞的良好描述比严重性指标更有用。良好的描述可以分解问题是什么、如何触发它以及消费者在确定其自身软件的影响时应考虑什么。

如果您想就此事与我们分享您的想法,请随时 提交问题