在安全漏洞方面，业界主要遵循三种理念：

1. 全面披露
2. 没有披露
3. 负责任的披露

在全面披露中，发现漏洞的安全研究人员会公开宣布漏洞的详细信息，并且在大多数情况下，还会提供漏洞利用的 PoC 以及披露信息。这种想法在 90 年代盛行，当时安全研究人员几乎每天都会在Full Disclosure和Bugtraq邮件列表等网站上公布 Windows、Linux 和其他软件的安全漏洞。

第二个哲学是不披露。例如，在周二补丁的情况下，Microsoft 会针对除了简短描述之外您一无所知的漏洞发布大量修复程序。与软件供应商合作的私人安全研究人员通常遵循这一理念。供应商的内部安全/质量保证团队也紧随其后。

现在遵循的第三个也是最普遍的理念是负责任的披露政策。在这里，发现漏洞的安全研究人员会给予足够的时间（在大多数情况下，至少一个月）来修复漏洞。在那之后，即使供应商没有修补安全漏洞，安全研究人员也会向公众披露漏洞和利用细节。这被称为负责任的披露，因为供应商有足够的时间提供漏洞补丁，并且不会暴露关键机器以供自由利用。

您可以遵循第三个选项，因为它是当今大多数安全研究人员都遵循的选项，并为软件供应商以及软件的安全研究人员和用户提供保护，以确保供应商将为由于即将全面披露日期的压力，该漏洞。

您可以使用一个开源的责任披露框架：

该框架由 Bugcrowd 和 CipherLaw 维护。它旨在让您的组织快速、顺利地准备好与独立的安全研究人员社区合作，同时降低研究人员和公司面临的法律风险。该政策本身的编写考虑了简单性和法律完整性。

• 设置负责任的披露计划 - 关于如何设置计划的分步最佳实践指南。
• 负责任的披露政策 - 样板披露政策。

我发现有两个与漏洞处理相关的 ISO 标准正在开发中，它们将在年底前完成：

• ISO 30111 “涵盖所有漏洞处理流程，无论它们是内部识别的还是由外部来源报告的”
• ISO 29147 “涵盖来自最终用户、安全研究人员和黑客等外部来源的漏洞披露”

我无法在网上找到这些标准的任何草案，但我很高兴在它们完成后看到它们。

在由 OpenWall 托管的开源软件安全 Wiki上有一些关于向开源项目披露安全漏洞的提示，但目前它相当简单，而且肯定不像标准模板。

您当然可以在相关的oss-security 邮件列表中找到大量示例，说明漏洞是如何由漏洞发现者或项目向公众披露的。