Go 的漏洞管理

Go Vulnerability Management - Go 的漏洞管理

原文:https://go.dev/security/vuln/

概述

​ 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的漏洞检测包vulncheck旨在为Go用户提供一种低噪声、可靠的方式,了解可能影响其项目的已知漏洞。漏洞检查已集成到Go的工具和服务中,包括一个新的命令行工具govulncheckGo包发现站点以及即将推出的VS Code Go

​ 要开始使用govulncheck,请从项目中运行以下命令:

$ go install golang.org/x/vuln/cmd/govulncheck@latest
$ govulncheck ./...

Go CNA

​ Go安全团队是CVE编号机构。请参见go.dev/security/vuln/cna以获取更多信息。

反馈意见

​ 我们希望您能按以下方式做出贡献,帮助我们进行改进:

常见问题

我如何报告Go项目中的漏洞?

​ 通过电子邮件将Go项目中的所有安全漏洞报告给security@golang.org。阅读Go的安全策略,了解有关我们的流程的更多信息。

我如何将公共漏洞添加到Go漏洞数据库中?

​ 要请求将公共漏洞添加到Go漏洞数据库中,请填写此表单

​ 如果漏洞已经公开披露,或者存在于您维护的包中(并且您已经准备好披露),则该漏洞被认为是公共漏洞。该表单仅适用于Go包中可导入的公共漏洞,这些包未由Go团队维护(任何Go标准库、Go工具链和golang.org模块之外的内容)。

​ 该表单还可用于请求新的CVE ID。请在此了解有关Go CVE编号机构的更多信息。

如何提出对漏洞的编辑建议?

​ 如需提出对 Go 漏洞数据库中现有报告的编辑建议,请填写此处的表格

如何报告问题或提供有关 govulncheck 的反馈?

​ 请在 Go 问题跟踪器上提交您的问题或反馈。

我在另一个数据库中发现了此漏洞。为什么它不在 Go 漏洞数据库中?

​ 报告可能会因多种原因被排除在 Go 漏洞数据库之外,包括相关漏洞不存在于 Go 包中、漏洞存在于可安装的命令而不是可导入的包中,或漏洞被另一个已经存在于数据库中的漏洞所包含。您可以在此了解有关 Go 安全团队排除报告的原因。如果您认为某个报告被错误地排除在 vuln.go.dev 之外,请告知我们

为什么 Go 漏洞数据库不使用严重性标签?

​ 大多数漏洞报告格式使用"LOW"、“MEDIUM"和"CRITICAL"等严重性标签来指示不同漏洞的影响并帮助开发人员优先考虑安全问题。但出于几个原因,Go 避免使用此类标签。

​ 漏洞的影响很少是普遍的,这意味着严重性指标通常可能是误导性的。例如,如果解析器用于解析用户提供的输入并可用于进行拒绝服务攻击,则崩溃可能是关键严重性问题,但如果解析器用于解析本地配置文件,则甚至称呼严重性为"低"可能都是过分的。

​ 标记严重性也是必然主观的。即使对于 CVE 程序也是如此,它提出了一个公式来分解漏洞的相关方面,例如攻击向量、复杂性和可利用性。然而,所有这些都需要主观评估。

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

​ 如果您想与我们分享有关此主题的想法,请随时提交问题

最后修改 February 21, 2024: 更新 (c8b41e8)