Bug Bounty Intake

Bug Bounty Intake turns the reports your program receives into verified findings. Every report that arrives on a connected channel is classified, filed as an issue in your workspace, reproduced against your live environment by the retest agent, and answered — with an optional patch for confirmed findings.

Three channels feed one pipeline:

Channel	How reports arrive	What Pensar sends back
Email	A Pensar-provisioned intake address you publish, or forward an existing alias into	An email reply to the reporter
HackerOne	Reports your HackerOne team has marked Triaged	A comment on the HackerOne report
Bugcrowd	Submissions your Bugcrowd team has marked Triaged	A public comment on the Bugcrowd submission

Bug Bounty Intake is enabled per workspace by Pensar. If Bug Bounty does not appear in your workspace sidebar, contact team@pensar.dev to turn it on. Once enabled, workspace admins and owners connect channels and manage settings; every member can view the ledger.

How It Works

Receive

A report arrives by email or through a platform webhook. Platform reports are only ingested once the platform’s own triage team has marked them Triaged — reports in the New state are ignored until then.

Classify

A model reads the report against your program scope and workspace inventory and decides whether it is a genuine vulnerability report or noise. For a report it extracts a title, summary, severity, reproduction steps, affected targets, and CWE mapping. Noise (marketing, scanner blasts, “pay me first” templates, reports about assets you don’t own) is recorded and dropped — no issue is filed and no reply is sent.

File

A report becomes a normal workspace issue in the In review status, with the reporter’s reproduction steps and targets in the description and an Intake section naming the reporter, channel, and classifier reasoning. It appears everywhere issues do — the Issues list, integrations, webhooks, and the API.

Verify

Pensar matches the reported targets to your attack surface (an endpoint whose path appears in a reported URL, or the application that owns the reported host) and dispatches the retest agent to reproduce the issue against the live target. If the reported target matches nothing in your inventory, the report settles as Needs review for manual follow-up.

Settle

The verdict lands on the submission: Confirmed (reproduced), Not reproducible, or Needs review (the run errored or could not reach a conclusion). A finding that could not be reproduced is closed as Resolved by the retest agent; a confirmed finding stays In review for your team.

Reply and remediate

With Reply to reporters on, the verdict goes back to the reporter on the channel the report arrived on. With Coordinate a patch on, a confirmed finding also dispatches the patching agent against your connected repository.

Pensar never changes a report’s state, priority, or reward on HackerOne or Bugcrowd — those affect bounty eligibility, so they stay your call. Verdicts are always posted as comments.

Connecting Channels

Open Bug Bounty in your workspace sidebar. Connect at least one channel; you can connect all three.

Email

HackerOne

Bugcrowd

Pensar provisions a dedicated receiving address for your workspace.

On the Email intake card, click Provision address
Copy the Intake address and either publish it as your program’s contact address, or forward an alias you already publish (for example security@acme.com) into it
If you forward, enter that alias under Forwarding alias and click Save

The forwarding alias tells Pensar to look past your forwarder and reply to the original reporter. Forwarded reports are still answered at the reporter’s address, not yours.

Only the configured forwarding alias activates forwarded-header recovery. Addresses mentioned in the body of a report can never redirect a reply.

Use Sync inbox to pick up any messages that arrived while intake was paused or before the address was connected.

Program Settings

Once at least one channel is connected, the switches at the top of the page apply to every channel:

Setting	Description
Accept reports	Pause to stop ingesting on every channel without disconnecting anything. Reports that arrive while paused are picked up by Sync when you resume.
Reply to reporters	Send the triage verdict back once a report settles — by email, or as a comment on the platform report. On by default; no reply is sent while it is off.
Coordinate a patch	Dispatch the patching agent as soon as a report is confirmed reproducible. Off by default. Requires a connected repository; without one, the verdict and reply still go out and the row shows No patch.
Program scope	Free text handed to the classifier verbatim to decide what is in scope, for example `In scope: *.acme.com, the iOS app. Out of scope: third-party SaaS, DoS, self-XSS.`

