Bug bounty finding intake and triage
the internal workflow record that runs alongside your external platform

Every report passes a check against the open findings already recorded on the same asset for the same finding template. A SQL injection against /api/v1/orders that two researchers report a day apart should resolve to one finding with two case references, not two separate records that confuse routing, retest, and disclosure.

The intake runs the asset reference and the finding template against the open catalogue before opening a new record. A match prompts a named decision: merge the new submission into the existing record with the new platform case identifier captured on an override row, or accept the submission as a distinct finding because the proof of concept demonstrates a materially different path.

Reports against issues the programme already remediated reach the intake routinely. A reproduction against a fix the engineering team shipped six months ago is a regression; a reproduction against a fix that never landed is a closure error. Both need a different intake path than a fresh finding.

The intake checks closed-and-fixed findings on the same asset and template. A reproduction against a closed finding promotes to the reopen workflow on the original finding rather than opening a new record. The reopen carries the new platform case identifier, the reproducer evidence, and the fix-reversion or fix-incomplete rationale.

A report that lands against a finding the programme already accepted as risk, suppressed for a documented reason, or deferred under an override decision is not a new finding. The exception register holds the named decision, the expiry, and the compensating control; the intake reads against that register before opening a new record.

The intake checks the override register for matches. A report against an active exception logs as a re-validation against the existing override with the new platform case identifier; the named decider gets prompted to review the override against the new evidence rather than the queue opening a parallel record that contradicts the exception.

External research often surfaces the same issue an authenticated scan, a code scan, or a CSPM check has already flagged. The scanner finding is on the queue with its own owner and SLA; the bug bounty report should not produce a parallel record that disagrees with the scanner record on severity, owner, or SLA.

The intake checks the open scanner findings on the affected asset for the same template. A match resolves into the scanner finding with the new platform case identifier captured on an override row and the source attribution updated to record that an external researcher independently surfaced the issue. The audit reads as one finding with two sources, not two findings with conflicting state.

The triager marks the report as triaged-and-accepted on the external platform and assumes the engineering owner will follow the platform thread. Two weeks later the platform shows the case still open, no internal finding exists, and the SLA clock has been running unrecorded since acceptance. The fix is opening a finding on the engagement at the moment the external platform marks the case as triaged-and-accepted so the internal queue is the canonical source of truth on remediation status.

The external platform records severity for payout purposes against its own rubric. The intake copies that severity into the finding and the workspace routing reads the wrong tier, the wrong owner, and the wrong SLA. The fix is recording the external severity as the source severity and applying the workspace CVSS 3.1 calibration with the temporal and environmental adjustments the deployed configuration justifies, so the routing reads against the calibrated severity and not the platform-payout severity.

Two researchers report the same SQL injection a day apart. The intake opens two findings with different owners, different SLAs, and different severity calibrations. Three months later the engineering team is on the hook for two records that resolve to the same fix. The fix is running the dedup check against the open catalogue, the closed catalogue, the override register, and the scanner catalogue before opening a new record, and capturing the merge decision on the existing finding rather than a parallel one.

Private programme reports with strict confidentiality clauses land on the engagement and become visible to everyone on the workspace. A researcher PII reference, a vulnerability that has not been disclosed, or a private-programme handling constraint gets exposed to roles that did not need access. The fix is RBAC scoping on the engagement record so only the named handlers see the privileged material, with the TLP-style handling note recorded on the document management artefact so the constraint travels with the report.

Engineering ships the fix, the researcher confirms remediation on the external platform, and the platform case closes. The internal finding stays in_progress because nobody walked the retest evidence back into the workspace. The audit reads the finding as overdue when it is actually resolved. The fix is the retest workflow pairing the verification artefact (request and response, regression test, screenshot) to the original finding on the engagement and moving the finding state to resolved or verified on the same record the platform case closed against.

