开源维护者安全术语指南：报告、公告与CVE的区别

blog / 2026-11-09 · 开源 · 安全

“我收到一个 CVE。”我经常从维护者那里听到这句话。这是错的。

你不会收到 CVE。你收到的是一份报告。你把它变成一份公告（advisory），然后向 CNA 申请一个 CVE ID，CNA 通常是 GitHub，但不一定非得是。

“我们发布了几个 CVE”也是错的。这听起来像是你发布了漏洞。你发布的是包含修复的版本，并发布公告。CNA 发布 CVE 记录，除非你自己就是 CNA。

如果这些话里有你不确定的词，这篇文章就是为你写的。文章余下部分会按照你作为维护者遇到它们的顺序，逐一解释。

漏洞报告是你得知问题的方式。有人发现了一个有安全影响的 bug，并私下告诉你。在 GitHub 上，这就是私有漏洞报告。

报告者打开仓库的 Security 标签页，点击“Report a vulnerability”。只有维护者和报告者能看到它。

报告是一种声称，不是事实。你的第一项工作是验证它。我收到的大多数报告都无效。

安全公告是你在漏洞确认并修复后发布的文档。它说明漏洞是什么、哪些版本受影响、哪些版本修复了它，以及用户应该怎么做。

在 GitHub 上，一旦你接受私有漏洞报告，它就会变成草稿公告。你和报告者一起编辑它，邀请协作者，并在一个临时的私有 fork 中修复问题。修复发布后，你发布公告。

每个 GitHub 公告都会获得一个 GHSA ID，例如 GHSA-86qp-5c8j-p5mr。这个 ID 属于 GitHub 的公告数据库。它不是 CVE ID。

你完全可以发布公告而不申请 CVE ID。但大多数扫描器（包括 Dependabot）和大多数安全团队都通过 CVE ID 跟踪漏洞。如果你想让用户收到警报，就申请一个。

CVE 代表 Common Vulnerabilities and Exposures（通用漏洞与暴露）。这是一个由 MITRE 运行、CISA 资助的项目，为每个公开已知的漏洞分配唯一 ID。

人们用“CVE”指代两种不同的东西：

所以准确的说法是：“我为我的公告申请了一个 CVE ID，并在我披露时发布了它。”

CNA，即 CVE Numbering Authority（CVE 编号管理机构），是由 CVE 项目授权分配 CVE ID 并发布 CVE 记录的组织。每个 CNA 都有范围：它被允许分配 ID 的产品。

当你在 GitHub 草稿公告上点击“Request CVE”时，你是在请求 GitHub 作为 CNA 分配一个 ID。GitHub 审核公告，预留 ID，并在你发布公告时发布 CVE 记录。

Starlette 中的 BadHost 正是如此。GitHub 于 5 月 22 日预留了 CVE-2026-48710，并于 5 月 26 日在我发布公告时发布了它。

如果你的项目在另一个 CNA 的范围内，则由该 CNA 分配 ID。如果项目有自己的 CNA（如 curl 或 PSF），报告者必须通过它。其他任何人都不能为其分配 CVE ID。

Root 是招募、培训和管理 CNA 的组织。每个 CNA 都隶属于一个 Root，或直接隶属于顶级 Root：MITRE 或 CISA。

只有当你想要成为 CNA 时，才需要关心 Root。Red Hat 运营着推荐给开源项目的 Root。例如，curl 是 Red Hat 下的一个 CNA。

你不需要成为 CNA 就能为你的项目获得 CVE ID。GitHub 已经覆盖了大多数开源项目。

当你想要拥有整个流程时，你才成为 CNA：

代价是一项承诺。你必须在几天内回应 CVE 争议，并保持活跃，否则会被移除。

Seth Larson 为 Python Software Foundation 经历了这一过程，并把他的笔记变成了一份面向开源项目的指南。

它涵盖了要求、步骤以及你会遇到的问题。从他在 OpenSSF 博客上的公告开始看。

我正在为 Starlette、python-multipart、Uvicorn 和 Mangum 走这个流程。我的范围和披露政策在 CVE 协调页面上。

这篇文章有用吗？考虑赞助我的开源工作。❤️