Skip to content

Submission & Evidence

Finding something interesting is only the middle of the bug bounty workflow. RedPick adds multiple layers between a raw disk finding and a pushed platform submission so that report quality stays high and false positives stay low.

Submission Sources

A submission can originate from:

  • a disk-based finding written during hunting
  • an existing imported platform report
  • a draft created from the dashboard or /bb-submit

The local submission model stores both the report text and the platform-specific delivery state.

Disk Findings

RedPick can scan the bug bounty program directories directly and expose all FINDING-*.md files through:

  • GET /api/v1/bugbounty/disk-findings

For each finding, the dashboard can display:

  • parsed sections from the markdown
  • linked evidence files
  • screenshots
  • video artifacts
  • readiness assessment
  • source path on disk

This makes the disk workspace a first-class input to the submission pipeline rather than an opaque side artifact.

Finding Lifecycle

The intended lifecycle is:

  1. hunt produces a candidate with evidence
  2. the candidate is screened or retried if ambiguous
  3. a proper FINDING-NNN.md is kept only for reportable candidates
  4. submission formatting creates a draft record
  5. readiness and dedup determine whether it can be pushed
  6. pushed submissions are tracked and later polled for status changes

False Positive Controls

Bug bounty reporting has two hard pressures:

  • avoid wasting platform time with noise
  • avoid damaging the operator's reputation with weak reports

RedPick addresses this with layered controls.

Hunt-side FP gate

During bug bounty hunting, Codex can act as a strict FP gate before a candidate is promoted from raw evidence into a durable finding. Ambiguous cases can be kicked back for behavioral retesting rather than flowing forward automatically.

Submission-side FP gate

/bb-submit applies a second bug bounty specific FP gate before push. The allowed outcomes are intentionally conservative:

  • proceed
  • keep as draft
  • require retest
  • block as likely false positive

Claude final authority

Even with aggressive Codex use, Claude remains the final live authority for exploit reality and ambiguous behavioral validation.

Report Formatting

/bb-submit turns a finding into a platform-friendly report by:

  1. parsing the canonical sections from markdown
  2. identifying the target program and provider
  3. formatting the report with provider-specific conventions
  4. optionally polishing the tone for human triage

The pipeline is designed around fast reviewer comprehension:

  • concise description
  • deterministic steps
  • concrete PoC
  • explicit impact
  • optional remediation

Video Evidence

Many bug bounty programs now expect a compact proof that is easy to replay. RedPick can generate a video artifact for a disk finding through:

  • POST /api/v1/bugbounty/findings/{platform}/{program_handle}/{finding_id}/generate-video

The video service supports:

  • terminal replay generated from real curl commands found in the markdown
  • optional browser segment when the issue is browser-driven or victim-visible

Generated artifacts are served through:

  • GET /api/v1/bugbounty/artifacts/{platform}/{program_handle}/videos/{filename}

Submission Readiness

Before a draft is considered ready, RedPick applies deterministic checks to the markdown:

  • is there a real technical description
  • are steps to reproduce deterministic enough
  • is the PoC validated by concrete evidence
  • is impact concrete rather than speculative
  • is the affected asset explicit
  • if video is required, is video evidence present
  • if browser evidence is required, does the video include a browser segment

These checks produce both blockers and warnings, which are surfaced in the dashboard and reused when handling disk findings or draft submissions.

Duplicate Pre-Check

RedPick runs a local duplicate heuristic before push:

  • POST /api/v1/bugbounty/dedup-check

The dedup service normalizes:

  • titles
  • vulnerability types
  • endpoints and paths
  • dynamic identifiers such as numeric IDs and UUIDs

It then scores the candidate as:

  • low
  • medium
  • high
  • certain

Auto-push is blocked or downgraded when the duplicate signal is strong.

Drafts, Push, and Tracking

Core submission routes:

  • POST /api/v1/bugbounty/submissions
  • GET /api/v1/bugbounty/submissions
  • PATCH /api/v1/bugbounty/submissions/{submission_id}
  • POST /api/v1/bugbounty/submissions/{submission_id}/push
  • GET /api/v1/bugbounty/submissions/{submission_id}/detail
  • POST /api/v1/bugbounty/submissions/poll-all

The dashboard then provides two complementary views:

  • Submissions: the list view for records and details
  • Pipeline: a Kanban-style view grouped by status

Status Polling and Retest

After a report is pushed, RedPick can poll the platform for updated state and normalize the result back into the local submission model. Resolved reports can also be retested through the dedicated retest route, allowing the operator to revisit a prior report as the target changes.

Practical Outcome

The submission pipeline is designed so that bug bounty hunting does not end when a payload works. The real end state is a triage-friendly, non-duplicate, evidence-backed report that can survive platform review and feed the next selection cycle with trustworthy outcome data.