The researcher requests public disclosure after the agreed embargo and the team has no record of the embargo terms, the named disclosure decider, or the prepared public communication. The disclosure lands without a coordinated response. The fix is recording the disclosure handling terms on the finding at intake (immediate, embargo with named end date, coordinated delay with named justification), the named disclosure decider, and the document management upload of the prepared public communication so the team is ready to coordinate when the embargo lapses.

The audit asks how the programme processed bug bounty submissions over the past quarter. The team excavates Slack threads, the platform export, and a spreadsheet to produce a narrative. The reconstruction is incomplete and slow. The fix is the activity log capturing every intake, dedup decision, severity calibration, owner assignment, retest event, disclosure decision, and exception linkage with timestamp and actor; the CSV export is the evidence pack the assessor reviews, not a narrative the analyst writes from memory.

The platform identifier (HackerOne case URL, Bugcrowd submission reference, Intigriti report ID, Synack tasking reference, in-house programme reference), the platform-recorded severity, the researcher handle, the platform-recorded triage timestamp, and the document management upload of the original report body. The external identity stays attached to the internal finding so the audit chronology is continuous from platform case to internal record.

The CVSS 3.1 base vector the workspace severity policy calibrated, the temporal and environmental adjustments the deployed configuration justifies, the resulting severity tier (Critical, High, Medium, Low), and the source severity from the external platform preserved alongside. The calibration is reproducible at audit because both severities are recorded on the same finding rather than the source severity being overwritten.

The affected asset reference (verified domain, repository, mobile bundle identifier, API endpoint, infrastructure resource), the affected component and version, the criticality tier from the asset criticality scoring layer, the routing rule the SLA tier inherits, and the named owner of record on the affected asset. Unowned assets promote to the unowned-asset queue rather than disappearing into the analyst inbox.

The dedup check result against the open catalogue, the closed catalogue, the override register, and the scanner catalogue. The named decision (new finding, merged into open, reopened against closed, re-validation against override, linked to scanner finding, closed as out-of-scope), the rationale, and the cross-reference to the existing record where one applies. The dedup decision is a named field so the audit reads against a queryable taxonomy.

The disclosure handling terms recorded at intake (immediate public disclosure, embargoed disclosure with named end date, coordinated delay with named justification, no public disclosure), the named disclosure decider, the document management upload of the prepared public communication where the programme prepares one in advance, and a non-executable reference to the payout decision on the external platform. SecPortal does not broker the payout; the workspace records the decision context so the internal chronology stays coherent.

The access scope that applies to the engagement (broad workspace access, restricted to bug bounty handlers, restricted to a named subset for private-programme constraints), the TLP-style handling note where the originating constraint demands one, and the PII handling rule for researcher attribution where anonymity protections apply. Confidential material is isolated by access scoping rather than relying on social discipline.

The VDP management workflow runs the public commitment to receive and triage security reports without a payout. The bug bounty workflow runs the operational record for reports that arrive through a paid platform or programme. Both run on the same engagement surface and share dedup, severity calibration, routing, and retest discipline; the bug bounty workflow adds the platform case identity, the dedup against the scanner catalogue, and the disclosure embargo handling the payout layer often imposes.

The internal disclosure intake workflow runs the record for employee, contractor, customer-success, internal red team, and anonymous-channel reports. The bug bounty workflow runs the record for external researcher reports that the bounty platform brokered. The internal intake page acknowledges bug bounty triage handoff as one of its upstream sources; this page is the upstream discipline that produces that handoff.

The general vulnerability finding intake workflow runs the record for scanner output, third-party scan imports, and structured machine-generated findings. The bug bounty workflow runs the record for human researcher submissions where the source is a paid external programme, the calibration steps differ, and the dedup discipline reads against the scanner catalogue rather than only against the open finding catalogue.

The third-party pentest report intake workflow runs the record for time-boxed engagements that arrive with a structured methodology and a single deliverable. The bug bounty workflow runs a continuous intake against ongoing researcher activity where each report is its own structured record, the disclosure timing varies per report, and the dedup discipline runs against a continuously moving catalogue rather than against a single batch.