Outbound coordinated vulnerability disclosure policy

# Outbound coordinated disclosure policy Source: [https://openai.com/policies/outbound-coordinated-disclosure-policy/](https://openai.com/policies/outbound-coordinated-disclosure-policy/) OpenAIOpenAI is committed to enhancing global software security by responsibly disclosing vulnerabilities discovered in third\-party software\. This policy governs how OpenAI reports and discloses vulnerabilities we discover in third\-party software to vendors and open source maintainers\. In these reports we aim to be cooperative, impactful, and maintain high integrity standards\. This policy lays out how we disclose issues found in open\-source and commercial software through automated and manual code review, as well as discoveries arising from internal usage of third\-party software and systems\. Detection methods may include: - AI\- or agent\-powered application security analysis\. - Security research, audits, and fuzzing of open\-source software\. - Evaluations of vendor\-supplied or third\-party software used within OpenAI operations\. - Other methods as appropriate\. **Ecosystem security:**A primary goal is to improve ecosystem security\. **Cooperative:**Good faith, helpful engagements\. Third party inbound disclosure processes are respected, subject to exceptions in this policy\. **Discreet by default:**Initial disclosures are private\. Public disclosures usually occur only after explicit vendor or open source maintainer consent, subject to exceptions set out below\. **High scale, low friction:**Validated, actionable disclosures are sent\. **Attribution when relevant:**Vulnerabilities will be credited as discovered by OpenAI Security Research \- Aardvark\. Where applicable, we may attribute discovery to specific individuals, systems, or agents\. 1. Identification and Validation Upon discovery, each finding is validated for security impact\. Reports typically include:- Impact summary \(e\.g\., denial‑of‑service, memory corruption\) - Affected versions / commit ranges - Reproduction steps or a proof‑of‑concept \(PoC\) where possible - Reproduction aids \(e\.g\., Docker image\) where feasible 2. Peer Review Each disclosure undergoes an internal review process prior to release, including peer review by a security engineer for accuracy, reproducibility, and quality\.- Where a vulnerability is discovered by an automated system, a security engineer reviews the disclosure before it is released\. - Where a vulnerability is discovered by a security engineer, a second security engineer reviews the disclosure\. 3. A security program manager coordinates disclosures, maintains records, and manages vendor interactions\. 4. Disclosure Process- **Reporting Channel\.**We will generally seek to follow the inbound disclosure procedures of the vendor or open source maintainer who is to receive the disclosure\. We reserve the right to follow an alternate procedure at our discretion\. Our preferred methods for disclosure include vendor security emails \(e\.g\. the company’s Product Security Incident Response Team email intake\), or private GitHub reporting\. Submissions to public trackers such as GitHub Issues are avoided by default\. We generally will not participate in Bug Bounty programs\. - **Internal Handling\.**OpenAI’s outbound disclosure communications are managed through a mailing list dedicated for this purpose\. Access to this mailing list will be internally restricted in the interest of confidentiality and discretion\. Internally, a member of our disclosure team will examine our own use of the affected product or code\. If use is found, we engage appropriate teams in accordance with our policies\. - **External Disclosures\.**In certain circumstances, in the absence of consent from the vendor or open source maintainer, OpenAI may share information with appropriate third parties that play a role in receiving, analyzing or disseminating vulnerability information in addition to, or instead of, the vendor or open source maintainer\. These may include disclosures to the public, or to a more limited set including to CERTs, CISA and other bodies within and outside the United States with responsibilities for ingestion and dissemination of vulnerability information\. 5. Public Disclosure Timeline We do not commit to strict publication timelines\. Public disclosures may occur in the following circumstances, where:- Explicit vendor permission is obtained\. - There is credible evidence of active exploitation\. - Notifying or attempting to notify the vendor or open source maintainer may be futile, including because the recipient may not be reachable or may not be responsive\. - The vendor or open source maintainer is unlikely to take appropriate action or has not acted with appropriate diligence after receiving notice\. - Disclosure is essential for protecting the rights, privacy, safety, security or property of OpenAI, its users, third parties, or the public interest\. - Disclosure is required by law\. There may be exceptions in certain cases\. For example, if timelines shift or there is a material difference in views around severity or patching, we may proceed with disclosure to ensure transparency and consistency in our process\. We reserve the right to change or deviate from this policy and our procedures implementing it\. We anticipate that these will change substantially as security research and application security testing become increasingly automated with advances in AI\. This policy does not create a contract, confer rights, or form the basis for reliance by any party\.