Pencheff
Docs ↗Sign inOpen an account

Integrations and operations · Company

Our partners

Implementation specialists, channel partners, and managed security workflows.

Operational pages connect Pencheff to the rest of the security program: notifications, ticketing, SIEM, schedules, observability, API access, support, onboarding, and deployment operations.

Start freeSign in
Task routerdocumented
8coverage areas
5operator steps
4evidence fields
Coverage8
Execution5
Evidence4
Controls4
DocsAPIReportsSupport

Operational paths point to setup, references, and the right next task for the workflow.

ScopeOur Practice
SectionCompany
MethodDeterministic-first
OutputUnified evidence
ProfileIntegrations and operations
01

Coverage

What does Our partners test?

  • Implementation specialists, channel partners, and managed security workflows.
  • This page is part of Company under Our Practice.
  • It links back into the broader the practice behind the platform experience.
  • Slack, Teams, Google Chat, Discord, PagerDuty, Opsgenie, Splunk HEC, signed webhooks, GitHub Issues, and Jira.
  • Schedules for recurring scans, release gates, retests, continuous monitoring, and drift checks.
  • OpenTelemetry spans, logs, metrics, trace waterfalls, audit hash chain, SLO, and cost dashboards.
  • API keys, REST references, MCP tool access, webhooks, and CI/CD automation.
  • Workspace onboarding, support, trust, pricing, self-hosting, partnerships, and enterprise deployment workflows.
02

Execution

How does Pencheff run this?

  • Connect a target, workspace, integration endpoint, or automation credential.
  • Choose event routing by target, severity, status, schedule, or release workflow.
  • Deliver findings to chat, ticketing, paging, SIEM, GitHub, webhooks, or dashboards.
  • Use traces, audit logs, SLOs, and cost views to operate scans with confidence.
  • Review support, pricing, or deployment requirements when scaling the program.
03

Evidence

What evidence does this produce?

  • Integration delivery status, target mapping, event payload, severity filters, and test results.
  • Trace spans for HTTP requests, subprocesses, LLM calls, scan phases, and errors.
  • Audit log records with actor, action, IP, user agent, and hash-chain verification.
  • API and MCP references for automation, CI/CD, and internal platform workflows.
04

Controls

How is this kept safe to run?

  • Credentials are stored as integration configuration and used only for the selected destination.
  • Signed webhooks and target-specific routing reduce noisy or unauthenticated delivery.
  • Observability is opt-in and can be disabled globally by environment policy.
  • Support and pricing pages route users to the right commercial or operational next step.
01

From the Pencheff docs

Partner pentest triage (HackerOne / Bugcrowd / Cobalt)

Pencheff integrates with HackerOne, Bugcrowd, and Cobalt as partner pentest platforms — every finding_new event can be auto-submitted as a draft report on the upstream platform, and the triager's verdict flows back through a callback that flips Pencheff's verification_status.

The integration sidesteps the multi-year build-out of a researcher network: instead of operating one ourselves, we route findings to the platform whose researcher community already triages your engagements.

What it does

StageDirectionSurface
Submit for triagePencheff → partnerClick Verify with humans → on a finding card; the finding is forwarded as a finding_new event through the configured integration.
Triager verdictPartner → PencheffThe partner's webhook calls back into POST /findings/{id}/verify-callback with one of: confirmed / informative / duplicate / not-applicable.
State flipPencheff sideconfirmed → verification_status = true_positive. informative → false_positive. duplicate / not-applicable → suppressed with reason.

Configure an integration

PlatformConfig fields
HackerOneapi_username, api_token
Bugcrowdapi_token, program_uuid
Cobaltapi_token, pentest_id

Add via Settings → Integrations → Add integration. Each platform has a one-click "test" round-trip:

  • HackerOne — GET /v1/me
  • Bugcrowd — GET /me (Crowdcontrol API v4)
  • Cobalt — GET /orgs (Cobalt API v3, X-Api-Key auth)

The test verifies the credentials before any real submission, so a bad token doesn't show up only when a real finding routes.

Per-finding triage button

Every finding card on /scans/{id}/findings/{fid} exposes a Verify with humans → button under the action row (next to Re-examine, Mark fixed, Confirm). Clicking it shows three buttons — one per configured partner kind — and the chosen platform gets the finding as a draft report.

Webhook signing

The Phase 1.2 HMAC primitive (pencheff_api.services.integration_dispatch.sign_webhook_body) is used for the generic webhook integration's outbound signature. Partner integrations rely on the partner's own signed-callback mechanism (HackerOne hash signature header, Bugcrowd JWT, Cobalt shared secret).

For inbound verify-callback requests, validate the partner's signature in front of the endpoint — Pencheff doesn't perform that step itself today (next iteration; tracked under Phase 4 follow-up).

Source