A specific Program scope is the single biggest lever on classification quality. Name your in-scope assets and your standard exclusions the same way your public program page does.

Replies to Reporters

Replies are templated from facts the pipeline already knows, not written by a model, so a reporter can never be told something the pipeline did not establish. Every reply quotes the issue reference (for example VULN-000042) so the reporter can cite it in follow-ups.

Verdict	What the reporter is told
Confirmed	The issue was reproduced and accepted as a valid finding; the team will follow up when a fix ships. If a patch was dispatched, the reply says remediation is already underway.
Not reproducible	The issue could not be reproduced and the report is being closed for now, with an invitation to reply with the exact request, account or role, and observed response.
Needs review	An automatic conclusion was not possible and a member of the security team is reviewing manually.

Noise is never answered. Email replies are sent from the intake address; platform replies are posted as comments on the original report or submission.

Reading the Bug Bounty Page

Processed Reports

Every report received on a connected channel and what came of it. The Source badge links to the original report on HackerOne or Bugcrowd.

Result	Meaning
Queued	Received and waiting to be classified
Classifying	The classifier is reading the report
Noise	Classified as not a vulnerability report — no issue, no reply
Closed upstream	HackerOne or Bugcrowd dispositioned the report themselves (duplicate, informative, spam, not applicable)
Verifying	Filed as an issue; the retest agent is reproducing it
Confirmed	Reproduced against the live target
Not reproducible	The retest agent could not reproduce it; the issue was closed as resolved
Needs review	Settled without a verdict — the target was not in inventory, or the verification run errored
Deferred	Held by the per-channel rate limit; admitted automatically when the window rolls forward
Failed	A pipeline step exhausted its retries — see below

The Reply column shows Queued, Sending, Sent, Failed, or Unknown (the send was attempted but delivery could not be confirmed).

Triage Pipeline

Reports that became issues, with the verification verdict, its confidence, and remediation state — Patching, a link to the Pull request, a fix count, or No patch. Click View issue to open the finding.

Rate Limits

To bound model and sandbox spend during a flood, each workspace admits up to 20 email reports and 100 platform reports per channel per rolling hour. Reports beyond that are not dropped: they show as Deferred and are admitted automatically once the window rolls forward.

Troubleshooting

A report shows Failed

A pipeline step (classification, filing, or reply) exhausted its retries. Open the row to read the recorded error, then click Retry triage. Retrying is safe — a redelivered step can never file a duplicate issue or send a second reply.

A reply shows Failed or Unknown

Failed means the send was rejected; fix the cause (for example an expired platform token) and click Retry reply. Unknown means the send was attempted but never confirmed. Check the reporter’s email thread or the platform report first — if the reply is not there, click Confirm not delivered and retry. Pensar never resends an Unknown reply on its own, to avoid double-posting.

Reports settle as Needs review without a verification run

The reported target did not match any application or endpoint in your attack surface, so there was nothing to reproduce against. Add the domain and let recon map it, or check that the reporter’s URL is actually one of your assets. The issue is still filed for manual review.

Platform reports are not arriving

Confirm the report is in the Triaged state — New reports are ignored by design
Check the webhook in HackerOne or Bugcrowd is pointed at the URL shown on the card and subscribed to the listed events
For HackerOne, confirm the signing secret in the webhook matches the one Pensar generated; Rotate secret and re-enter it if unsure
For Bugcrowd, confirm the API credential has no IP allowlist and that the user who created it can access the program
Use Sync on the channel card to backfill anything the webhook missed

Connection failed

The API token or credential could not read the program. Confirm it was created by a user with access to that program, that the program handle or code matches the URL exactly, and — for Bugcrowd — that you pasted identifier:secret rather than the full Authorization header.

Disconnecting

Click Disconnect on a channel card to remove its credentials and stop intake on that channel. Reports already processed stay in the ledger and their issues remain in the workspace. To pause everything without disconnecting, turn off Accept reports.

Need Help?

If you encounter issues setting up Bug Bounty Intake, please contact our support team at team@pensar.dev.