[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

1. 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

1. 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.

"""
Codex Security - Responsible Disclosure and Bug-Bounty Submission/Tracking Integration
"""
from dataclasses import dataclass, field
from enum import Enum
from typing import Dict, List, Optional, Any
import hashlib
import json
import logging

logger = logging.getLogger("codex.security.disclosure")

class DisclosurePlatform(Enum):
    BUGBCROWD = "bugcrowd"
    HACKERONE = "hackerone"
    OPENAI_SECURITY = "openai_security"
    CUSTOM = "custom"

class ReportState(Enum):
    DRAFT = "draft"
    SCOPE_VERIFIED = "scope_verified"
    SUBMITTED = "submitted"
    TRIAGED = "triaged"
    NEEDS_INFO = "needs_info"
    RESOLVED = "resolved"
    DUPLICATE = "duplicate"
    REJECTED = "rejected"

@dataclass
class DisclosureConfig:
    platform: DisclosurePlatform
    program_handle: str
    api_endpoint: str
    auth_token_ref: str
    enforce_strict_scope: bool = True

@dataclass
class SecurityFindingReport:
    finding_id: str
    title: str
    severity: str
    description: str
    reproduction_steps: List[str]
    evidence_hashes: List[str]
    scope_target: str
    state: ReportState = ReportState.DRAFT
    external_report_id: Optional[str] = None
    metadata: Dict[str, Any] = field(default_factory=dict)

class DisclosureManager:
    def __init__(self, config: DisclosureConfig):
        self.config = config

    def verify_scope(self, finding: SecurityFindingReport) -> bool:
        """Verify that the target asset/scope is authorized under the active disclosure program."""
        logger.info(f"Verifying target {finding.scope_target} against program {self.config.program_handle}")
        # In production, query the platform's active scope list API
        if not finding.scope_target:
            return False
        finding.state = ReportState.SCOPE_VERIFIED
        return True

    def submit_report(self, finding: SecurityFindingReport) -> Dict[str, Any]:
        """Submit the validated and packaged finding securely to the disclosure platform."""
        if self.config.enforce_strict_scope and finding.state != ReportState.SCOPE_VERIFIED:
            if not self.verify_scope(finding):
                raise ValueError(f"Scope verification failed for target: {finding.scope_target}")

        payload = {
            "title": finding.title,
            "severity": finding.severity,
            "description": finding.description,
            "steps": finding.reproduction_steps,
            "evidence": finding.evidence_hashes,
            "program": self.config.program_handle
        }
        
        # Secure transmission mock
        logger.info(f"Transmitting finding {finding.finding_id} to {self.config.platform.value} API at {self.config.api_endpoint}")
        
        # Simulate successful submission response
        external_id = f"ext-rep-{hashlib.sha256(finding.finding_id.encode()).hexdigest()[:10]}"
        finding.external_report_id = external_id
        finding.state = ReportState.SUBMITTED
        
        return {
            "status": "success",
            "external_report_id": external_id,
            "platform": self.config.platform.value,
            "tracked_state": finding.state.value
        }

    def sync_status(self, finding: SecurityFindingReport) -> ReportState:
        """Poll or webhook sync for report triage status updates."""
        if not finding.external_report_id:
            return finding.state
        logger.info(f"Syncing status for external report {finding.external_report_id}")
        # Mock status check response
        return finding.state