您应该让开发人员私下知道，以便他们有机会修复它。在那之后，如果你公开了这个漏洞，你应该给开发者足够的时间来修复这个问题，并且让暴露在漏洞中的人有足够的时间来升级他们的系统。就个人而言，在大多数情况下，我会允许开发人员在安全公告中发布公告，而不是自己宣布。至少，我会等待确认漏洞已得到修复。如果你有时间并且可以访问源代码，你也可以提供一个补丁。

就我个人而言，我认为负责任的披露似乎是从道德角度出发的最佳方式，并且对于 Dan Kaminsky 揭示 DNS 缓存中毒漏洞的细节非常有效。但这在很大程度上取决于您正在处理的公司或团体以及它将影响的用户群。

@VirtuosiMedia 在概述“负责任的披露”方面做得很好。

我要补充两点：

• 与供应商合作（如果可以的话），以确保他们完全理解它并且不会发布半生不熟的补丁。
• 如果供应商无视您或忽略您，请继续尝试。但是，如果他们声称这不是漏洞，请继续发布。尽可能大声。如果他们承诺修复但没有修复，请尝试从他们那里得到答案，以及他们承诺的明确时间表。在某些时候，如果他们继续推迟，最终你可能想告诉他们你无论如何都会发布 - 然后给他们一些时间来实际修复它（但时间短且有限。）

这是一个复杂的话题。几年前我参与了 TLS 重新协商漏洞的披露，相信我，我们非常努力地“负责任”，但最终，我们成功地主要是惹恼了我们周围的每个人，并且（也许）推迟了修复的实际版本。并不是说供应商通知一定是坏事，只是说它真的很容易被鞭打并最终造成与好的一样多的伤害，或者更糟。

在我们的案例中，它采取了 IETF ( RFC 5746 ) 的行动来解决这个问题，即使我们在它泄露的那天准备好了一份互联网草案，但辩论和决定解决方案的实际工作又花了大约三个月的时间，并且在披露发生之前并没有真正开始。

无论如何，这不是您问题的答案，但它是我所知道的更有趣的披露故事之一。在2010 ShmooCon 主题演讲中更多关于这个故事的内容，我和 Marsh Ray 一起做的，他发现了这个问题。