本文翻译自《Go Vulnerability Management》。
点此回到《Go安全》。
概述
Go可以帮助开发人员检测、评估和解决有可能被攻击者利用的代码Bug或弱点。在幕后，Go团队运行一个管道来策划有关漏洞的报告，这些报告存储在Go漏洞数据库中。可以阅读和分析各种库和工具的这些报告，以了解特定用户项目可能受到的影响。此功能已集成到Go软件包发现站点和新的CLI工具govulcheck中。
该项目正在推进中，正在积极开发中。我们欢迎你的反馈，帮助我们改进！
注意：要报告Go项目中的漏洞，请参阅Go安全策略。
架构
Go中的漏洞管理由以下高级部分组成：
- 数据管道从各种来源收集漏洞信息，包括国家漏洞数据库（NVD）、GitHub咨询数据库，以及直接从Go包维护者那里收集。
- 漏洞数据库由使用数据管道中的信息的报告填充。数据库中的所有报告都由Go Security团队进行审查和策划。报告采用开放源代码漏洞（OSV）格式，可通过API访问。
- 与pkg.go.dev和govulcheck集成，使开发人员能够发现项目中的漏洞。govulncheck命令分析代码库，并根据正在直接或间接调用易受攻击的函数的那些代码来显示实际影响到你的漏洞。Govulncheck提供了一种低噪声、可靠的方法来查找项目中的已知漏洞。
资源
Go漏洞数据库
Go漏洞数据库包含来自许多现有来源的信息，此外还有Go包的维护人员直接向Go安全团队的报告。数据库中的每个条目都会被审查，以确保漏洞的描述、包和符号的信息以及版本的详细信息是准确的。
有关go漏洞数据库的更多信息，请参阅go.dev/security/vuln/database，在浏览器中查看数据库中的漏洞信息，请参阅pkg.go.dev/vuln。
我们鼓励包的维护人员在自己的项目中提供有关漏洞的信息，并向我们发送如何减少该漏洞造成的影响的建议。
Go漏洞检测
Go的漏洞检测旨在为Go用户提供一种低噪声、可靠的方式来了解可能影响其项目的已知漏洞。漏洞检测集成到Go的工具和服务中，包括一个新的命令行工具govulcheck、Go包发现网站、主流的编辑器，例如带有Go扩展的VS Code。
要开始使用govulcheck，请在项目中运行以下命令语句：
$ go install golang.org/x/vuln/cmd/govulncheck@latest
$ govulncheck ./...要在编辑器中启用漏洞检测，请参阅编辑器集成漏洞检测插件页面中的说明。
Go CNA
Go安全团队是一个CVE编号机构(CVE Numbering Authority)。有关更多信息，请参阅go.dev/security/vuln/cna。
反馈
我们希望你在以下方面做出贡献并帮助我们改进：
- 为你维护的Go包提供有关公共漏洞的新信息或更新现有的信息
- 参加此调查以分享你使用govulcheck的经验
- 向我们发送有关问题和功能的反馈
FAQ
如何报告Go项目中的漏洞？
通过电子邮件向[email protected]报告Go项目中的所有安全漏洞。有关我们流程的更多信息，请阅读Go的安全政策。
如何将公共漏洞添加到Go漏洞数据库？
要将公共漏洞添加到Go漏洞数据库，请填写此表单。
如果漏洞已经公开披露，或者存在于你维护的包中（并且你已准备好披露），则该漏洞被视为公开漏洞。该表单仅适用于不由Go团队维护的可导入的Go包中的公共漏洞（Go标准库、Go工具链和golang.org模块之外的任何包）。
该表单也可用于申请新的CVE ID。点击此处了解更多关于Go CVE编号机构的信息。
如何提议对漏洞进行编辑？
提议编辑Go漏洞数据库中的现有报告，请填写此处的表单。
我如何报告问题或提供有关govulcheck的反馈？
在Go问题跟踪器上提交你的问题或反馈。
我在另一个数据库中发现了此漏洞，为什么它不在Go漏洞数据库中？
由于各种原因，报告可能会被排除在Go漏洞数据库之外，包括相关漏洞不存在于Go包中，存在于可安装命令而非可导入包中，或者该漏洞被数据库中已存在的另一个漏洞所包含。你可以在此处了解更多关于Go Security团队排除报告的原因。如果你认为某个报告被错误地排除在vuln.gov之外，请告诉我们。
为什么Go漏洞数据库不使用严重级别标签？
大多数漏洞报告格式使用严重性标签，如“LOW”、“MEDIUM”和“CRITICAL”，以指示不同漏洞造成的影响程度，并帮助开发人员确定安全问题的优先处理级别。然而，由于几个原因，Go避免使用此类标签。
漏洞的影响很少是普遍的，这意味着严重性指标往往具有欺骗性。例如，如果解析器用于解析用户提供的输入，并且可以被DoS攻击利用，那么解析器中的漏洞可能是一个严重的问题，但如果解析器只是用于分析本地配置文件，即使将严重性称为“低”也可能言过其实。
严重程度也必然是主观的。即使对于CVE程序也是如此，该程序假定了一个公式来分解漏洞的相关方面，如攻击向量、复杂性和可利用性。然而，所有这些都需要主观评价。
我们认为，对漏洞的良好描述比严重性指标更有用。一个好的描述可以分解什么是问题，如何触发问题，以及用户在确定对自己软件的影响时应该考虑什么。
如果你想与我们分享你对此主题的想法，请随时提交一个议题。