出站协调漏洞披露政策

# 出站协调披露政策 来源：https://openai.com/policies/outbound-coordinated-disclosure-policy/ OpenAI致力于通过负责任地披露第三方软件中发现的漏洞来增强全球软件安全。本政策规定了OpenAI如何向供应商和开源维护者报告和披露我们在第三方软件中发现的漏洞。在这些报告中，我们致力于开展合作、产生影响并维护高完整性标准。 本政策阐述了我们如何通过自动化和手动代码审查披露开源和商业软件中发现的问题，以及从内部使用第三方软件和系统中发现的问题。检测方法可能包括： - AI或Agent驱动的应用安全分析。 - 开源软件的安全研究、审计和模糊测试。 - 对OpenAI运营中使用的供应商提供或第三方软件的评估。 - 其他适当的方法。 **生态安全：** 主要目标是改善生态安全。 **合作性：** 善意、有益的沟通。第三方入站披露流程得到尊重，但本政策中的例外情况除外。 **默认谨慎：** 初始披露是私密的。公开披露通常仅在获得明确的供应商或开源维护者同意后进行，但下文列明的例外情况除外。 **高规模、低摩擦：** 发送经过验证、可操作的披露。 **相关时注明出处：** 漏洞将归功于OpenAI安全研究 - Aardvark发现。在适用情况下，我们可能会将发现归功于特定个人、系统或Agent。 1. 识别和验证 发现后，每项发现都会经过安全影响验证。报告通常包括： - 影响摘要（例如，拒绝服务、内存损坏） - 受影响的版本/提交范围 - 复现步骤或概念验证(PoC)（如可能） - 复现辅助工具（例如Docker镜像）（如可行） 2. 同行评审 每份披露在发布前都经过内部审查流程，包括安全工程师对准确性、可重现性和质量的同行评审。 - 如果漏洞由自动化系统发现，安全工程师在发布前审查披露。 - 如果漏洞由安全工程师发现，第二名安全工程师审查披露。 3. 安全项目经理协调披露、维护记录并管理供应商互动。 4. 披露流程 - **报告渠道。** 我们通常会遵循接收披露的供应商或开源维护者的入站披露程序。我们保留按自己的判断遵循其他程序的权利。我们首选的披露方法包括供应商安全电子邮件（例如公司的产品安全事件响应团队电子邮件接收）或私密GitHub报告。默认避免向GitHub Issues等公开跟踪系统提交。我们通常不参与漏洞赏金计划。 - **内部处理。** OpenAI的出站披露通信通过专门的邮件列表管理。为了保护保密性和谨慎性，此邮件列表的访问权限在内部受限。在内部，我们披露团队的成员将审查我们对受影响产品或代码的使用情况。如果发现使用，我们将根据我们的政策与相应团队互动。 - **外部披露。** 在某些情况下，在缺乏供应商或开源维护者同意的情况下，OpenAI可能会与在接收、分析或传播漏洞信息中发挥作用的适当第三方分享信息，除了或代替供应商或开源维护者之外。这些可能包括向公众披露，或向CERT、CISA和美国境内外其他负责漏洞信息接收和传播的机构的有限披露。 5. 公开披露时间表 我们不承诺严格的发布时间表。公开披露可能在以下情况下进行： - 获得明确的供应商许可。 - 有可信的主动利用证据。 - 通知或尝试通知供应商或开源维护者可能徒劳无益，包括因为接收者可能无法联系或可能无响应。 - 供应商或开源维护者不太可能采取适当行动，或在收到通知后未采取适当的勤勉行动。 - 披露对于保护OpenAI、其用户、第三方或公众利益的权利、隐私、安全、保护或财产至关重要。 - 法律要求披露。 在某些情况下可能存在例外。例如，如果时间表发生变化或关于严重程度或补丁的观点存在重大差异，我们可能会进行披露以确保流程的透明度和一致性。 我们保留更改或偏离本政策及其实施程序的权利。随着AI进步使安全研究和应用安全测试日益自动化，我们预计这些将大幅变化。本政策不构成合同、授予权利或成为任何方依赖的基础。