Skip to content

Platforms & Sync

The bug bounty flow starts with connected platform accounts. From there RedPick syncs programs, optionally imports the operator's existing reports, exposes only eligible targets to the runner, and continuously watches for scope or bounty changes that should influence hunting priority.

Supported Platforms

The dashboard supports multiple account records across the main public programs:

  • HackerOne
  • Bugcrowd
  • Intigriti
  • YesWeHack

Each connected account is stored as a BugBountyPlatform record and shown in the Platforms tab of the Bug Bounty workspace.

Account Onboarding Flow

  1. Connect a platform account in the dashboard.
  2. The backend stores the account and marks whether program sync and report sync are supported for that provider.
  3. The frontend usually triggers an immediate program sync after a successful connection.
  4. Programs become visible in the Programs and Intelligence tabs as soon as sync data is available.

Program Sync

Program sync is exposed in two ways:

  • per-platform sync: POST /api/v1/bugbounty/platforms/{platform_id}/sync
  • sync all connected accounts: POST /api/v1/bugbounty/sync-all

The sync pipeline updates:

  • program metadata
  • scope items and eligibility flags
  • bounty tables and max/min payout hints
  • policy URL and descriptive metadata
  • status changes such as active, paused, or closed

Report Import

RedPick can also import the operator's own existing submissions from supported providers:

  • POST /api/v1/bugbounty/platforms/{platform_id}/sync-reports

Imported reports are normalized into the local submission model so they appear in:

  • submissions history
  • pipeline view
  • earnings and stats
  • learning loop inputs

Status normalization maps provider-specific states into the local states used by the dashboard, including draft, submitted, triaged, accepted, resolved, duplicate, informative, and not_applicable.

Eligible Target Gating

The runner can expose a Bug Bounty Only launch mode. In that mode it does not let the operator choose arbitrary targets.

Instead, it reads:

  • GET /api/v1/bugbounty/eligible-targets

This endpoint collects every unique in-scope asset from synced active programs, normalizes the asset into a launchable URL, and returns only targets that belong to the authenticated user's programs.

This is the enforcement layer that keeps bughunter users constrained to synced program scope when launching a test from the runner UI.

Change Detection

RedPick treats program changes as first-class hunting signals.

Scope and bounty timeline

The raw change stream is exposed through:

  • GET /api/v1/bugbounty/scope-changes

The change model includes:

  • asset_added
  • asset_removed
  • bounty_increased
  • bounty_decreased
  • bounty_multiplier
  • bounty_per_severity_changed
  • policy_changed
  • status_changed

Active program changes for hunting

The perpetual loop and operators usually consume a grouped view instead:

  • GET /api/v1/bugbounty/program-changes?since_hours=168

For each program, RedPick computes:

  • total_priority_boost
  • grouped recent changes
  • a recommendation such as HUNT_NOW, MONITOR, DEPRIORITIZE, or SKIP

Typical examples:

  • bounty multipliers and large scope additions push a program to HUNT_NOW
  • paused or closed status can force SKIP
  • negative movement can reduce priority without removing the program completely

Once the loop or an operator has acted on those changes, the system can clear the signal with:

  • POST /api/v1/bugbounty/programs/{program_id}/changes/mark-acted

Monitor Workflow

The /bb-monitor skill wraps the change-monitoring flow:

  1. Sync all connected platforms.
  2. Pull the recent change summaries.
  3. Highlight the highest ROI changes, especially bounty multipliers and new scope.
  4. Optionally keep watching on an interval.

This is the main bridge between passive platform observation and active target selection.

What Sync Enables Downstream

Everything else in the bug bounty system depends on accurate sync data:

  • one-click engagement setup needs current scope and policy URL
  • intelligence ranking needs scope, payouts, and program freshness
  • eligible-target gating needs scope eligibility
  • change monitoring needs previous and current program state
  • report import and submission tracking need the local program IDs

If sync is stale, the rest of the stack gets progressively less reliable. That is why the dashboard auto-syncs old accounts and why both /bb-session and the perpetual loop refresh platform state before making new selection decisions.