关于存储库安全公告
漏洞披露是漏洞报告者（如安全研究人员）和项目维护者之间协作非常重要的领域。 双方需要从发现潜在有害安全漏洞的那一刻起共同努力，直到向世界披露漏洞，最好有可用的修补程序。 通常，当有人让维护者私下了解安全漏洞时，维护者会开发修复程序、验证修复程序并通知项目或包的用户。 更多信息，请参阅 关于安全漏洞的协调披露。
使用存储库安全公告，公共存储库的维护人员可私下讨论和修复项目中的安全漏洞。 协作得到修补程序后，存储库维护人员可发布安全通知，向项目社区公开安全漏洞。 通过发布安全通知，存储库维护人员可使其社区更轻松地更新包依赖项并对安全漏洞的影响进行调查。
使用存储库安全公告，可以执行以下操作：
- 创建安全通告草稿，并使用草稿私下讨论漏洞对项目的影响。
- 在临时私有复刻中私下协作以修复漏洞。
- 在补丁发布后发布通告向社区提醒漏洞。
数据可复用.库.安全公告再发布 %}
还可以使用 REST API 创建、列出和更新存储库安全公告。 有关详细信息，请参阅“适用于存储库安全公告的 REST API 终结点”。
您可以向为安全通告做出贡献的个人提供积分。 有关详细信息，请参阅“编辑存储库安全通告”。
您可以创建安全策略，向人们提供有关报告项目中安全漏洞的说明。 有关详细信息，请参阅“将安全策略添加到存储库”。
如果您在仓库中创建了安全通告，安全通告将保留在您的仓库中。 我们在 github.com/advantores 上的 GitHub Advisory Database 发布任何由依赖关系图支持的生态系统的安全公告。 任何人都可以提交对 GitHub Advisory Database 中发布的公告的更改。 有关详细信息，请参阅“在 GitHub Advisory Database 中编辑安全公告”。
如果安全通告是专门针对 npm 的，我们也会向 npm 安全通告发布该通告。 有关详细信息，请参阅 npmjs.com/advisories。
CVE 识别号
GitHub Security Advisories 基于通用漏洞披露 (CVE) 列表而构建。 在 GitHub 上的安全通告表是符合 CVE 描述格式的标准化表格。
GitHub 是 CVE 编号颁发机构 (CNA)，被授权分配 CVE 标识号。 更多信息，请参阅 CVE 网站上的关于 CVE 及 CVE 编号机构的内容。
在 GitHub 上为公共仓库创建安全通告时，您可以选择为安全漏洞提供现有的 CVE 标识号。
在您发布了安全通告并且 GitHub 为漏洞分配 CVE 标识号后，GitHub 会将 CVE 发布到 MITRE 数据库。
发布安全公告
发布安全公告会通知社区其解决的漏洞，使其更容易更新包依赖项并研究漏洞的影响。
从公共存储库发布草稿公告时，可见性级别会有所不同，如下所示：
-
**任何人都可以** 查看当前版本的咨询数据，以及信用用户已接受的任何咨询信用额度。 -
**协作者** 可以查看公告的对话历史记录。
发布后安全公告的 URL 不会更改。
如果需要更新或更正已发布的安全通告中的信息，可以编辑安全通告。 请参阅“编辑存储库安全通告”。
对于发布的安全通告的 Dependabot alerts
GitHub 将审查每个发布的安全通告，将其添加到 GitHub Advisory Database， 并且可能使用安全通告向受影响的仓库发送 Dependabot alerts 警报。 如果安全通告来自派生库，我们只有在该派生库拥有一个在公共软件包注册表上以唯一名称发布的软件包时才会发送警报。 此过程最长可能需要 72 小时，GitHub 可能会联系您以获取更多信息。
修复版本的重要性
在发布公告之前，应尽可能将 修补程序版本添加到安全公告中。 否则，通告将在没有修复版本的情况下发布，并且 Dependabot 将向您的用户提醒有关问题，而不需提供任何安全版本来更新。
根据漏洞，可能需要调整方法。 如果修复版本为：
-
**即将可用**，而且如果你能够，可以等待修复准备就绪后再披露问题。 -
**在开发中但尚不可用**，在公告中提及这一点，并在发布后稍后编辑公告。 -
**未计划**，请在公告中明确说明，以便你的用户不会联系你询问何时进行修复。 在这种情况下，列入用户可用于缓解这一问题的步骤会有帮助。