[Codex Security] Add first-class responsible-disclosure and bug-bounty submission/tracking

Summary

Codex Security is missing the final, operationally critical stage of the security lifecycle: responsible disclosure.

Codex can increasingly help a researcher discover, validate, reproduce, write up, deduplicate, and track security findings. The current Codex Security tracking workflow can route validated findings into project-management or source-control destinations such as GitHub issues/security advisories and other trackers. But when the finding is a vulnerability in OpenAI itself—or another vendor with a coordinated disclosure / bounty program—the researcher still has to leave Codex, manually reconstruct the report in a separate system, re-establish program scope, move evidence, submit it, and then manually maintain the linkage between the Codex finding and the disclosure case.

That is a major missing architectural layer.

For OpenAI specifically, the gap is especially conspicuous because OpenAI's coordinated vulnerability disclosure policy asks researchers to report vulnerabilities, bugs, safety/abuse issues, and security flaws; the Security Bug Bounty uses Bugcrowd for submission/reward management; and the Safety Bug Bounty is a separate program that may reroute reports with the Security team depending on scope.

Codex Security should therefore support first-class disclosure providers and a tracked submission lifecycle, rather than ending at an internal tracking ticket.

Related existing issues

This proposal is part of the same broader reporting/intake architecture discussed in:

• #32225 — identifies a private security/engineering feedback-intake failure for sensitive Codex incidents and asks for selective evidence submission, stable case IDs, and confirmation that reports reach the correct team.
• #37583 — proposes an OpenAI-native, trackable issue/reporting system instead of fragmented /feedback, support, GitHub, Community/Discord, etc.
• #37585 — proposes recognizing substantial verified bug-reporting work because producing high-quality reports consumes real user time and paid Codex capacity.

Those issues cover important pieces of the same system. This issue focuses on the missing security-disclosure branch: once Codex Security has a validated finding, it should be able to carry that finding through authorized responsible disclosure and track the resulting case.

Current failure mode

The present workflow is effectively:

find
  -> validate
  -> reproduce
  -> write up
  -> classify
  -> package evidence
  -> track internally
  -> STOP

The human researcher must then manually perform:

find the right disclosure program
  -> re-check scope
  -> authenticate to the external program
  -> copy/reformat the report
  -> re-attach evidence
  -> submit
  -> capture report ID
  -> monitor triage
  -> respond to information requests
  -> track duplicate/accepted/rejected/payout state

This is precisely where a security workflow should become more structured, not less.

Proposed architecture

Add a first-class Responsible Disclosure stage to Codex Security:

finding
  -> validated
  -> disclosure_candidate
  -> program_fit
  -> evidence_sealed
  -> submission_previewed
  -> user_approved
  -> submitted
  -> tracking_id
  -> triaged
  -> accepted | duplicate | rejected | needs_information
  -> fixed / disclosed / payout / resolved

The system should distinguish at least three destination classes:

1. Internal tracking

   • GitHub issue
   • GitHub security advisory
   • other internal trackers

2. OpenAI responsible disclosure

   • OpenAI Security Bug Bounty (currently Bugcrowd-backed)
   • OpenAI Safety Bug Bounty
   • appropriate OpenAI security incident / coordinated-disclosure route when a bounty program is not the correct destination

3. Third-party responsible disclosure

   • provider interface for Bugcrowd / HackerOne / vendor-native portals / security.txt or documented vendor intake
   • bounded by the target's published policy and the researcher's authorization

The external platform can remain third-party infrastructure. The Codex Security workflow should still own the provider integration, evidence model, approval gate, submission receipt, and lifecycle state.

Why this belongs in Codex Security, not as a random connector

This should not require the researcher to discover and install a generic “Bugcrowd plugin.” Responsible disclosure is a core consequence of successful security work.

Codex Security already has the context needed to do this safely:

• canonical finding identity and fingerprint
• validation state
• source revision / affected paths
• reproduction evidence
• severity/impact analysis
• duplicate checks
• sensitive-data boundaries
• exact payload preview and approval patterns
• immutable evidence / provenance

A disclosure provider is therefore the natural next stage of the security workflow.

Required provider contract

A responsible-disclosure provider should expose a typed interface roughly equivalent to:

list_programs()
get_program_scope(program_id)
check_eligibility(finding, program_scope)
search_duplicates(finding)
prepare_submission(finding, evidence_manifest)
preview_submission(payload)
submit(payload, explicit_user_approval)
read_submission(tracking_id)
add_information(tracking_id, payload, explicit_user_approval)
get_status(tracking_id)
record_disposition(tracking_id)

The provider contract should return stable, typed states rather than free-form success claims.

Program-fit gate

Before submission, Codex Security should classify the finding and explain the routing decision:

SECURITY_BOUNTY
SAFETY_BOUNTY
SECURITY_INCIDENT
VENDOR_CVD
PRODUCT_BUG_NOT_BOUNTY
OUT_OF_SCOPE
NEEDS_HUMAN_ROUTING

It should never manufacture bounty eligibility. The preview should state:

• observed impact
• inferred impact (separate)
• program scope match
• scope uncertainties
• duplicate status
• required evidence still missing
• likely non-qualifying conditions

This would improve report quality and reduce spam for bounty teams.

Evidence sealing and privacy

Before external submission, Codex Security should create an evidence manifest that explicitly separates:

• public-safe summary
• private evidence selected for the program
• source-code excerpts
• screenshots / traces
• request / conversation IDs
• account-specific metadata
• secrets that are excluded

Every attachment should have:

• SHA-256
• MIME/type
• provenance
• redaction state
• explicit inclusion/exclusion decision

No credential, cookie, API token, private key, unrelated user data, or secret-bearing command should be included by default.

Approval and submission semantics

External disclosure is consequential and should require an exact preview before the write.

The user should see:

• exact program / destination
• authenticated account identity
• title
• full report body
• severity/impact claim
• every attachment
• redactions
• disclosure visibility
• duplicate decision
• program-scope rationale

Then one explicit approval should authorize that exact payload.

After submission, Codex Security must read the case back and return a receipt such as:

Provider: OpenAI Security Bug Bounty / Bugcrowd
Report ID: ...
Submitted: ... UTC
Status: New / Triaged / Needs info / Accepted / Duplicate / Rejected
Evidence manifest SHA-256: ...

ChatGPT/Codex should never say “reported to OpenAI” unless a real report object exists and has been read back.

Triage and payout tracking

The workflow should continue after submission.

A finding should remain open until one terminal state exists:

ACCEPTED_FIXED
ACCEPTED_PAYOUT
DUPLICATE_WITH_CANONICAL_ID
REJECTED_WITH_REASON
OUT_OF_SCOPE_WITH_EVIDENCE
WITHDRAWN_BY_REPORTER

documented or added to backlog should not be treated as disclosure completion.

The system should support:

• status polling / refresh
• triage questions
• bounded follow-up evidence
• duplicate linkage
• severity changes
• remediation confirmation
• payout / recognition disposition where the provider exposes it

Integration with OpenAI's own reporting architecture

This proposal complements #37583 rather than replacing it.

A unified OpenAI reporting layer could route ordinary product bugs to a first-party issue/case system while routing validated security/safety findings into the appropriate bounty/CVD program. From the user's perspective, the workflow should answer:

What did I find, where should it go, what exactly will be submitted, what is its ID/status, and what happens next?

The user should not need to understand the internal boundary among /feedback, GitHub, support, Bugcrowd, Safety Bug Bounty, and security incident intake before the product can help them route a valid report correctly.

Suggested Codex Security additions

A possible skill/tool split:

finding-discovery
validation
vulnerability-writeup
responsible-disclosure   <-- new
track-findings           <-- internal/project tracking remains separate
fix-finding

responsible-disclosure would own:

• current policy/scope retrieval
• program selection
• duplicate discovery
• evidence manifest + redaction
• exact preview
• approval-gated submission
• readback
• triage lifecycle

track-findings would continue to own internal Jira/Linear/GitHub-style project tracking rather than being overloaded with external disclosure semantics.

Acceptance criteria

• Codex Security has an explicit responsible-disclosure workflow separate from internal issue tracking.
• OpenAI Security Bug Bounty and OpenAI Safety Bug Bounty are supported as first-class destinations or through a unified first-party OpenAI disclosure API.
• If Bugcrowd remains the backend for the Security Bug Bounty, the researcher can authenticate/link that account without manually reconstructing the report outside Codex.
• The workflow retrieves current scope before submission.
• It checks for duplicates where the provider permits it.
• It distinguishes observed facts from inferred root cause/impact.
• It creates a redacted, hashed evidence manifest.
• It shows the exact payload and requires explicit approval before external submission.
• It returns a stable report/tracking ID and verifies it through readback.
• It tracks needs-info / accepted / duplicate / rejected / payout / resolved states.
• It never falsely claims a submission occurred.
• It supports third-party coordinated disclosure through a provider interface without bypassing published authorization/scope policies.
• Sensitive evidence can remain private while a public product issue contains only a safe architectural summary.

Non-goals

• Automatically submitting every scanner finding.
• Encouraging bounty spam.
• Bypassing Bugcrowd/HackerOne/vendor authentication.
• Testing outside authorized program scope.
• Publishing sensitive findings to GitHub.
• Treating every product defect as a bounty-eligible vulnerability.

Expected outcome

A successful Codex Security investigation should end with one of two clear outcomes:

not disclosure-eligible -> tracked internally with evidence

or

disclosure-eligible -> submitted through the correct authorized program -> stable tracking ID -> triage lifecycle

The current architecture is unusually strong at helping researchers find problems and unusually weak at helping them complete the responsible-disclosure process. Closing that gap would reduce researcher friction, improve report quality, reduce duplicate/low-signal submissions, and make Codex Security a complete security-engineering workflow rather than a pipeline that stops immediately before disclosure.

The issue names no implementation files, tests, or entry points. Start by locating the existing Codex Security finding and internal tracking workflow, then map where a separate responsible-disclosure lifecycle and provider contract would fit; done means the acceptance criteria are covered without bypassing authorization or approval gates.