任何对仓库有管理员权限的人都可以创建安全通告。
拥有仓库管理员权限的任何人，对该仓库中的所有安全通告也拥有管理员权限。 对安全通告拥有管理员权限的人可以添加协作者，而协作者对安全通告拥有写入权限。
注意：如果你是安全研究人员，应直接联系维护人员，要求他们创建安全通告，或在你不管理的存储库中代表你发布 CVE。 但是，如果为存储库启用了私人漏洞报告，则可以自行私下报告漏洞。 有关详细信息，请参阅“私下报告安全漏洞”。
About repository security advisories
漏洞披露是漏洞报告者（如安全研究人员）和项目维护者之间协作非常重要的领域。 双方需要从发现潜在有害安全漏洞的那一刻起共同努力，直到向世界披露漏洞，最好有可用的修补程序。 通常，当有人让维护者私下了解安全漏洞时，维护者会开发修复程序、验证修复程序并通知项目或包的用户。 For more information, see "关于安全漏洞的协调披露."
使用存储库安全公告，存储库维护人员可私下讨论和修复项目中的安全漏洞。 协作得到修补程序后，存储库维护人员可发布安全通知，向项目社区公开安全漏洞。 通过发布安全通知，存储库维护人员可使其社区更轻松地更新包依赖项并对安全漏洞的影响进行调查。
With repository security advisories, you can:
- Create a draft security advisory, and use the draft to privately discuss the impact of the vulnerability on your project. For more information, see "创建存储库安全公告."
- Privately collaborate to fix the vulnerability in a temporary private fork.
- Publish the security advisory to alert your community of the vulnerability once a patch is released. For more information, see "发布存储库安全公告."
还可以使用存储库安全公告重新发布已在其他地方披露的安全漏洞详细信息，方法是将该漏洞的详细信息复制并粘贴到新的安全公告中。
You can also use the REST API to create, list, and update repository security advisories. For more information, see "存储库安全公告" in the REST API documentation.
You can give credit to individuals who contributed to a security advisory. For more information, see "编辑存储库安全通告."
您可以创建安全策略，向人们提供有关报告项目中安全漏洞的说明。 有关详细信息，请参阅“将安全策略添加到存储库”。
If you created a security advisory in your repository, the security advisory will stay in your repository. We publish security advisories for any of the ecosystems supported by the dependency graph to the GitHub Advisory Database on github.com/advisories. Anyone can submit a change to an advisory published in the GitHub Advisory Database. For more information, see "在 GitHub Advisory Database 中编辑安全公告."
If a security advisory is specifically for npm, we also publish the advisory to the npm security advisories. For more information, see npmjs.com/advisories.
还可加入 GitHub Security Lab，以浏览与安全相关的主题，并为安全工具和项目做出贡献。
CVE identification numbers
GitHub Security Advisories builds upon the foundation of the Common Vulnerabilities and Exposures (CVE) list. The security advisory form on GitHub is a standardized form that matches the CVE description format.
GitHub is a CVE Numbering Authority (CNA) and is authorized to assign CVE identification numbers. For more information, see "About CVE" and "CVE Numbering Authorities" on the CVE website.
When you create a security advisory for a public repository on GitHub, you have the option of providing an existing CVE identification number for the security vulnerability. 如果你需要项目中的安全漏洞的 CVE 标识号，但尚未获得，则可从 GitHub 请求 CVE 标识号。 GitHub 通常在 72 小时内审核请求。 请求 CVE 识别码不会公开您的安全通告。 如果您的安全通告符合 CVE 条件，GitHub 将为您的通告保留 CVE 识别码。 然后，我们将在公开安全通告后发布 CVE 详细信息。 对安全通告具有管理员权限的任何人都可以申请 CVE 标识号。
如果您已经拥有要使用的 CVE，例如，如果您使用 GitHub 以外的 CVE Numbering Authority (CNA)，请将 CVE 添加到安全通告表。 例如，如果您想要获得与计划在发布时间发送的其他通信一致的通告，则可能会发生这种情况。 如果你的项目由其他 CNA 涵盖，则 GitHub 无法向你的项目分配 CVE。
Once you've published the security advisory and GitHub has assigned a CVE identification number to the vulnerability, GitHub publishes the CVE to the MITRE database. For more information, see "发布存储库安全公告."
Dependabot alerts for published security advisories
GitHub 将审查每个发布的安全通告，将其添加到 GitHub Advisory Database， 并且可能使用安全通告向受影响的仓库发送 Dependabot alerts 警报。 如果安全通告来自复刻，我们仅当该复刻拥有在公共软件包注册表上以唯一名称发布的软件包时才发送警报。 此过程最长可能需要 72 小时，GitHub 可能会联系您以获取更多信息。
有关 Dependabot alerts 的详细信息，请参阅“关于 Dependabot 警报”和“关于 Dependabot 安全更新”。 有关 GitHub Advisory Database 的详细信息，请参阅“在 GitHub Advisory Database 中浏览安全公告”。