# Account Setup: Configure Your Hackrate Organization
Source: https://hackrate-bb-app.mintlify.app/companies/account-setup
Set up your company account on Hackrate — create your organization, configure settings, invite team members, and control who can access each program.
Your Hackrate account is the foundation for everything your security team does on the platform. This guide covers creating and configuring your organization, inviting teammates, understanding permission roles, and managing your account preferences. Taking time to set this up correctly ensures the right people can act on reports quickly and that no access is inadvertently over- or under-provisioned.
## Creating your organization
When you register as a company on Hackrate, your first task is to create an **Organization**. An organization is the top-level container for all of your programs, team members, and settings.
To create an organization, go to **Organizations** in the main navigation and click **New Organization**. You will need to provide:
| Field | Description |
| --------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Your company's full display name, shown to researchers on program pages |
| **Alias** | A short, URL-safe identifier (for example, `acme`). This appears in your program URLs and cannot be changed later, so choose carefully. |
If your company runs multiple distinct products or business units with separate security budgets, consider creating one organization per unit. This makes it easier to manage team permissions and report access independently.
## Inviting team members
Security programs work best when the right colleagues have access. Hackrate uses a role-based permission system that lets you control exactly what each person can see and do.
### Roles and permissions
Full control over the program and organization. SuperAdmins can publish programs, pause programs, manage bounty tables, invite and remove administrators, and configure integrations. This role should be reserved for security leads or program owners.
Can update program details, manage the scope, publish announcements, send notifications to researchers, and triage reports. StandardAdmins cannot pause or publish programs. This is the right role for day-to-day security team members who operate the program.
Can view program details and reports but cannot make changes. Suitable for stakeholders such as legal, compliance, or executive team members who need visibility without operational access.
Access to the program analytics dashboard, including report counts, bounty spend, and budget utilization. Useful for security managers who need reporting data without access to individual vulnerability details.
### How to invite a teammate
Open the program you want to grant access to and click **Permissions** (or **Administrators**) in the program management menu.
Type the colleague's work email address and select the appropriate role from the dropdown.
Click **Add User**. If the colleague already has a Hackrate account, they receive an email notification and gain access immediately. If they do not yet have an account, they receive an invitation email prompting them to register — their role will be applied automatically once they complete registration.
Pending invitations are visible in the **Permissions** panel under the program. You can monitor whether a colleague has accepted, declined, or not yet responded to their invitation.
### Admin groups
For organizations with multiple programs, managing permissions program-by-program can become time-consuming. **Admin Groups** let you bundle a set of users and assign the group a role across one or more programs in a single step. Create and manage admin groups from the **Organization** settings page.
## Organization-level vs. program-level access
Permissions can be granted at two levels:
* **Organization level** — grants access to all current and future programs within the organization. Use this for core security team members who work across all programs.
* **Program level** — grants access to a specific program only. Use this for external consultants, product team liaisons, or temporary reviewers.
Organization-level roles are powerful — a SuperAdmin at the organization level has full access to every program in that organization. Grant this level only to colleagues who genuinely need it.
## Account and notification preferences
### Email notifications
Hackrate sends email notifications for key activity on your programs. From your **Account Settings** page you can toggle each category on or off and choose your preferred content level:
**Notification categories:**
* **New reports** — notified when a researcher submits a new vulnerability report
* **Report updates** — notified when a report's status or severity changes
* **Comments** — notified when someone posts a comment on a report
* **Internal comments** — notified for internal notes visible only to your team
* **Files** — notified when a file attachment is added to a report
* **Program updates** — notified about changes to program settings or announcements
* **Marketing updates** — product news and platform announcements from Hackrate
* **News and communication** — general Hackrate community news
**Content level** controls how much detail is included in each notification email:
* **Minimal** — brief summary only
* **Typical** *(default)* — standard detail level suitable for most users
* **Full** — complete report content and context included in the email
### Security.txt integration
If your organization publishes a `security.txt` file (as recommended by [RFC 9116](https://www.rfc-editor.org/info/rfc9116)), you can reference your Hackrate VDP form URL in it. The platform provides a ready-to-use snippet from the program's embed settings. This makes it easy for researchers who discover your assets independently to find the right reporting channel.
### Two-factor authentication
Hackrate strongly recommends enabling two-factor authentication (2FA) on your account, especially if you hold a SuperAdmin role. You can enable 2FA from your account security settings.
## Business units
If your organization is structured into distinct business units — for example, separate product teams with their own security responsibilities — Hackrate supports **Business Units** as an optional organizational layer. Business units allow you to associate specific targets with a particular team and restrict visibility of reports and scope to the appropriate group. Contact the Hackrate team to enable this feature for your organization.
# Connect Hackrate to GitHub for Issue and Advisory Tracking
Source: https://hackrate-bb-app.mintlify.app/companies/integrations/github
Install the Hackrate GitHub App on your repositories and create issues or security advisories directly from reports without leaving the platform.
The GitHub integration bridges your Hackrate program and your engineering workflow. Once connected, you can turn any triaged report into a GitHub issue — with a title, description, labels, and a link back to the Hackrate report — with one click from the report management page. For vulnerability disclosures that require coordinated remediation, you can also draft a GitHub Security Advisory directly from a report. The integration keeps the two systems in sync by tracking the last-known state of every issue it creates.
## How the Integration Works
Hackrate connects to GitHub through a GitHub App installed on your organization's or user's GitHub account. The App grants Hackrate the ability to read your repository list and create issues or advisories on your behalf. The connection is stored per-program, so if you run multiple programs, each one can be linked to the same GitHub App installation.
All authentication uses GitHub's official OAuth and App flows — Hackrate never stores your GitHub credentials.
## Installing the GitHub App
Navigate to your program in Hackrate and open **Settings**. You need a SuperAdmin or StandardAdmin role on the program to connect integrations.
In the **Integrations** section, find the GitHub card and click **Connect GitHub**. Hackrate will redirect you to GitHub to authorize the App installation.
On the GitHub authorization page, choose whether to install the App on all repositories or only on selected ones. Hackrate recommends selecting only the repositories where you track security work — this follows the principle of least privilege.
GitHub redirects you back to Hackrate automatically. The system records your installation and syncs the list of repositories you granted access to. You land back on the program settings page with the GitHub integration shown as **Connected**.
If you have already installed the Hackrate GitHub App for another program in the same organization, the new program will share the same installation. You do not need to go through the GitHub authorization flow again — simply connect the program in its settings and select from the already-synced repository list.
## Creating a GitHub Issue from a Report
Once the integration is connected, a **Create GitHub Issue** action appears in the report management view for every report in your program.
Navigate to **Reports → Manage** and open the report you want to track in GitHub.
Find the GitHub Issues section in the report management sidebar or action panel and click **Create Issue**.
A form appears with the following fields:
* **Repository** — select from the repositories synced from your GitHub App installation
* **Title** — defaults to the report title; edit as needed
* **Body** — the issue description; you can include a summary of the vulnerability and a reference to the Hackrate report ID
* **Labels** — optionally add labels such as `security`, `bug`, or a severity label
Click **Create**. Hackrate calls the GitHub API, creates the issue, and stores a link record containing the repository name, issue number, direct issue URL, and current issue state. This link is displayed on the report page so anyone managing the report can jump to GitHub in one click.
Use GitHub labels that match your team's severity taxonomy (e.g., `sev:critical`, `sev:high`) so the issue appears correctly in your engineering board filters as soon as it is created.
## Creating a GitHub Security Advisory
For vulnerabilities that require a CVE or a coordinated public disclosure, Hackrate can create a **GitHub Security Advisory** (GHSA) directly from the report management page, in addition to a regular issue.
Find the report you want to disclose and open its management view.
In the GitHub integration section, choose **Create Security Advisory** instead of **Create Issue**. Complete the advisory form, including the ecosystem and affected package details required by GitHub.
Hackrate creates a draft advisory in your chosen repository's **Security** tab. Your engineering team can refine the advisory, request a CVE, and publish it when the vulnerability is fully resolved.
## Synced Data
Hackrate tracks the following fields for every issue it creates:
| Field | Description |
| ---------------- | ------------------------------------------------------------------------------------- |
| Repository | Full name of the repository (e.g., `acme-corp/security-tracker`) |
| Issue number | The GitHub issue number |
| Issue URL | Direct link to the issue on GitHub |
| Last known state | The state of the issue the last time Hackrate synced with GitHub (`open` or `closed`) |
The state is updated automatically via GitHub webhooks whenever the issue is opened, closed, or reopened.
## Troubleshooting
This can happen if the OAuth callback did not complete successfully. Try reconnecting from program settings. If the problem persists, check whether any browser extensions or firewalls blocked the GitHub redirect back to Hackrate.
Hackrate only shows repositories that were explicitly granted access during the App installation. Go to your GitHub App installation settings (GitHub → Settings → Applications → Installed GitHub Apps) and ensure the Hackrate App has access to the repositories you expect. Then return to Hackrate program settings and click **Sync Repositories** to refresh the list.
If the Hackrate GitHub App is removed from your GitHub account, the integration will stop working. New issues cannot be created and webhook syncs will fail. To restore the integration, go to program settings and click **Connect GitHub** to go through the installation flow again. Previously created issue links remain stored in Hackrate but will no longer receive state updates.
Only SuperAdmins and StandardAdmins can create GitHub issues and advisories from reports. Read-Only and Analytics users will not see these actions in the report management view.
# Create Jira Tickets from Hackrate Reports Automatically
Source: https://hackrate-bb-app.mintlify.app/companies/integrations/jira
Connect your Jira project to a Hackrate program so your triage team can file tickets directly from the report management view without switching tools.
Security teams often work alongside engineering teams that live in Jira. The Hackrate–Jira integration removes the manual step of copying vulnerability details from Hackrate into a Jira ticket. Once configured, a **Create Jira Ticket** action becomes available on every report management page in your program. Your triagers can file a ticket without leaving Hackrate, keeping both systems up to date and reducing the risk of information getting lost in translation.
## How It Works
The Jira integration is configured at the program level. You supply your Jira instance URL and the target project details, and Hackrate stores those alongside your program. When an admin clicks to create a ticket, Hackrate uses those stored settings to open a pre-filled ticket in the correct Jira project.
The Jira integration is configured by an admin in program settings. Only one Jira project can be connected to a program at a time. If you need to route tickets to different projects depending on the type of finding, consider using multiple programs or routing rules in Jira itself.
## Configuring the Jira Integration
Go to your program in Hackrate and open **Settings**. You need a SuperAdmin or StandardAdmin role on the program to configure integrations.
In the **Integrations** tab, find the Jira card.
Provide the base URL of your Jira instance. For Jira Cloud this looks like `https://your-company.atlassian.net`. For Jira Server or Data Center, use the URL your team navigates to when opening Jira.
Supply the numeric ID of the Jira project where security tickets should be created. You can find this in your Jira project settings.
Provide the Issue Type ID for the kind of ticket you want to create — for example, the ID for "Bug" or "Security Vulnerability" in your project's issue type scheme.
Click **Save**. The Jira integration is now active for this program. The Jira details will appear in the report management sidebar for every report in the program.
## Creating a Jira Ticket from a Report
Go to **Reports → Manage** and open any report within the program that has Jira configured.
In the report management view, a Jira panel shows your configured base URL, project, and issue type. This confirms the integration is active.
Click **Create Jira Ticket**. Hackrate pre-fills the ticket with the report title, a description derived from the report content, the severity level, and a link back to the Hackrate report. Review and adjust the content if needed, then submit.
The ticket appears in your Jira project board. Your engineering team can pick it up from their normal Jira workflow. The Hackrate report retains a reference to the Jira ticket for traceability.
## What Data Is Sent to Jira
When you create a ticket from a report, the following information is included:
The vulnerability title from Hackrate becomes the Jira ticket summary.
The Hackrate severity level (Critical, High, Medium, Low) is included in the ticket body to help engineers prioritize.
The report's description, impact statement, and reproduction steps are included so engineers have the full context without needing Hackrate access.
A direct link back to the Hackrate report is embedded in the ticket so reviewers can navigate between systems easily.
## Tips for Getting the Most Out of the Integration
In Jira Cloud, go to your project, open **Project Settings → Details**, and look for the Project ID in the URL or the settings fields. In Jira Server, the Project ID is shown in **Project Settings → Edit Project**.
In Jira Cloud, go to **Project Settings → Issue Types**, click the issue type you want to use, and note the numeric ID in the URL. In Jira Server, you can find issue type IDs under **Jira Administration → Issues → Issue Types**.
If your engineering workflow requires Critical and High findings in one project and Medium and Low in another, you can configure two separate Hackrate programs with different Jira settings, or handle routing automatically with Jira Automation rules that re-assign issues based on labels or custom fields you populate.
The Jira integration stores your Jira base URL and project details in program settings. Only SuperAdmins and StandardAdmins can modify this configuration. If your Jira instance URL changes — for example, after a migration to Jira Cloud — remember to update the base URL in every program that uses the integration.
# Slack, Microsoft Teams, and Zapier Notification Setup
Source: https://hackrate-bb-app.mintlify.app/companies/integrations/slack
Route Hackrate report alerts to Slack channels, Microsoft Teams, or Zapier workflows so your team is notified the moment a new report arrives.
Staying on top of incoming vulnerability reports means being notified where your team already works. Hackrate supports real-time notification delivery to Slack and Microsoft Teams channels, so new reports and status changes appear in your existing communication tools without anyone having to log in and check the dashboard. For teams with more complex routing needs, the Zapier integration lets you build custom automation workflows that connect Hackrate to virtually any other tool.
## Slack Notifications
The Slack integration sends messages to a Slack channel of your choosing whenever a new report is submitted to your program or a report's status changes.
### Setting Up Slack
In your Slack workspace, go to **Apps → Incoming WebHooks** (or open Slack's App Directory and search for "Incoming WebHooks"). Click **Add to Slack**, choose the channel where Hackrate notifications should appear, and click **Add Incoming WebHooks Integration**. Copy the webhook URL that Slack generates.
Navigate to your program in Hackrate and open **Settings**. You need a SuperAdmin role to configure integrations.
In the **Integrations** section, find the Slack card and paste the webhook URL you copied from Slack. Click **Save**.
Submit a test report or update a report status. Within seconds, you should see a notification appear in the Slack channel you configured.
### What Triggers a Slack Notification
| Event | Description |
| --------------------- | ----------------------------------------------------------------- |
| New report submitted | A new vulnerability report lands in the program |
| Report status changed | A triager changes a report to Accepted, Resolved, Duplicate, etc. |
| Comment added | A new comment (internal or external) is posted on a report |
Point Slack notifications at a dedicated `#security-reports` channel rather than a general engineering channel. This keeps the signal clean and makes it easy to set up Slack notification preferences or integrations (like PagerDuty) on that channel independently.
## Microsoft Teams Notifications
The Microsoft Teams integration works the same way as Slack — Hackrate sends a message to a Teams channel via an incoming webhook whenever a new report arrives or a report's status changes.
### Setting Up Microsoft Teams
In your Teams workspace, navigate to the channel where you want notifications to appear. Click the **⋯ (More options)** menu next to the channel name and select **Connectors**. Find **Incoming Webhook**, click **Configure**, give it a name (e.g., "Hackrate Alerts"), and click **Create**. Copy the webhook URL that Teams provides.
Navigate to your program and open **Settings → Integrations**.
Find the Microsoft Teams card and paste the webhook URL. Click **Save**.
Trigger a report event — for example, change a report status — and confirm the notification appears in your Teams channel.
Each Hackrate program holds one Slack webhook and one Teams webhook independently. If you run multiple programs and want notifications for all of them in the same channel, configure the same webhook URL in each program's settings.
## Zapier Integration for Advanced Automation
If Slack and Teams don't cover your workflow, the Zapier integration gives you a webhook endpoint that Hackrate calls for every report event. You can use this as the trigger for any Zapier automation — routing reports to a ticketing system, populating a spreadsheet, sending a formatted email, triggering an on-call alert, or anything else Zapier supports.
### Setting Up Zapier
Log in to [zapier.com](https://zapier.com) and create a new Zap. For the trigger, choose **Webhooks by Zapier → Catch Hook**. Zapier will generate a unique webhook URL for this Zap.
Copy the webhook URL that Zapier provides on the trigger configuration step.
In your Hackrate program settings, open **Integrations** and find the Zapier card. Paste the Zapier webhook URL and click **Save**.
Back in Zapier, trigger a test event from Hackrate (by updating a report), then map the incoming data fields to your target app's action. Activate the Zap when you're satisfied.
If you want more control over how notifications look in Microsoft Teams than the default webhook message provides, you can use Zapier as a middleware:
1. Set up the Hackrate Zapier integration as described above.
2. Add a **Formatter** step in Zapier to reshape the incoming data.
3. Add a **Microsoft Teams** action step to send a card-formatted message with exactly the fields you care about.
This pattern also works for routing different severity levels to different Teams channels — add a **Filter** step between the trigger and the Teams action.
Webhook URLs — whether for Slack, Teams, or Zapier — grant the ability to post to your channel or trigger your automation without authentication. Treat them as secrets. Do not share them publicly, commit them to source control, or include them in logs.
# Webhooks, Email Alerts, and the Embedded Report Form
Source: https://hackrate-bb-app.mintlify.app/companies/integrations/webhooks
Configure email notification preferences, set up Zapier webhooks, and embed the Hackrate report form on your own website for VDP programs.
Hackrate offers several ways to push information out of the platform and into your team's workflow: per-user email notifications that each person can tune to their own preferences, Zapier webhooks for custom automation pipelines, and — for Vulnerability Disclosure Programs (VDP) — an embeddable report form that lets researchers submit reports without ever visiting the Hackrate website. This page explains all three and how to configure each one.
## Email Notifications
Every Hackrate user can configure their own email notification preferences. Notifications are sent from the platform to your registered email address and can be enabled or disabled per event type.
### Notification Event Types
Receive an email when a new vulnerability report is submitted to a program you administer. Useful for ensuring nothing is missed even when you're not actively logged in.
Get notified when the status of a report changes — for example, when a report you submitted or are managing moves to Accepted, Resolved, or Duplicate.
Receive an email when a new public comment is posted on a report you're involved with.
Receive an email when a new internal (team-only) comment is posted on a report. Only visible to admins with triage access.
Get notified when a new file or evidence attachment is added to a report.
Platform announcements, new feature releases, and other communications from the Hackrate team.
### Email Content Level
In addition to toggling individual event types, you can control how much detail each notification email contains:
| Level | What you receive |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Minimal** | A brief subject line and a link to the item in Hackrate — no vulnerability details in the email body. Best for security-conscious environments where email may be archived or forwarded. |
| **Typical** | A short summary with the report title, severity, and status — enough context to prioritize without the full report content. |
| **Full** | The complete report content, including title, description, summary, impact, and any comments included in the notification trigger. Convenient for quick triage from your inbox. |
If your organization has a policy against including sensitive information in email, set all users to **Minimal** content level. This ensures vulnerability details stay inside Hackrate and are only accessible to authenticated users with the correct role.
### Configuring Your Email Preferences
Navigate to your **Profile Settings → Notification Preferences** to enable or disable each event type and to select your preferred content level. Each user manages their own preferences independently — there is no org-wide default override.
## Zapier Webhook Integration
For teams that need to route Hackrate events into custom automation pipelines, the Zapier integration provides a webhook trigger that fires on report events. You can connect this to hundreds of downstream apps — from project management tools and ticketing systems to communication platforms and custom APIs.
In [Zapier](https://zapier.com), create a new Zap and choose **Webhooks by Zapier → Catch Hook** as the trigger. Zapier provides a unique webhook URL for this Zap.
In Hackrate, go to your program's **Settings → Integrations** and find the Zapier section. Paste the webhook URL and save.
Update a report status or add a comment in Hackrate. Zapier will receive the payload, allowing you to inspect the data fields and map them to your automation's next steps.
Add action steps in Zapier — for example, create a Jira ticket, send a formatted Slack message, update a Google Sheet row, or trigger a PagerDuty alert. Activate the Zap when ready.
Each program can have one Zapier webhook URL configured. If you need to fan out events to multiple systems, use Zapier's **Multi-Step Zaps** or a tool like Make (formerly Integromat) with a single inbound webhook that dispatches to multiple actions.
## Embedded Report Form for VDP Programs
If your program is a Vulnerability Disclosure Program (VDP), you can embed the Hackrate report submission form directly on your own company website — for example, on a `security.yourcompany.com` page or in your security policy. This allows researchers to submit reports without needing to navigate to Hackrate directly, making it easier for non-technical reporters and reducing friction in the disclosure process.
### How the Embedded Form Works
When a program is marked as **embeddable**, Hackrate serves a standalone report form that you can include in your website via an `
```
Adjust the `height` value to suit your page layout.
Submit a test report through the embedded form on your website and confirm it appears in your Hackrate inbox. Check that your notification settings fire correctly for embedded submissions.
Reports submitted through the embedded form are flagged as embedded submissions in Hackrate. This distinction is visible on the report management page and in CSV exports (the "VDP" column), letting your triage team know the report came in through the public disclosure form rather than through a registered hacker account.
If the submitter provides an email address and that address matches an existing Hackrate account, the report is linked to that account automatically. Otherwise, the submission is stored with the contact information the reporter provided.
Link your embedded form directly from your `security.txt` file and your website's footer. Researchers actively looking for a place to report vulnerabilities will check both of these locations first.
# Hackrate for Companies: Ethical Hacking Platform Guide
Source: https://hackrate-bb-app.mintlify.app/companies/introduction
Learn how Hackrate helps organizations find vulnerabilities before attackers do, using a global community of ethical hackers and four security services.
Hackrate is an ethical hacking platform that connects your organization with a global community of vetted security researchers. Instead of waiting for malicious actors to discover weaknesses in your systems, Hackrate lets you take a proactive stance: you define what should be tested, researchers find real-world vulnerabilities, and your team receives structured, actionable reports — all within a controlled and transparent environment. Whether you are running a continuous bug bounty program or a time-boxed penetration test, Hackrate centralizes every finding, conversation, and reward in one place.
## What Hackrate offers organizations
Hackrate provides four distinct service types that can be used independently or in combination, depending on your security maturity and compliance requirements.
Crowdsource continuous security testing by rewarding ethical hackers for valid vulnerability reports. Define your scope, set bounty payouts by severity and asset tier, and receive a steady stream of validated findings as your product evolves.
Commission time-boxed, structured penetration tests conducted by verified researchers. Get deep, methodology-driven assessments with real-time visibility into findings — suitable for compliance audits and pre-release reviews.
Give security researchers a safe, structured way to report vulnerabilities without offering monetary rewards. Hackrate manages the intake, validation, and communication so you minimize the risk of irresponsible disclosure.
Continuously monitor your external attack surface for exposed assets and emerging risks. Identify unknown or forgotten assets before hackers do, and get a clearer picture of your organization's digital footprint.
## How the platform is structured
Everything on Hackrate is organized around a clear hierarchy. Understanding this model helps you navigate the platform and delegate the right responsibilities to your team.
**Organization → Program → Target → Report**
* **Organization** — Your company's top-level workspace on Hackrate. It holds one or more programs and allows you to manage team members, permissions, and billing in one place.
* **Program** — A security engagement with its own scope, rules, budget, and lifecycle. A program can be a bug bounty, a PTaaS engagement, or a VDP. Programs can be public (listed in the Hackrate catalog) or private (invite-only).
* **Target** — An individual asset within a program's scope, such as a web application, API, or mobile app. Each target has a type, a severity expectation, and a tier that determines its bounty payout level.
* **Report** — A vulnerability submission from a researcher. Reports are linked to a specific target, triaged by severity, and tracked through resolution.
Hackrate's managed service means that a dedicated team reviews incoming reports for validity and accuracy before they reach your inbox, reducing noise and false positives.
## Getting started quickly
Register your account, create your organization, and launch your first program in minutes.
Understand program types, lifecycle stages, and key configuration options.
Learn how to define in-scope assets, assign tiers, and manage out-of-scope items.
Configure your organization, invite team members, and set up notification preferences.
## Why organizations choose Hackrate
Automated vulnerability scanners provide a useful baseline, but they cannot replicate the creativity and business context that skilled human researchers bring. Ethical hackers discover logic flaws, chained attack paths, and business-impact vulnerabilities that no scanner will catch. Hackrate's platform gives you full transparency into who is testing, what they found, and what it would cost to remediate — without requiring you to expand your in-house security headcount.
Hackrate is also designed for compliance. Structured vulnerability reports, severity-based prioritization, and audit-ready documentation make it straightforward to demonstrate continuous security testing for ISO 27001, SOC 2, PCI DSS, HIPAA, GDPR, and NIS2 frameworks.
# Managed Bug Bounty Program: Setup and Configuration Guide
Source: https://hackrate-bb-app.mintlify.app/companies/programs/bug-bounty
Configure a Hackrate Managed Bug Bounty Program — set up bounty tables, define asset tiers, choose public or private access, and manage your budget.
A Managed Bug Bounty Program on Hackrate puts your assets in front of a global community of ethical hackers who are motivated to find real vulnerabilities. Unlike automated scanners, human researchers bring creativity, business context, and adversarial thinking that uncover logic flaws, chained attack paths, and high-impact issues that rule-based tools will never catch. Hackrate's managed service wraps the program with professional triage, researcher communication, and validated reports — so your security team can focus on fixing vulnerabilities rather than managing a crowd.
## How bug bounty works on Hackrate
The lifecycle of a managed bug bounty program follows four phases:
Work with the Hackrate team to define which assets are in scope, what types of vulnerabilities are eligible for rewards, and how much you are willing to pay for each severity level. Setting the right bounty amounts and clear boundaries is the foundation of a successful program. A well-scoped program attracts quality researchers and produces actionable findings.
Finalize the program policy: what researchers can and cannot do during testing, which vulnerability classes are in scope, how to report findings, and the expected response time from your team. Decide whether to start with a private (invite-only) program or go public immediately. Hackrate's team reviews and approves the program before it goes live.
Once the program is published, researchers begin testing. Each submission arrives in your report inbox with a structured format: title, affected target, reproduction steps, evidence, and the researcher's severity assessment. Hackrate's managed triage validates reports for accuracy before they reach your team, eliminating duplicate and low-quality submissions.
Review validated reports, collaborate with researchers through the platform's messaging thread, and track remediation progress. When a report is accepted, you approve the bounty payout. Hackrate handles the actual payment to the researcher after your authorization, and the researcher earns both the monetary reward and reputation points on the platform.
## Setting up your bounty table
The **Bounty Table** defines exactly how much a researcher earns for a valid finding, based on the severity of the vulnerability and the tier of the affected target.
### Severity levels
Hackrate uses five severity levels, aligned with industry-standard vulnerability scoring practices:
| Severity | Description |
| --------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **Exceptional** | Extraordinary findings with immediate, catastrophic business impact — included only when your program opts in to this tier |
| **Critical** | Full system compromise, remote code execution, authentication bypass, or mass data exposure |
| **High** | Significant impact on confidentiality, integrity, or availability of a major asset |
| **Medium** | Moderate impact requiring some user interaction or limited scope of effect |
| **Low** | Minor security issues with limited practical exploitability |
### Tiers: prioritizing your most important assets
Hackrate's bounty table uses a **two-tier** system that lets you pay more for vulnerabilities in your most critical assets without affecting payouts for secondary systems.
* **Tier 1** — Primary or business-critical assets, such as your main customer-facing application, core API, or payment system. Tier 1 vulnerabilities command the highest bounties.
* **Tier 2** — Secondary assets, such as staging environments, marketing sites, or less sensitive internal tools. Tier 2 payouts are lower, reflecting the reduced business risk.
When you add a target to your program, you assign it to Tier 1 or Tier 2. The bounty table then maps each severity-tier combination to a payout amount.
### Example bounty table
The table below shows a typical bounty configuration. Your actual amounts will depend on your budget, the sensitivity of your assets, and market benchmarks for your industry.
| Severity | Tier 1 | Tier 2 |
| --------------- | ------- | ------- |
| **Exceptional** | \$3,000 | \$1,500 |
| **Critical** | \$2,000 | \$1,000 |
| **High** | \$800 | \$400 |
| **Medium** | \$300 | \$150 |
| **Low** | \$100 | \$50 |
The Exceptional severity row is optional — you can choose whether to include it in your program. Bounty amounts can also be configured as **fixed values** or as **ranges** (a minimum and maximum per cell). Ranges give your team flexibility to reward exceptional report quality within a severity band. Contact the Hackrate team to configure range-based payouts.
### Currency
Each program is denominated in either **USD** or **EUR**. All bounty table values and budget tracking use the currency you select at program creation. Currency cannot be changed after the program is published.
## Managing your budget
Every bug bounty program has an associated **Budget** — the total funds allocated for bounty payments across the program's lifetime. The Hackrate analytics dashboard gives you live visibility into:
* **Bounties paid** — the sum of all approved payouts to date
* **Bonus payments** — any additional discretionary rewards granted on top of standard bounties
* **Budget consumption percentage** — how much of your total budget has been spent
* **Bounty forecast** — the estimated future spend based on open, unresolved reports
The Hackrate platform adds a service fee to each bounty payout. Budget planning should account for this when setting your total program budget. Contact the Hackrate team for current fee details.
## Public vs. private bug bounty programs
A private bug bounty program is only accessible to researchers you explicitly invite. This approach is ideal when you are:
* Running your first bug bounty program and want to start with a small, trusted cohort
* Testing a sensitive or pre-release product
* Working within regulatory constraints that require controlled access
To invite researchers, go to **Invite Hackers** in the program management menu. You can browse the Hackrate researcher community, filter by skills and reputation, and send invitations. Invitations expire after 12 days, and you can resend or revoke them at any time.
A public bug bounty program is listed in the Hackrate catalog and open to any registered, verified researcher. This maximizes your testing coverage and gives you access to the widest range of expertise. Public programs typically generate more reports but also more diversity of vulnerability types.
The Hackrate managed triage service is especially valuable for public programs, where report volume can be higher.
## Program models and maturity paths
Bug bounty programs do not have to follow a one-size-fits-all model. Hackrate supports several common approaches:
Start with a controlled, invite-only program. Once your team is comfortable triaging reports and your scope is well-defined, expand to a public program for broader coverage.
An always-on program with no fixed end date. Ideal for products that ship continuously and need ongoing security validation as each release introduces new code.
Run a bug bounty program for continuous coverage while commissioning targeted PTaaS engagements for deep-dive assessments of specific features or compliance requirements.
Begin with a narrow scope — one or two core assets — and expand the target list as your remediation capacity grows and your team's confidence increases.
## Sending notifications to researchers
You can send a direct email notification to all enrolled researchers from the **Send Notification** feature in the program management menu. This is useful for communicating scope changes, temporary testing restrictions, or program news that is more urgent than a standard announcement. A preview function lets you review the email before sending.
## Credentials for researchers
If your in-scope assets require login access, you can provide **test credentials** to researchers through the credential management system. Credentials can be scoped to the entire program or to individual targets. The platform distributes credentials automatically to researchers who join the program, ensuring each researcher gets a unique set of login details.
# Programs Overview: Security Engagements on Hackrate
Source: https://hackrate-bb-app.mintlify.app/companies/programs/overview
Understand what a Hackrate program is, how public and private programs differ, the full program lifecycle, and which program type suits your organization.
A **program** is the central unit of work on Hackrate. It defines what should be tested, by whom, under what rules, and — for bug bounty programs — what rewards are available. Every vulnerability report on the platform is associated with a program, and every program belongs to an organization. Understanding how programs work helps you configure them well and get the most out of your security testing investment.
## What a program contains
When you create a program on Hackrate, you configure a set of fields that together describe the engagement completely. Researchers use this information to understand what to test and how to report; your team uses it to triage findings and manage budget.
| Field | Purpose |
| -------------------------- | ------------------------------------------------------------------------------- |
| **Name** | The display name of the program, visible to researchers |
| **Alias** | A short, unique identifier used in URLs and notifications |
| **Description** | Background about your company and the product under test |
| **Policy** | The rules of the engagement — what researchers can and cannot do |
| **Targets** | The in-scope assets researchers are authorized to test |
| **Bounty Table** | Payout amounts organized by severity and target tier (bug bounty programs only) |
| **Budget** | The total funds allocated for bounty payments |
| **Currency** | USD or EUR |
| **Launch Date / End Date** | Optional scheduled start and end dates |
| **Visibility** | Whether the program is invite-only or open to all researchers |
| **Rewards enabled** | Whether valid reports are eligible for monetary rewards |
| **Managed** | Whether Hackrate's team provides managed triage and researcher communication |
| **Testing Period** | The allowed testing hours or windows that researchers must respect |
Markdown formatting is supported in the Description and Policy fields, allowing you to use headings, lists, code blocks, and emphasis to make your program page clear and professional.
## Public vs. private programs
One of the most important decisions when creating a program is whether it should be public or private.
Public programs appear in the Hackrate catalog and are open to any registered researcher who chooses to apply. This maximizes your testing coverage and exposes your assets to a diverse range of skill sets and approaches. Public programs are well-suited to mature products that have already been through initial hardening.
Private programs are invite-only. You select specific researchers from the Hackrate community and send them invitations. This approach gives you tighter control over who is testing and is ideal for sensitive systems, early-stage products, or situations where a smaller, focused group of researchers is preferred.
A common progression is to start with a private program to validate your scope and triage workflow with a small group of trusted researchers, then open the program publicly once you are confident in your process.
## Program lifecycle
A Hackrate program moves through a series of states from initial setup to completion. Understanding this lifecycle helps you know what actions are available at each stage and what researchers experience.
```
Draft → Published → Active → (Paused) → Ended
```
The program has been created but has not yet been reviewed and published. Only your team can see it. Use this stage to finalize your scope, write your policy, and configure your bounty table before going live.
The program has been reviewed by the Hackrate team and is now visible to researchers (if public) or to invited researchers (if private). Researchers can view the program details and apply or accept invitations.
The program is open for submissions. Researchers can submit vulnerability reports, and your team receives notifications for each new report.
The program has been temporarily suspended. No new reports can be submitted. All participating researchers receive an automatic email notification when a program is paused. Pausing is typically used when your team needs time to catch up on a backlog of reports, or when significant changes are being made to the product under test.
The program has concluded. Existing reports remain accessible for your records and compliance needs, but no new submissions are accepted. For time-boxed engagements such as PTaaS, the end date is agreed upon at the start of the engagement.
Only a SuperAdmin can publish or pause a program. Pausing sends an automatic email to all enrolled researchers, so use this action deliberately.
## Program announcements
You can post **Announcements** to a program at any time. Announcements appear prominently on the program's details page and are useful for communicating scope changes, temporary restrictions, updated rules, or recognition of the research community's contributions. Only one announcement is highlighted as "recent" at any given time; previous announcements are archived but remain visible.
To notify researchers of an announcement by email (rather than just posting it on the program page), use the separate **Send Notification** feature in the program management menu.
## Program types on Hackrate
Hackrate supports four service types. Each has its own dedicated setup guide.
Continuous, reward-based vulnerability discovery with a global researcher community.
A structured, no-bounty reporting channel that protects both your organization and researchers.
Time-boxed penetration testing with verified researchers and real-time report visibility.
How to define, tier, and manage the assets within any program type.
# Penetration Testing as a Service: PTaaS on Hackrate
Source: https://hackrate-bb-app.mintlify.app/companies/programs/ptaas
Run structured penetration tests on Hackrate with verified ethical hackers — real-time findings, compliance-ready outputs, and HackGATE™ monitoring.
Penetration Testing as a Service (PTaaS) on Hackrate gives you the depth and discipline of a structured penetration test without the operational overhead of managing an external pentest engagement from scratch. Hackrate coordinates a focused team of verified ethical hackers, manages the testing timeline, and delivers real-time visibility into findings through the platform — so your security and engineering teams can begin remediation before the final report is even written.
## What makes PTaaS different from bug bounty
Bug bounty programs are open-ended and continuous: researchers test whenever and however they choose, within your defined scope. PTaaS is structured and time-boxed: a defined team tests a defined scope during a defined window, following a systematic methodology.
| | PTaaS | Bug Bounty |
| ------------------------ | ------------------------------------------------------------ | -------------------------------------------------- |
| **Testing window** | Fixed engagement period (days or weeks) | Ongoing / continuous |
| **Researcher selection** | Curated team selected by Hackrate | Community-driven; researchers apply or are invited |
| **Methodology** | Structured, systematic | Creative, adversarial |
| **Output** | Formal engagement report + real-time findings | Individual vulnerability reports |
| **Best for** | Compliance audits, pre-launch reviews, deep-dive assessments | Continuous coverage across an evolving product |
| **Pricing model** | Project-based | Platform fee + bounties |
PTaaS and bug bounty are complementary, not competing. Many organizations run both: PTaaS for structured assessments aligned to compliance cycles, and bug bounty for continuous coverage between formal tests.
## Why PTaaS on Hackrate
### Verified researchers
Every researcher who participates in a PTaaS engagement on Hackrate has been identity-verified using KYC (Know Your Customer) services. Hackrate's Elite Club — a curated group of the highest-performing and most trustworthy researchers on the platform — is the preferred pool for PTaaS engagements. Researchers hold industry-recognized certifications including OSCP, OSCE, CISSP, and CEH.
You are not working with an anonymous crowd. You know who is testing your systems, and those individuals have agreed to strict non-disclosure and professional conduct requirements.
### Real-time visibility into findings
Unlike traditional penetration tests where you receive a report weeks after testing concludes, Hackrate's PTaaS delivers findings in real time. Every vulnerability a researcher submits appears in your dashboard immediately. Your team can begin triaging and remediating critical issues while testing is still ongoing — dramatically shortening the time between discovery and fix.
### HackGATE™ monitoring
For organizations that require the highest level of transparency and control over their security testing, Hackrate offers integration with **HackGATE™** — a managed gateway appliance purpose-built for monitoring pentest projects. HackGATE is the industry's first comprehensive solution for monitoring ethical hacker activity during a testing engagement.
With HackGATE, you gain:
* Full visibility into the network traffic generated by testers
* Assurance that researchers are staying within the agreed scope
* Detailed audit logs of testing activity for compliance and legal purposes
* The ability to pause or terminate testing activity instantly if needed
HackGATE is available as an add-on to PTaaS engagements. Contact the Hackrate team to learn more about deployment options and requirements.
### Flexibility across asset types
PTaaS on Hackrate supports a wide range of asset types:
Full black-box, grey-box, or white-box testing of web applications, including authentication, business logic, API endpoints, and client-side security.
REST, GraphQL, and SOAP API assessments — covering authentication, authorization, input validation, and data exposure.
iOS and Android app assessments including static analysis, runtime testing, local data storage, and network communication security.
Internal and external network assessments, firewall rule reviews, and infrastructure hardening checks.
## How a PTaaS engagement works
The Hackrate team works with you to define the engagement scope, testing objectives, and timeline. You specify which assets should be tested, any restrictions (for example, production vs. staging environments, off-limit functionality, testing hours), and the depth of assessment required. A clear scope document is agreed upon before testing begins.
Hackrate selects a team of 5 to 20 verified researchers with the skill sets most relevant to your target assets. For specialized engagements — for example, a mobile app with specific iOS exploitation requirements — the team is assembled accordingly. Researchers sign NDAs and are briefed on the engagement rules before access is granted.
Testing begins on the agreed start date. Researchers submit findings through the Hackrate platform as they are discovered. Each report is structured with title, severity, affected asset, reproduction steps, supporting evidence (screenshots, proof-of-concept code), and remediation guidance. Critical findings are flagged immediately for your team's attention.
You can communicate directly with the researcher who submitted a finding through the platform's messaging thread. This is especially valuable for understanding complex exploitation chains or requesting additional evidence.
Once your engineering team has addressed a finding, you can request a retest from the researcher who originally identified it. Retesting confirms that the fix is effective and that the vulnerability cannot be reintroduced through a variant of the original attack.
At the conclusion of the engagement, Hackrate produces a formal engagement report summarizing all findings by severity, including evidence, impact descriptions, and remediation guidance. This report is structured for executive, engineering, and compliance audiences.
## Compliance-ready outputs
PTaaS engagements on Hackrate are designed to satisfy the evidence requirements of major compliance frameworks. The structured findings, severity ratings, and formal report are directly usable as supporting documentation for:
Demonstrates regular penetration testing as required by Annex A controls on vulnerability management and technical compliance review.
Supports the availability, integrity, and confidentiality criteria by providing documented evidence of proactive security testing.
Satisfies Requirement 11.3 for penetration testing of the cardholder data environment and associated systems.
Supports organizational obligations around risk management, incident prevention, and data protection by design.
## Integrations for streamlined workflows
Vulnerability findings from PTaaS engagements can be pushed directly to your existing development and operations tooling:
* **Jira Cloud** — Automatically create Jira issues from Hackrate reports, keeping your engineering team's workflow in one place
* **GitHub** — Create GitHub issues or security advisories directly from reports, with status syncing when issues are closed or reopened
* **Microsoft Teams** — Receive real-time notifications in your Teams channels when new findings are submitted
* **Slack** — Get instant Slack notifications for new reports and status changes
* **Zapier** — Connect Hackrate to thousands of other tools through Zapier webhooks
Configure integrations from the **Integrations** section of your program management page.
# Targets & Scope: Defining In-Scope Assets on Hackrate
Source: https://hackrate-bb-app.mintlify.app/companies/programs/targets-scope
Define in-scope and out-of-scope targets on Hackrate, assign asset tiers, set bounty eligibility per target, and provide test credentials to researchers.
Scope definition is one of the most consequential decisions you make when running a security program. A well-defined scope attracts focused, high-quality research, protects your production systems, and sets clear expectations that prevent disputes about report validity. A vague or poorly written scope leads to off-target testing, wasted researcher effort, and confusion for your triage team. This guide explains how to configure targets on Hackrate and how each field affects the researcher and reporting experience.
## What is a target?
A **target** is an individual asset that you add to a program's scope. Each program can have multiple targets, and each target is configured independently. Researchers see the full list of active, in-scope targets when they view the program — this is how they decide where to focus their efforts.
Every target has the following properties:
| Field | Description |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Name** | A clear, recognizable label for the asset (for example, `Customer Web App`, `Payment API`) |
| **Type** | The asset category (web application, API, mobile app — iOS, mobile app — Android, network, other) |
| **Description** | Context about the asset: what it does, what kind of users access it, and any hints about its architecture or sensitivity |
| **Tier** | `1` for primary/critical assets; `2` for secondary assets. Tier directly affects bounty payouts in bug bounty programs. |
| **Bounty eligible** | Whether valid findings on this target qualify for monetary rewards |
| **Active** | Whether the target is currently visible to researchers. Inactive targets are hidden from the program's scope page. |
| **In / Out of scope** | Whether the target is something researchers are authorized to test, or an asset they must explicitly avoid |
## In scope vs. out of scope
Every program on Hackrate has both an **in-scope** list (assets researchers are authorized to test) and an **out-of-scope** list (assets they must not touch). Being explicit about both is equally important.
Assets that researchers are authorized to test. These are the targets you want tested and for which you will accept vulnerability reports. Only active, in-scope targets appear in the public-facing scope table on the program page.
Assets that researchers must not test. These are typically production databases, third-party services you do not own, infrastructure shared with other customers, or assets with legal or contractual restrictions on testing.
Out-of-scope items should be explicit, not implied. If a researcher accidentally tests an out-of-scope asset, the report will be rejected — but this creates friction and erodes trust. The more specific your out-of-scope list, the better.
Common categories to consider for out-of-scope designation:
* Third-party services and SaaS platforms you use but do not own
* Shared hosting infrastructure
* Rate-limiting and anti-brute-force mechanisms (often excluded to prevent DoS)
* Social engineering and physical security testing
* Denial-of-service (DoS/DDoS) attacks
* Automated scanning at a rate that degrades service performance
## Tier 1 vs. Tier 2 assets
The tier system allows you to pay differentiated bounty amounts based on how critical an asset is to your business. This creates the right incentives: researchers spend more time on your highest-value targets because the potential reward is higher.
Tier 1 targets are your most important assets — the ones where a vulnerability would have the greatest business impact. Examples:
* Main customer-facing web application
* Core payment processing API
* Authentication service
* Primary mobile app
Tier 1 targets receive the **highest bounty payouts** in the bounty table. Assign Tier 1 to assets where a critical vulnerability could lead to mass data exposure, financial loss, or reputational damage.
Tier 2 targets are lower-risk assets where a vulnerability is less likely to have severe business impact. Examples:
* Marketing website (no user data or transactions)
* Internal admin tool with limited external exposure
* Documentation portal
* Sandbox or developer environment
Tier 2 targets receive **lower bounty payouts** than Tier 1. This does not mean researchers ignore them — it means the risk-reward ratio accurately reflects the asset's importance.
You do not have to use both tiers. If all your in-scope assets are equally critical, you can assign everything to Tier 1. The tier system is a tool for differentiation, not a requirement.
## Best practices for scope definition
### Be specific with asset names
Avoid vague names like `All web applications` or `Backend services`. Instead, name each asset specifically:
* ✅ `app.yourcompany.com — Customer Portal (Vue.js frontend + REST API)`
* ❌ `All customer-facing apps`
Specific names help researchers understand exactly what to test and help your triage team quickly confirm which asset a report relates to.
### Write meaningful descriptions
The description field appears on the program's public scope page and is visible to researchers before they begin testing. Use it to explain:
* What the asset does and who uses it
* The technology stack (if you are comfortable sharing it)
* Any known constraints or guidance (for example, "Test accounts are available via the credential request system")
* Any historical context relevant to testing (for example, "This API was recently rewritten and is a high priority")
### Separate test environments from production
If you want researchers to test against a staging or test environment rather than production, create a separate target for each and name them clearly:
* `Main App — Staging (app-staging.yourcompany.com)`
* `Main App — Production (app.yourcompany.com)`
You can then configure the staging target as active and in-scope, and leave the production target as active but with tighter restrictions in the policy.
### Refresh your scope regularly
Your product changes over time — new features are shipped, old services are deprecated, and the attack surface evolves. Review your target list at least quarterly and:
* Deactivate targets for assets that no longer exist
* Add targets for new assets
* Upgrade Tier 2 targets to Tier 1 if their criticality has increased
* Update descriptions to reflect architectural changes
## Adding targets to a program
Targets are managed from the **Scope** section of your program management page. Contact the Hackrate team to add new targets or modify existing ones — this ensures the change is reviewed and that researchers are notified appropriately when scope expands.
Adding a significant new target to an active program is treated as a scope expansion. It is good practice to post an **Announcement** to the program when you expand scope so that researchers are aware of the new testing opportunity.
## Deactivating targets
If you need to remove an asset from scope — for example, because it has been retired or because you need to take it offline for maintenance — you can **deactivate** the target rather than deleting it. Deactivated targets are hidden from the public scope table and from researcher view, but they remain in your program's history along with any reports associated with them.
Deactivating a target does not automatically notify researchers. If the change is time-sensitive (for example, you are taking a production system offline for maintenance and need to prevent testing immediately), post an announcement or send a direct notification to enrolled researchers.
## Providing test credentials
Many web applications and APIs require authenticated access to test properly. Hackrate's **credential management** system lets you securely provision test accounts to researchers.
### How credentials work
You upload test credentials (username and password pairs) via a CSV file or the credential dashboard. The platform assigns unique credentials to each researcher who joins the program, ensuring:
* No two researchers share the same test account (preventing one researcher's actions from interfering with another's)
* Each researcher knows which account is theirs
* You can audit which researcher was using which account if an incident occurs
Credentials can be configured at two levels:
* **Program-wide** — A single set of credentials grants access to the entire program's test environment
* **Target-specific** — Different credentials for each target, where each asset has its own authentication system
### Setting a credential quantity per target
For targets where you want each researcher to receive multiple test accounts (for example, to test different user roles), you can configure how many credential sets each researcher receives per target. If this is set to zero, each researcher receives one credential set by default.
Create test accounts with realistic but clearly distinguishable names (for example, `testuser-hacker-001@yourcompany-test.com`) so that your application logs make it easy to separate genuine testing activity from real user traffic.
# Vulnerability Disclosure Policy: Managed VDP on Hackrate
Source: https://hackrate-bb-app.mintlify.app/companies/programs/vulnerability-disclosure
Set up a Managed Vulnerability Disclosure Policy on Hackrate — give researchers a safe, structured reporting channel without requiring a bounty budget.
A **Vulnerability Disclosure Policy (VDP)** is a public commitment from your organization that you welcome responsible security research and have established a safe, structured process for receiving vulnerability reports. On Hackrate, VDP is offered as a fully managed service — the platform handles researcher intake, validation, and communication, while you focus on fixing the issues your researchers find. A VDP is often the smartest first step for organizations beginning their security testing journey, and it can run alongside a bug bounty program or PTaaS engagement.
## What a VDP is — and how it differs from bug bounty
The core distinction between a VDP and a bug bounty program is straightforward: a VDP does not require monetary rewards. Researchers who report through a VDP are contributing to the security of your organization's products because they believe in responsible disclosure — not because they expect payment.
| | VDP | Bug Bounty |
| ------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------- |
| **Monetary rewards** | Not required | Yes — defined in bounty table |
| **Researcher motivation** | Responsible disclosure, recognition | Financial reward + recognition |
| **Scope** | Typically broad; can include all public-facing assets | Scoped to specific targets with tier assignments |
| **Cost model** | Fixed platform fee (from 200 EUR/month) | Platform fee + bounty payouts |
| **Best for** | Establishing a reporting channel; compliance; first step into security testing | Continuous, reward-driven vulnerability discovery |
Many organizations run both a VDP and a bug bounty program simultaneously. The VDP provides a broad, open channel for any researcher to report any finding, while the bug bounty program focuses creative effort on specific high-priority targets with monetary incentives.
## Safe harbor and responsible disclosure
A VDP signals to the security research community that your organization will not take legal action against researchers who discover and responsibly disclose vulnerabilities within the scope and rules you define. This "safe harbor" commitment is critical — without it, researchers who find genuine vulnerabilities in your systems may choose not to report them, or may disclose them publicly without giving you time to fix them.
Your program's **Policy** field (formatted in Markdown) is where you define the terms of engagement. A strong VDP policy should include:
* What researchers are authorized to test
* What they are explicitly **not** authorized to do (for example, social engineering employees, accessing customer data, or performing denial-of-service attacks)
* How researchers should submit their reports
* What your organization commits to in response: acknowledgment timeline, investigation timeline, and fix timeline
* The safe harbor statement — your commitment not to pursue legal action for good-faith research conducted within the defined scope
The Hackrate team can help you draft a clear, legally sound VDP policy. Drawing from established frameworks such as disclose.io and NTIA's coordinated vulnerability disclosure guidelines is a good starting point.
## Setting up a managed VDP on Hackrate
From your organization dashboard, create a new program and configure it as a disclosure-only program (no monetary rewards). You can still define the scope using Targets; researchers will see which assets are in scope even without a bounty attached.
Fill in the **Policy** field with your responsible disclosure terms, safe harbor language, and testing boundaries. Use the **Description** field to introduce your organization and explain why you have established the program. Both fields support Markdown formatting.
Enable the **Embeddable Report Form** option to activate a standalone report URL and an embeddable widget that you can place on your website — for example, on a security page or within your existing developer documentation. See the section on embedding below.
Once the Hackrate team has reviewed your program, publish it. Add the VDP link to your `security.txt` file, your website footer, your developer documentation, and any other place where security researchers are likely to look.
## The embeddable report form
Hackrate provides an embeddable vulnerability report form that lets researchers submit reports directly from your own website, without needing to navigate to the Hackrate platform. This removes friction for researchers and reinforces that the reporting channel is yours — not a third-party service.
When the embeddable form is enabled for a program, you get:
**Direct link** — A standalone URL you can share in your `security.txt` file, in email signatures, or on your security page. The URL follows the pattern:
```
https://www.hckrt.com/Reports/EmbeddedReportForm?program=your-alias
```
**Embed code** — A snippet you can paste directly into your website to display the form inline. The form resizes automatically within any standard page layout.
**Allowed domains** — Optionally restrict which domains are permitted to embed the form. If no domains are configured, the form can be embedded anywhere.
### Customizing the form appearance
Two fields control how the form looks to researchers:
* **Form title** — The title displayed at the top of the form. Defaults to `[Your Program Name] x Hackrate`. You can customize this to show only your company name or a specific product name.
* **Introductory text** — Optional text shown above the form fields. Use this to explain the purpose of the form, link to your full VDP policy, or set expectations about response times. Markdown formatting is supported.
### security.txt integration
The `security.txt` standard ([RFC 9116](https://www.rfc-editor.org/info/rfc9116)) is a widely recognized convention for publishing your security contact and reporting information in a machine-readable file at `/.well-known/security.txt`. Hackrate generates a ready-to-use `security.txt` snippet from your program's embed settings. The snippet includes your policy URL, preferred languages, and canonical URL — ready to drop into your web server.
Adding a `security.txt` file is one of the highest-impact, lowest-effort things you can do to improve your responsible disclosure posture. It signals organizational maturity and makes it dramatically easier for researchers who find your assets organically to report what they find.
## Anonymous and unauthenticated reporting
Researchers who submit reports through the embeddable form can choose to provide an email address for follow-up or submit anonymously. Anonymously submitted reports are still tracked and triaged by the Hackrate team. If a researcher later creates or logs into a Hackrate account with the same email address used in an embedded submission, those reports are automatically linked to their account.
## Compliance and audit benefits
A managed VDP on Hackrate contributes directly to several compliance frameworks:
* **ISO 27001** — Supports requirements around vulnerability management (Annex A.12.6) and information security incident management
* **NIS2** — Supports the coordinated vulnerability disclosure requirements introduced by the EU NIS2 Directive
* **SOC 2** — Demonstrates a proactive approach to vulnerability identification and remediation
* **GDPR** — A VDP helps ensure personal data vulnerabilities are reported promptly, supporting breach notification obligations
Your Hackrate program provides audit-ready documentation of all reports received, their status, and your team's response — valuable evidence for any compliance review.
# Quickstart: Launch Your First Security Program on Hackrate
Source: https://hackrate-bb-app.mintlify.app/companies/quickstart
Go from zero to a live security program in six steps: register, create your organization, define your scope, and start receiving vulnerability reports.
Getting your first Hackrate security program off the ground is straightforward. This guide walks you through every step, from creating your account to receiving your first vulnerability report. Most organizations complete the initial setup in under an hour; the Hackrate team is available to assist with program configuration at any point.
Go to [hckrt.com](https://www.hckrt.com) and sign up for an account. During registration, you will provide your name and email address and create a password. After verifying your email, you will be prompted to indicate that you are joining as an organization (rather than as a security researcher).
Use a shared security team email alias (for example, `security@yourcompany.com`) so that multiple colleagues can receive platform notifications without depending on a single individual's inbox.
Once you are logged in, create your Organization. An organization is your company's top-level workspace — it holds all of your programs and allows you to manage team members and permissions centrally.
You will provide:
* **Organization name** — your company's display name on the platform
* **Alias** — a short, unique identifier used in program URLs (for example, `acme`)
If you have multiple subsidiaries or product lines that need separate program configurations, you can create additional organizations later.
From your organization dashboard, create a new program. The most important decision at this stage is which service type fits your current needs.
Choose a **Managed Bug Bounty Program** if you want ongoing, continuous security testing with monetary rewards for researchers. Bug bounty works best when you already have a mature product that can tolerate creative, open-ended testing. You will configure a bounty table that sets payout amounts by severity and asset tier.
Choose a **Managed Vulnerability Disclosure Policy (mVDP)** if you want a structured, safe channel for researchers to report vulnerabilities without offering cash rewards. VDP is a lower-cost entry point and is often the right choice for organizations beginning their security testing journey. Pricing starts at 200 EUR/month.
Choose **Penetration Testing as a Service (PTaaS)** if you need a time-boxed, methodical test — for example, before a product launch, as part of an annual compliance review, or when assessing a newly acquired system. Hackrate coordinates a team of verified researchers for the engagement duration.
A common maturity path is to start with a VDP to establish a reporting channel, then layer in a bug bounty program once your team is comfortable triaging reports. PTaaS can run in parallel at any stage.
Fill in your program's **Name**, **Description** (about your company), **Policy** (program rules for researchers), and set the program's **currency** (USD or EUR). You can also choose whether the program should be **public** (visible in the Hackrate catalog) or **private** (accessible only to researchers you invite).
Scope is one of the most important parts of any security program. Add the assets you want researchers to test as **Targets**. For each target, provide:
* **Name** — a clear, recognizable label (for example, `Main Web App` or `Customer API`)
* **Type** — the asset category (web application, API, mobile app, etc.)
* **Description** — context that helps researchers understand what the asset does
* **Tier** — Tier 1 for your primary or highest-value assets; Tier 2 for secondary assets. Tier affects bounty payouts in a bug bounty program.
* **Bounty eligible** — whether valid findings on this target are eligible for a monetary reward
Also specify any **out-of-scope** items — assets that researchers must not test. Being explicit about exclusions protects your production systems and sets clear expectations.
Never leave your scope vague. Ambiguous boundaries lead to off-target testing and disputes over report validity. Be as specific as possible about what is in scope and what is not.
With your scope defined, you are ready to open the program to researchers.
* **Public programs** — click **Publish** to list the program in the Hackrate catalog. Any registered researcher can apply to participate.
* **Private programs** — use the **Invite Hackers** feature to select specific researchers from the Hackrate community. You can resend invitations at any time.
Once published, Hackrate notifies the relevant researcher community. Researchers who apply to a public program receive a confirmation email with a link back to the program.
Before publishing, the Hackrate team will review your program configuration to ensure the scope, rules, and bounty table are clear and complete. This review is part of the managed service.
When a researcher submits a vulnerability, it appears in your **Reports** inbox. Each report includes a title, description, reproduction steps, supporting evidence, and the researcher's assessment of severity.
Your team reviews each report, communicates with the researcher through the platform's messaging thread, and updates the report status. For bug bounty programs, once a report is validated you can approve the bounty payout — Hackrate handles the payment to the researcher.
Use the **Analytics** dashboard to track total reports by severity, bounties paid, budget consumption, and researcher activity over time.
## What to do next
Invite your security team, configure notification preferences, and manage organization settings.
Learn about program lifecycle stages, public vs. private programs, and key configuration fields.
Deep-dive into defining targets, assigning tiers, and managing out-of-scope assets.
Configure bounty tables, set payout ranges, and manage your program budget.
# Bounty Rewards: Payouts, Tables, and Bonus Amounts
Source: https://hackrate-bb-app.mintlify.app/companies/reports/bounty-rewards
Learn how bounty payouts are calculated from the bounty table, how to award rewards from the report view, and how to add discretionary bonus amounts.
Bounty rewards are the financial incentive at the heart of a paid bug bounty programme. Hackrate's bounty system is designed to give you precise, transparent control over how much you pay for each finding — based on the vulnerability's severity and the tier of the affected target — while still leaving room to recognise exceptional researcher effort through bonus payments. This page explains how the bounty table works, how to configure fixed or ranged payouts, and how to award a bounty (and optional bonus) from the report management view.
## How bounty amounts are determined
A bounty payout is the intersection of two dimensions: **severity** and **target tier**.
* **Severity** reflects how dangerous the vulnerability is: Critical, High, Medium, Low, or Exceptional (if your programme enables this tier).
* **Target tier** reflects the relative importance of the affected asset to your business. Tier 1 targets are your highest-value assets (core production systems, customer-facing APIs, payment infrastructure); Tier 2 targets are less critical assets (staging environments, internal tools, lower-priority subdomains).
The bounty table maps every combination of severity and tier to a specific payout amount — or a payout range if your programme uses interval-based pricing.
## The bounty table structure
Your programme's bounty table has two tiers (Tier 1 and Tier 2) and up to five severity levels:
| Severity | Tier 1 Payout | Tier 2 Payout |
| ----------- | ----------------- | ----------------- |
| Exceptional | Set per programme | Set per programme |
| Critical | Set per programme | Set per programme |
| High | Set per programme | Set per programme |
| Medium | Set per programme | Set per programme |
| Low | Set per programme | Set per programme |
The **Exceptional** severity level is optional. It is only available if your programme explicitly enables it in the bounty table configuration. Use it for vulnerabilities that significantly exceed the typical Critical threshold — for example, a fully unauthenticated remote code execution on a core production system.
### Fixed amounts vs. ranges
Your bounty table can operate in one of two modes:
Every severity/tier combination maps to a single, exact payout figure. When you award a bounty for an Accepted or Resolved report, the system shows the exact amount from the table and you confirm the award.
**Example fixed bounty table (USD):**
| Severity | Tier 1 | Tier 2 |
| ----------- | -------- | ------- |
| Exceptional | \$10,000 | \$5,000 |
| Critical | \$5,000 | \$2,500 |
| High | \$2,000 | \$1,000 |
| Medium | \$500 | \$250 |
| Low | \$100 | \$50 |
Fixed amounts provide researchers with complete certainty about what they will earn before they submit, which is a strong motivation for thorough, high-quality reports.
Each severity/tier cell defines a **minimum** and **maximum** payout. When awarding a bounty, you choose the actual amount within that range, giving you discretion to reward a particularly well-written report more generously than a minimally sufficient one.
**Example range bounty table (USD):**
| Severity | Tier 1 Range | Tier 2 Range |
| ----------- | ---------------- | --------------- |
| Exceptional | $8,000 – $15,000 | $4,000 – $7,500 |
| Critical | $3,000 – $6,000 | $1,500 – $3,000 |
| High | $1,000 – $2,500 | $500 – $1,250 |
| Medium | $200 – $600 | $100 – $300 |
| Low | $50 – $150 | $25 – $75 |
Range-based tables are common for programmes that want to reward researcher effort and report quality, not just the severity of the finding. A critical finding in an unusually hard-to-reach system, documented with exceptional clarity, might justify the top of the range even if a standard critical would land in the middle.
## Currency
Bounty amounts are denominated in the currency set at the programme level. Hackrate supports **USD (US dollars)** and **EUR (euros)**. The currency applies to all bounties and bonuses on that programme and is shown throughout the report management interface and the researcher's payout history.
Currency is set when the programme is created or configured. If you need to change the currency for an existing programme, contact your Hackrate account manager — changing currency mid-programme can cause confusion for researchers who have been operating under a different expectation.
## Awarding a bounty from the report view
You can award a bounty directly from the report management page once the report has been reviewed and you are ready to reward the researcher.
### Confirm severity and tier
Before awarding, verify that the severity on the report accurately reflects your assessment — not the researcher's original claim if you have adjusted it. The bounty amount is calculated based on the current severity on the report and the tier of the affected target.
The target's tier (Tier 1 or Tier 2) is shown in the Target card at the top of the management page.
### Open the bounty section
Scroll to the **Bounty** section in the report management view. The system shows the applicable amount (or range) from your programme's bounty table for the current severity and tier combination.
### Enter the bounty amount
If your programme uses **fixed amounts**, the amount is pre-filled. Confirm it is correct and proceed.
If your programme uses **ranges**, enter the amount you wish to award within the min–max range for the applicable severity and tier.
### Submit the bounty
Click **Award bounty** to confirm the payment. The bounty amount is recorded on the report and a payment record is generated with a unique tracking identifier. The researcher is notified that a bounty has been awarded and can see the amount in their account. Each bounty record has a shareable page that the researcher can use as proof of payment.
The bounty amount is also visible in the **Bounty** column of your CSV exports, giving you a straightforward way to reconcile programme spend.
## Adding a bonus payment
In addition to the standard bounty, you can award a **bonus** to recognise exceptional quality, unusual depth of research, or a finding that had particularly significant business impact beyond what the severity score alone captures.
The bonus is a separate amount recorded alongside the bounty. Both appear on the report:
* **Bounty** — the standard award calculated from the bounty table
* **Bonus** — the additional discretionary amount
Both the bounty and the bonus appear in CSV exports, and both are included in the researcher's payout history.
Consider awarding a bonus when:
* The researcher provided an unusually detailed write-up with clear remediation recommendations
* The report was marked **Good quality duplicate** and you want to acknowledge the effort even though the finding was already known
* The finding had a real-world impact (e.g. the vulnerability was discovered to already be exploited) that the severity score alone does not fully reflect
* The researcher was exceptionally responsive and cooperative throughout the triage process
## Budget management and forecasting
Running a sustainable bug bounty programme requires understanding your bounty spend over time. Use the **CSV export** from the report inbox with the **Bounty** and **Bonus** columns selected to produce a detailed ledger of every reward paid out, filterable by programme, date range, and severity.
For forecasting, the bounty table itself is your primary planning tool:
* Multiply your expected monthly report volume (from historical data or programme benchmarks) by severity distribution to estimate average monthly spend
* Tier 1 assets drive the majority of bounty spend; if you are adding high-value Tier 1 targets, plan your budget accordingly
* Range-based tables give you a natural upper bound: your maximum possible payout per report is the Tier 1 Exceptional maximum
Suppose your programme receives roughly 20 valid reports per month with the following severity distribution:
* 2 Critical (both Tier 1)
* 5 High (mix of Tier 1 and Tier 2)
* 8 Medium (mostly Tier 2)
* 5 Low (Tier 2)
Using the example fixed table above (USD):
| Severity | Count | Avg payout | Subtotal |
| ----------------------------- | ------ | ---------- | -------------------- |
| Critical (Tier 1) | 2 | \$5,000 | \$10,000 |
| High (Tier 1 × 2, Tier 2 × 3) | 5 | \~\$1,400 | \$7,000 |
| Medium (Tier 2) | 8 | \$250 | \$2,000 |
| Low (Tier 2) | 5 | \$50 | \$250 |
| **Total** | **20** | | **\~\$19,250/month** |
This kind of estimate gives your finance team a defensible monthly budget figure. Actual spend will vary — especially if an exceptional finding comes in — but the table makes the variance predictable.
## Frequently asked questions
Yes. You can award a bounty at any point after accepting a report — you do not have to wait until you have deployed a fix. Many programmes award bounties upon **Accepted** status to reward the researcher promptly, then move the report to **Resolved** separately when remediation is complete.
Contact your Hackrate account manager if you need to correct a bounty record. Bounty records are tracked with a unique identifier and are linked to the researcher's payout history, so corrections need to be coordinated to ensure the researcher's account reflects the right amount.
Standard **Duplicate** reports are typically not rewarded. However, if you close a report as **Good quality duplicate**, you can use the bonus field to make a discretionary payment acknowledging the researcher's quality work without implying you are paying a full bounty for a duplicate finding.
No. Awarding a bounty and changing the report status are independent actions. You can award a bounty while the report is in **Accepted** status and close it as **Resolved** later, or you can close it first and then award the bounty. The order is up to your programme's internal workflow.
# Managing Vulnerability Reports on Hackrate Platform
Source: https://hackrate-bb-app.mintlify.app/companies/reports/overview
Learn how vulnerability reports flow from researchers to your security team, how to navigate the report inbox, and how to export report data for analysis.
The Hackrate report management system is the central hub where your security team reviews, triages, and resolves every vulnerability submission that researchers send to your programs. When a researcher discovers a security issue and submits a report — whether through your program's dedicated page or an embedded submission form — it lands immediately in your inbox, ready for your team to act on. Understanding how to navigate the inbox, use the right view for each workflow, and export data when you need it will help you run a faster, more organised triage process.
## How reports reach your team
Every report goes through a defined lifecycle from the moment a researcher presses **Submit**. All submissions — whether through your program's dedicated page or an embedded form — enter with a **New** status. From there, your admin team takes ownership: reviewing the evidence, assessing severity, communicating with the researcher, and ultimately moving the report to a closed status once a decision has been made. A SuperAdmin can move a report to **New – To review** to signal that it has been routed and is awaiting formal assignment.
Reports submitted via an embedded form are flagged automatically so you can identify them at a glance in the management view. The reporter may or may not have a registered Hackrate account at the time of submission.
At every stage, the report retains a full audit trail: the original description, proof-of-concept attachments, all comments (public and internal), the CVSS vector, the assigned team member, and the full status history. Nothing is lost as the report moves through its lifecycle.
## The report inbox
Your report inbox is found under **Reports → My Program Reports**. It displays all vulnerability reports submitted to the programs you have administrative access to. The inbox is built around four distinct **view modes** that let you focus on exactly the subset of reports relevant to your current task.
Shows every report whose status is classified as **Open** — meaning it is still active and requires attention. This is the default view and the best starting point for your daily triage work.
Shows only reports in **New**, **Needs more info**, or **New – To review** status. This is your incoming queue: reports that are waiting for an initial review or are pending a researcher's response to your clarification request.
Shows every report you have access to, regardless of status — including all open and closed reports. Use this when you need a complete picture of your program's history or want to audit past decisions.
Opens a side-panel with granular filters so you can build custom queries across your entire report dataset. Combine any mix of filters to get exactly the slice of data you need.
A **pending reports** counter at the top of the inbox shows how many reports are currently in the New queue (New, Needs more info, or New – To review), giving you an at-a-glance measure of your team's outstanding workload.
## Searching and filtering
A global search bar is always visible regardless of the active view mode. It searches across report ID, title, program name, status, severity, and the reporter's alias in real time, letting you jump directly to a specific report without changing your current view.
In **Advanced view**, a persistent side panel exposes the following filters, which can be combined freely:
* **From date / To date** — filter by report creation date within an inclusive date range
* **Programs** — select one or more of your accessible programs; leave empty to include all
* **Hacker alias** — filter by the submitting researcher's username
* **Statuses** — filter by one or more specific status names (e.g. Accepted, Resolved)
* **Open / Closed** — filter by status type to see only open or only closed reports
* **Severities** — filter by Critical, High, Medium, Low, or None
Use **Advanced view** when preparing for a sprint review, a bug bounty programme audit, or a board-level report. You can combine a date range with a specific severity level to see, for example, all Critical and High reports submitted in the last quarter.
The table columns — ID, Report title, Program, Created, Last activity, Status, and Severity — are all sortable. Last activity reflects the most recent comment on the report, so sorting by it descending puts the most recently active reports at the top.
## Exporting reports to CSV
The **Export CSV** button in the inbox header opens an export dialog that lets you select exactly which data columns to include and apply optional filters before generating the file.
### Available export columns
| Column | Description |
| ------------------- | ---------------------------------------------------------------------------------------------- |
| ID | Unique report identifier |
| Report Title | The name/title of the report |
| Program | Program the report was submitted to |
| Created At | Submission date |
| Reporter | Researcher's alias |
| Severity | Critical / High / Medium / Low / None |
| Status | Current status name |
| Status Type | Open or Closed |
| Target | The specific asset the vulnerability affects |
| Tier | Target tier (Tier 1 or Tier 2) |
| Bounty | Bounty amount awarded |
| Duplicate Of | ID of the original report if this is a duplicate |
| CAPEC ID | Vulnerability type classification name (e.g. "SQL Injection") |
| Business Unit | Business unit associated with the target |
| Bonus | Additional bonus amount awarded |
| Last Activity | Date and time of the most recent comment; falls back to the creation date if no comments exist |
| CVSS Score | CVSS vector string |
| VDP | Whether the report was submitted via an embedded/VDP form |
| Assigned To (Email) | Email address of the team member assigned to the report |
**SuperAdmin** users can additionally export the **Summary**, **Description**, and **Impact** fields, which contain the full technical content of the report. These fields are restricted to protect sensitive vulnerability details in environments where not all export recipients have SuperAdmin clearance.
You can use the **Use current table filters** shortcut in the export dialog to carry over whatever program, status, date, and severity filters you already have active in the Advanced view, making it easy to export exactly the subset you are currently looking at.
## Role-based report visibility
Not all team members see the same reports. Your effective role determines which statuses appear in your inbox:
* **SuperAdmin** and **StandardAdmin** — full access to all 14 report statuses, including early-stage statuses like Pre-submission, New, Needs more info, and all Not Accepted variants
* **Analytics** — read-only access to aggregate data; cannot see reports in early triage statuses (Pre-submission, New, Needs more info, Duplicate, or any Not Accepted variant)
* **Read-Only** — read-only access to the same report subset as Analytics
This means that team members without a SuperAdmin or StandardAdmin role will only see reports that have progressed beyond initial triage — keeping sensitive pre-decision reports visible only to those responsible for triaging them.
## Next steps
A complete reference for all 14 statuses in the triage workflow, including what each one means and who can see it.
Step-by-step guidance for reviewing, validating, assigning, and closing reports as a company admin.
Learn how the bounty table works, how to award payouts from the report view, and how to add bonus amounts.
# Vulnerability Report Statuses: A Complete Reference
Source: https://hackrate-bb-app.mintlify.app/companies/reports/report-statuses
A complete reference for all 14 Hackrate report statuses — what each one means, who can see it, and how reports move through the triage workflow.
Every report on Hackrate carries a status that tells your team — and the submitting researcher — exactly where that report stands in the triage lifecycle. Statuses are divided into two fundamental types: **Open** (the report is active and requires attention) and **Closed** (a final decision has been recorded and the report is no longer pending action). Understanding the full set of statuses, and what each one signals, is the single most important skill for running an effective vulnerability management programme.
There are **14 statuses** in total: 5 open and 9 closed.
## Open vs. Closed
An **Open** status means the report is still in flight. Someone — whether a researcher, a reviewer, or a team member — still has an action to take. Open reports appear in the **Open reports** view of your inbox and are counted in the pending-reports badge at the top of the page.
A **Closed** status means the report has reached a terminal decision. No further action is expected unless the report is explicitly reopened. Closed reports are hidden from the Open view but remain fully accessible in the **All reports** and **Advanced** views for audit, reference, and analytics purposes.
Closing a report does not delete it. All comments, evidence, CVSS data, bounty records, and status history are permanently retained and can be reviewed at any time.
## All 14 statuses at a glance
| ID | Status Name | Type | Appears in New queue |
| -- | --------------------------- | ------ | -------------------- |
| 1 | Pre-submission | Open | No |
| 2 | New | Open | ✓ Yes |
| 3 | Accepted | Open | No |
| 4 | Needs more info | Open | ✓ Yes |
| 5 | Resolved | Closed | No |
| 6 | Informative | Closed | No |
| 7 | Duplicate | Closed | No |
| 8 | Not Accepted (Invalid) | Closed | No |
| 9 | Not Accepted (Spam) | Closed | No |
| 10 | Not Accepted (Out of Scope) | Closed | No |
| 11 | Not Accepted (Self-Closed) | Closed | No |
| 12 | New – To review | Open | ✓ Yes |
| 13 | Good quality duplicate | Closed | No |
| 14 | Accepted risk | Closed | No |
## The New reports queue
The **New reports** view (available in the inbox view switcher) shows all reports in statuses **2 (New)**, **4 (Needs more info)**, and **12 (New – To review)**. These are the reports that most urgently need a human action: a first-time review, a follow-up on a clarification request, or formal routing before triage begins. Monitoring this queue daily helps your team avoid letting reports go stale.
## Detailed status descriptions
### Open statuses
A report that has been started by a researcher but **not yet formally submitted**. The researcher may be drafting their findings, uploading evidence, or completing required fields before hitting the submit button. Pre-submission reports are not visible to researchers on the platform as complete submissions, and they do not appear in the standard triage queue.
**For the company:** Pre-submission reports represent work in progress on the researcher's side. You generally do not need to take action until the report advances to **New** upon submission. SuperAdmin and StandardAdmin roles can see these reports for awareness purposes.
**Visibility:** SuperAdmin and StandardAdmin only. Non-super-admin team members cannot see reports in this status.
A **freshly submitted report** that has not yet been reviewed by any member of your team. This is the entry point for every standard submission from a registered researcher. The report contains the researcher's full write-up — title, description, summary, impact, CVSS score, severity, vulnerability type, target, and any attached proof-of-concept files — but your team has not yet made any triage decision.
**For the company:** New reports should be reviewed as promptly as possible. Your first actions will typically be to read the submission, check the pre-validation checklist, assign the report to a team member, and either accept it for further investigation, request clarification, or close it with an appropriate status.
**For the researcher:** The researcher knows their report has been received and is awaiting review. They cannot yet see whether their report has been read.
**Visibility:** SuperAdmin and StandardAdmin only. Other roles cannot see reports in this status.
The report has been **reviewed and confirmed as a valid vulnerability** by your triage team. Accepting a report signals to the researcher that the issue is real, in-scope, and that your team is working on a fix or mitigation. The report remains Open because remediation is still in progress.
**For the company:** Once you accept a report, it is good practice to communicate an estimated timeline to the researcher and begin your internal remediation workflow. You may also award a bounty at this stage, or wait until the vulnerability is fully resolved.
**For the researcher:** Acceptance is a positive signal — it means their finding is being taken seriously. Many researchers view the Accepted status as the trigger for bounty payment, though programmes vary on exact timing.
**Visibility:** All roles with any level of access to the report.
Your team has reviewed the submission and **requires additional information or clarification** from the researcher before a triage decision can be made. This status pauses the review clock on your side while the researcher provides what is needed — for example, a clearer reproduction case, an updated CVSS justification, or additional evidence.
**For the company:** When setting this status, always leave a clear comment explaining exactly what information you need and what format is preferred. Vague requests slow down resolution and create a poor researcher experience.
**For the researcher:** The researcher is notified and is expected to respond. Once they provide the requested information, the report is typically moved back to **New** or directly to **Accepted** depending on your workflow.
**Visibility:** SuperAdmin and StandardAdmin only. Other roles cannot see reports in this status.
A report that a SuperAdmin has explicitly moved into this state for formal team review. A SuperAdmin can apply this status to any report currently in **Pre-submission**, **New**, or **Needs more info** to signal that the report has been picked up and is pending assignment to a reviewer. It is commonly applied to reports received via an embedded form (VDP), but can also be used for any report that needs an explicit routing step before triage proceeds.
**For the company:** Treat New – To review reports with the same urgency as standard **New** reports. When working with embedded-form submissions, you can check the **VDP** indicator on the report to confirm the submission channel. If the submitter's email matches an existing Hackrate account, you can link the account to the report from the management view.
**For the researcher / submitter:** Depending on whether they have an account, the submitter may or may not be able to see updates. Inviting them to the platform from the report view enables full two-way communication.
**Visibility:** SuperAdmin and StandardAdmin only. Other roles cannot see reports in this status.
***
### Closed statuses
The vulnerability described in the report has been **fully remediated**. Your engineering or security team has deployed a fix, and the issue no longer exists in the affected target. Resolved is the most positive closed outcome and typically accompanies a bounty payout if the report was previously Accepted.
**For the company:** Before marking a report Resolved, verify that the fix has been deployed and, where possible, validated against the original reproduction steps. Leave a comment for the researcher explaining what was done.
**For the researcher:** Resolved is the expected end state for a valid, accepted report. It confirms that their work had a real impact on your security posture.
The report describes a **real observation** — something factually accurate about your environment — but it does not constitute a security vulnerability that requires remediation. The finding may describe expected behaviour, a known limitation, or a low-impact behaviour that does not meet your programme's risk threshold.
**For the company:** Use Informative thoughtfully. Researchers who receive this status may be frustrated if they believe the finding is more serious. A well-written comment explaining why the finding is informative rather than a vulnerability (e.g. "this behaviour is by design and documented in our security policy") leads to a much better outcome than a bare status change.
**For the researcher:** The report is not being rewarded but is acknowledged as a genuine, good-faith submission. Some programmes offer points or recognition for Informative reports.
The vulnerability has **already been reported by another researcher**. The report is closed to avoid double-counting or double-paying for the same issue. The **Duplicate Of** field on the report records the ID of the original (first-reported) report.
**For the company:** Only mark a report as a duplicate when you are confident the root cause and the affected asset match. A partial overlap is not automatically a duplicate. Always point the researcher to the original report ID using the Duplicate Of field, and consider leaving a brief comment.
**For the researcher:** Receiving a Duplicate status is disappointing but normal in active programmes. The researcher should be told which report was the original so they understand the decision.
**Visibility:** SuperAdmin and StandardAdmin only. Other roles cannot see duplicate reports.
The submission **does not demonstrate a real security vulnerability**. The reported behaviour may be expected, the proof of concept may be non-functional, or the claimed impact may be inaccurate or unachievable. This is a firm rejection of the security claim itself — not a procedural rejection.
**For the company:** Provide a clear, specific explanation in your closing comment. Vague rejections damage trust and discourage good-faith researchers. Where possible, explain exactly which part of the submission did not hold up (e.g. "the SSRF requires an internal network position that is not attainable from the internet").
**Visibility:** SuperAdmin and StandardAdmin only. Other roles cannot see reports in this status.
The submission is **low-quality, automated, or clearly irrelevant** — for example, a generic scanner output dumped without context, an off-topic message, or a repeated submission with no new information. Spam reports typically show little to no effort from the researcher.
**For the company:** Use this status only for genuinely low-quality submissions, not as a shortcut for reports that are merely wrong. Mislabelling a sincere-but-incorrect report as Spam has a significant negative impact on researcher relations and programme reputation.
**Visibility:** SuperAdmin and StandardAdmin only. Other roles cannot see reports in this status.
The vulnerability is **real** and may even be valid, but it affects an asset, domain, subdomain, or feature that is explicitly **not covered by your programme scope**. The report is closed because your programme cannot accept or reward findings outside its defined boundaries.
**For the company:** Before closing as Out of Scope, double-check your programme's in-scope and out-of-scope asset list. If the target is ambiguous, consider clarifying your scope definition rather than penalising the researcher. Leave a comment pointing the researcher to your programme scope documentation.
**Visibility:** SuperAdmin and StandardAdmin only. Other roles cannot see reports in this status.
The report was **closed without a formal resolution** — either by the researcher themselves withdrawing the submission, or by an admin closing the report after the researcher became unresponsive or explicitly withdrew their finding. This status documents that the report ended without a definitive technical verdict from your team.
**For the company:** Self-Closed is appropriate when a researcher retracts their own report, when communication has broken down entirely after reasonable attempts, or when a pre-submission report was never completed. It is not a substitute for proper rejection when you have reviewed the submission.
**Visibility:** SuperAdmin and StandardAdmin only. Other roles cannot see reports in this status.
This report covers a vulnerability that was **already reported by another researcher**, but the submission itself is of **notably high quality** — well-written, thoroughly documented, with clear reproduction steps and meaningful impact analysis. While it cannot be accepted as a primary finding, its quality warrants recognition.
**For the company:** Use Good quality duplicate when you want to acknowledge a researcher's effort even though they were not the first to report the issue. Some programmes pair this status with a partial bounty, a bonus payment, or a public thanks to reward thoroughness and professionalism.
**For the researcher:** This status signals that their work was seen and valued, even if the vulnerability was already known. It is a meaningful distinction from a plain Duplicate status.
The vulnerability is **confirmed as valid and real**, but your organisation has made a **conscious, deliberate decision to accept the risk** rather than remediating it. This might be because the cost or complexity of remediation outweighs the business risk, the vulnerability is only exploitable under conditions considered sufficiently unlikely, or a compensating control is already in place.
**For the company:** Accepted risk should be used with care and proper internal sign-off. Document your rationale in the **Team Summary** field (visible only to your team) and communicate the outcome clearly to the researcher. Consider whether a bounty or partial reward is appropriate given that the finding was valid.
**For the researcher:** Accepted risk confirms their finding is real and has been reviewed at a senior level. It is a closed status, so the issue is not expected to be fixed, but the researcher's work is acknowledged.
## Status flow overview
Reports do not follow a single linear path. The diagram below describes the most common transitions:
```
Researcher submits
│
▼
[2] New ──► (SuperAdmin routes) ──► [12] New – To review
│ │
│◄──────────────────────────────────────┘
│
├──► [4] Needs more info ──► (researcher responds) ──► [2] New
│
├──► [3] Accepted ──► [5] Resolved
│ │
│ └──► [14] Accepted risk
│
├──► [6] Informative
├──► [7] Duplicate ──► or ──► [13] Good quality duplicate
├──► [8] Not Accepted (Invalid)
├──► [9] Not Accepted (Spam)
├──► [10] Not Accepted (Out of Scope)
└──► [11] Not Accepted (Self-Closed)
```
Closed reports can be **reopened** by an admin if new information comes to light — for example, if a researcher provides compelling additional evidence after a rejection, or if a Resolved vulnerability regresses in a later release.
## Role-based status visibility
The statuses visible to a team member depend on their assigned role. This ensures that sensitive pre-decision reports are only seen by those responsible for triaging them.
Full visibility across **all 14 statuses**, including:
* Pre-submission (1)
* New (2)
* Needs more info (4)
* Duplicate (7)
* Not Accepted — Invalid (8)
* Not Accepted — Spam (9)
* Not Accepted — Out of Scope (10)
* Not Accepted — Self-Closed (11)
* All other open and closed statuses
SuperAdmins can also export the sensitive report fields (Summary, Description, Impact) via CSV.
Can only see reports that have been reviewed and have progressed past the initial triage stage. The following statuses are **hidden** from these roles:
* Pre-submission (1)
* New (2)
* Needs more info (4)
* Duplicate (7)
* Not Accepted — Invalid (8)
* Not Accepted — Spam (9)
* Not Accepted — Out of Scope (10)
* Not Accepted — Self-Closed (11)
Visible statuses include: Accepted, Resolved, Informative, New – To review, Good quality duplicate, and Accepted risk.
Never share access credentials with individuals who should not see pre-decision reports. Use the Analytics or Read-Only roles for team members whose responsibility is reporting and analysis rather than active triage.
# How to Triage Vulnerability Reports as a Company Admin
Source: https://hackrate-bb-app.mintlify.app/companies/reports/triaging
Step-by-step guidance for reviewing evidence, validating severity, assigning reports, communicating with researchers, and reaching a final triage decision.
Triaging is the process of turning a raw researcher submission into a clear, actionable decision — whether that means accepting a valid vulnerability, requesting more information, marking a duplicate, or closing the report with a rejection. Done well, triaging protects your organisation, builds trust with the research community, and keeps your programme running efficiently. This guide walks you through everything you need to do from the moment a new report lands in your inbox to the moment you set a final status.
## Accessing the report management view
Every report has a dedicated management page that only company admins can access. You reach it from **Reports → My Program Reports** by clicking the report title in the inbox table. The management view shows the full report contents, a pre-validation checklist, the CVSS scorer, all comments, attached evidence files, and all available triage actions.
You must have a **SuperAdmin** or **StandardAdmin** role for the relevant programme or organisation to triage reports. Read-Only and Analytics roles can view reports but cannot take triage actions such as changing status, adding comments, or awarding bounties.
## Step-by-step triage workflow
### Review the report header
At the top of the management view you will see three summary cards showing the current **Status** (with its Open/Closed type), the **Target** (with its tier), and the **Severity** the researcher assigned. These give you an immediate at-a-glance orientation before you read the full submission.
Also check:
* **Program** — confirms which of your programmes this report belongs to
* **Target** — the specific asset the researcher tested; verify it is in-scope for your programme
* **Reporter** — the researcher's alias; useful context if you have prior interactions with this person
* **VDP flag** — if the report arrived via an embedded/VDP form, this will be indicated on the report
### Check the pre-validation checklist
Hackrate automatically analyses each report against a set of quality criteria and surfaces the results as a pre-validation checklist on the management page. This checklist checks whether the report includes all the elements needed for a productive triage:
Is a summary provided? A missing or very short summary is a signal that the researcher may not have clearly articulated the vulnerability.
Is a detailed description present? The description should explain how the vulnerability works and how it was discovered.
Is a business impact statement included? Good reports explain not just what is broken but what an attacker could do with it.
Are proof-of-concept files attached? Screenshots, videos, or request/response logs are critical for validation.
Has the researcher selected a severity level? An unset or implausible severity warrants attention.
Is the reported target currently in-scope for the programme? If the target is marked out-of-scope, the checklist will flag this immediately.
Use the checklist as a quick indicator, not an absolute gate. A report can fail one checklist item and still be a high-quality, valid finding — for example, a researcher who submits a clearly demonstrable, critical vulnerability without attaching a file may simply need a gentle prompt to upload a screenshot.
### Read the full report content
Scroll through the **Details** section to read:
* **Summary** — the researcher's concise description of the issue
* **Description** — the full technical write-up, including steps to reproduce
* **Impact** — the researcher's assessment of business risk
* **CVSS** — the submitted CVSS vector; you can view and recalculate it interactively on the management page using the built-in CVSS scorer
* **Vulnerability type** (CAPEC/CWE) — the classification the researcher selected
Review all **evidence files** (screenshots, videos, HTTP request captures, or code snippets) attached to the report. Evidence quality is often the deciding factor in borderline cases.
### Assess and adjust severity
The severity the researcher assigned may not match your assessment. If you disagree, you can change it directly from the management view. Severity affects the bounty calculation (if your programme uses a bounty table), so setting it accurately before awarding a payout is important.
Severity levels available are: **Critical**, **High**, **Medium**, **Low**, and **None**.
You can also update the **vulnerability type** (CAPEC classification) and the **CWE type** if the researcher's original selection was imprecise.
Use the interactive CVSS calculator on the management page to score the vulnerability yourself if you disagree with the researcher's vector. The recalculated score updates in real time and helps you justify a severity change to the researcher with a concrete, objective basis.
### Assign the report to a team member
If your organisation has multiple admins, assign the report to the team member best placed to investigate it — for example, the engineer who owns the affected system, or the security analyst specialising in the relevant vulnerability class. Use the **Assign** control on the management page to select from your programme's admin users.
Assigning a report creates clear ownership, prevents reports from falling through the cracks when multiple people are in the inbox, and makes the **Assigned To** column meaningful in CSV exports.
### Communicate with the researcher
The management view has a comment system with two distinct modes:
Visible to both your team and the researcher. Use public comments to:
* Ask for clarification or additional evidence
* Confirm that you have reproduced the issue
* Update the researcher on remediation progress
* Explain the rationale for a triage decision
Public comments are the primary channel for researcher communication and have a direct effect on programme reputation and researcher satisfaction.
Visible **only to your admin team**. Use internal comments to:
* Document your internal analysis and rationale
* Coordinate between team members
* Record notes about remediation steps or timeline
* Flag concerns that are not appropriate to share with the researcher
Internal comments are highlighted in green in the management view so they are visually distinct from public comments.
You can also store an internal **Team Summary** on the report — a free-text field that is never visible to the researcher and is intended for structured internal documentation of the finding and your team's response.
### Make the triage decision
Once you have reviewed the evidence, assessed severity, and (if needed) gathered additional information from the researcher, change the report's status to reflect your decision. The full set of available statuses is described in the [Report Statuses reference](/companies/reports/report-statuses), but the most common triage actions are:
| Action | Status to set |
| ------------------------------------------------ | --------------------------- |
| Confirm valid vulnerability | Accepted |
| Ask researcher for more details | Needs more info |
| Vulnerability has been fixed | Resolved |
| Finding is real but not a security risk | Informative |
| Already reported by another researcher | Duplicate |
| Report does not demonstrate a real vulnerability | Not Accepted (Invalid) |
| Submission is low-quality or irrelevant | Not Accepted (Spam) |
| Target is not covered by the programme | Not Accepted (Out of Scope) |
| Researcher withdrew or became unresponsive | Not Accepted (Self-Closed) |
| Organisation accepts the risk without fixing | Accepted risk |
| High-quality submission, but still a duplicate | Good quality duplicate |
Always leave a **public comment** when closing a report, especially with a rejection. A brief, specific explanation dramatically improves researcher experience and reduces disputes.
### Mark duplicates correctly
When closing a report as **Duplicate** or **Good quality duplicate**, use the **Duplicate Of** field to record the ID of the original (first-submitted) report that describes the same vulnerability. The dropdown on the management page shows all earlier reports in the same organisation's programmes, making it easy to find the right reference.
Only mark a report as a duplicate when the root cause and the affected asset genuinely match. A report that describes a related but distinct vulnerability in the same system is not automatically a duplicate — it may deserve separate triage and its own bounty.
### Award a bounty (if applicable)
If the report is valid and your programme is a paid bug bounty programme, you can award a bounty directly from the management view. See [Bounty Rewards](/companies/reports/bounty-rewards) for full details on how bounty amounts are determined and how to record the payment.
You can also award a **bonus** on top of the standard bounty for exceptional quality, unique impact, or particularly thorough documentation.
## Integrations available from the report view
The report management page provides direct access to two external integrations that help bridge your security triage workflow with your engineering and development processes.
Create a GitHub issue directly from the report. The issue is pre-populated with the report's title, summary, description, impact, and severity label. Once created, the issue is linked to the report and its current state (open/closed) is shown on the management page.
Draft a GitHub Security Advisory from the report. Automatically populated with the report summary, description, impact, affected package/target, and the researcher's GitHub login (if provided). Advisories are created as private drafts, giving your team time to review before any public disclosure.
If your programme has a **Jira integration** configured, a Jira issue creation shortcut will also be available on the management page, pre-filled with the report data.
## Hacktivity disclosure
Once a report is resolved, you may choose to publish it to the **Hacktivity** feed — Hackrate's public disclosure mechanism. Disclosing a report to Hacktivity increases programme transparency, rewards the researcher with public recognition, and contributes to the wider security community's knowledge base.
The Hacktivity disclosure option is available from the report management view for admins with SuperAdmin or StandardAdmin access. You control exactly when (and whether) to publish, so disclosure always happens on your terms and timeline.
## Reopening a closed report
If new information emerges after you have closed a report — for example, a researcher provides a compelling additional proof of concept after an Invalid rejection, or a Resolved vulnerability reappears in a new release — you can reopen the report using the **Reopen** action on the management page. This moves the report back to an open status and allows the triage process to continue.
# Hackrate Admin Groups for Team-Based Access Control
Source: https://hackrate-bb-app.mintlify.app/companies/team/admin-groups
Create named groups of admins and assign roles to the whole group at once, so new team members inherit the right access the moment they join.
Managing access one person at a time gets unwieldy as your security team grows. Admin Groups solve this by letting you create named collections of users — say, "Triage Team" or "Frontend Engineers" — and assign roles to the group as a whole. When you add someone to a group, they immediately inherit every permission that group holds. When you remove them, those permissions are revoked at the same time. You never have to track down a dozen individual role assignments just to offboard someone.
## What Admin Groups Are
An Admin Group is a reusable container that belongs to your organization. It has a name, an optional description, and a list of members. You can then assign the group one or more roles at any scope — organization, program, Business Unit, or individual report. When Hackrate evaluates a user's access, it expands their group memberships and combines them with any direct assignments, always applying the most privileged role that results.
Groups are visible from your organization management page alongside Business Units, programs, and individual user rights.
## Creating a Group
From your organization dashboard, click **Organization Management** (or your organization name in the top navigation). You need a SuperAdmin role at the organization level to manage groups.
Scroll to the **Admin Groups** section. You'll see a list of existing groups and an option to create a new one.
Give the group a clear, purpose-driven name (e.g., "Triage Team", "Security Researchers", "Frontend Team"). Add an optional description so other admins understand who belongs here.
Click **Create**. The group is now available to receive members and role assignments.
## Adding Members to a Group
From the Admin Groups list, click the group you want to manage.
Click **Add member** and enter the email address of the person you want to add. If they already have a Hackrate account, they are added immediately. If not, they receive an invitation email.
The user appears in the group's member list. Pending invitations are shown separately until the invitee registers.
A user can belong to multiple groups. Their effective role at any scope is always the most privileged role they hold, whether it comes from a direct assignment or any of their groups.
## Assigning a Role to a Group
You can assign a group a role at any of the four scope levels — organization, program, Business Unit, or report. The assignment works exactly the same way as assigning a role to an individual user.
Assign the group a role at the organization level to give every member access across all programs. This is appropriate for a core security team that triages reports from multiple programs.
From the organization management page, find the **User Rights** section, choose **Add right**, select the group instead of an individual user, pick the role, and set the scope to the organization.
Restrict the group's role to a single program. Members will only see reports from that program, nothing else. This is the most common assignment for product-team security contacts.
In the program's settings or the organization management panel, add a right for the group with the desired role and select the specific program as the scope.
Scope the group's role to a Business Unit so members only see reports for the targets in that unit. Ideal for siloed teams (e.g., a "Mobile Team" group whose role is scoped to a "Mobile Apps" Business Unit).
Give the group access to a single report. Useful when a vulnerability requires input from a cross-functional team but you don't want to expose the rest of your program.
## Worked Example: Creating a Triage Team
Create a new group named **Triage Team** with the description "First-line reviewers for all inbound reports."
Invite the three engineers responsible for first-pass triage. They receive email invitations.
Once the group is created, assign it the **StandardAdmin** role scoped to your main bug bounty program. This gives every member triage access to that program's reports.
When a new engineer joins the triage rotation, add them to the group. They immediately inherit StandardAdmin access — no extra role assignment required.
If a user is both a member of the Triage Team group (which has StandardAdmin at program level) and has a separate direct assignment of Read-Only at the organization level, Hackrate evaluates all of their rights together and applies the most privileged one. In this case, they would have StandardAdmin on the specific program and Read-Only everywhere else.
Group membership never *reduces* access — it can only add to it.
Removing a user from a group revokes the rights that came from that group. If the user also has direct assignments, those remain. Always review a user's direct rights before assuming removal from a group fully revokes their access.
# Business Units for Target-Scoped Access Control in Hackrate
Source: https://hackrate-bb-app.mintlify.app/companies/team/business-units
Group your program's targets into Business Units so each team only sees the reports relevant to their area, without access to unrelated assets.
A typical bug bounty program spans many different targets — web applications, mobile apps, APIs, and infrastructure. Not every team member needs to see every report. A mobile developer shouldn't wade through backend API vulnerabilities, and an infrastructure engineer doesn't need to review UI-layer issues. Business Units let you slice your targets into meaningful groups so that each team's access is limited to the reports that are actually relevant to them.
## What Business Units Are
A Business Unit is a named grouping that belongs to your organization and contains one or more targets from your programs. You can then assign admin rights — for an individual user, an Admin Group, or both — scoped specifically to that Business Unit. When a report comes in against a target, Hackrate automatically associates the report with the Business Units that contain that target, and anyone whose role is scoped to that Business Unit can see and manage that report.
Business Units exist at the organization level, which means the same unit can span targets across multiple programs if your targets are organized that way.
## How Business Units Connect to Targets
The link between a Business Unit and a target is called a **Business Unit Scope**. Each scope entry says: "this target belongs to this Business Unit." A single target can belong to multiple Business Units — for example, a shared authentication service might belong to both a "Backend Team" unit and a "Security Core" unit.
When someone holds a role scoped to a Business Unit, Hackrate resolves access like this:
1. Look up all targets assigned to that Business Unit.
2. Find all reports submitted against those targets.
3. Grant the user the assigned role over exactly those reports.
Reports outside the Business Unit's targets remain invisible to that user (unless they have broader access through another assignment).
## Creating a Business Unit
Navigate to your organization dashboard and open **Organization Management**. You need a SuperAdmin role at the organization level to create and manage Business Units.
Scroll to the **Business Units** section. Existing units are listed here; click **Create Business Unit** to start a new one.
Choose a name that clearly describes the team or area it represents — for example, **Mobile Team**, **Web Frontend**, **Cloud Infrastructure**, or **Payment Services**.
Click **Create**. The Business Unit is now available for target assignment and access control.
## Assigning Targets to a Business Unit
From the Business Units list, select the unit you just created.
Use the target selector to assign the relevant targets from your programs to this unit. You can add any target that belongs to a program in your organization.
The unit's scope list shows every target it covers. Future reports submitted against any of these targets will be accessible to anyone whose role is scoped to this Business Unit.
If a target is part of more than one Business Unit, all users with access to either unit will see reports for that target. Use this intentionally — for example, a shared login service could live in both a "Backend Team" unit and an "Authentication Team" unit.
## Granting Access at the Business Unit Level
Once a Business Unit has targets assigned, you can give users or groups a role scoped to that unit. They will only be able to see and act on reports whose target falls within the unit.
From the organization management page, go to **User Rights** or the **Team** section.
Click **Add right**, select the user or Admin Group, choose their role (e.g., StandardAdmin), and set the scope to the Business Unit you created.
The user now appears in the team list with their role and the Business Unit scope noted. They will see only the reports tied to that unit's targets when they log in.
## Use Case: Mobile Team Access
Your program has six targets: a web app, an iOS app, an Android app, a REST API, an admin portal, and a payment gateway. Your mobile developers should only triage vulnerabilities found in the iOS and Android apps.
**Setup:**
1. Create a Business Unit called **Mobile Apps**.
2. Assign the iOS app target and the Android app target to the Mobile Apps unit.
3. Create an Admin Group called **Mobile Triage Team** and add your mobile engineers.
4. Assign the Mobile Triage Team the **StandardAdmin** role scoped to the **Mobile Apps** Business Unit.
**Result:**
Your mobile engineers can log in, see a report queue containing only reports against the iOS and Android targets, triage them, and leave internal comments — all without ever seeing vulnerabilities in the web app, API, or payment gateway.
Business Unit membership is shown on individual report management pages, so reviewers always know which organizational area a report belongs to. This is also reflected in CSV exports, where a "Business Unit" column shows the unit or units associated with each report's target.
Removing a target from a Business Unit immediately affects the access of everyone whose role is scoped only to that unit. They will lose visibility into reports for that target. If you are reorganizing Business Units, coordinate with your team first.
# Managing Team Roles and Permission Scopes in Hackrate
Source: https://hackrate-bb-app.mintlify.app/companies/team/roles-permissions
Understand the four Hackrate roles, what each can do, and how to apply them at the right scope — from your whole organization down to a single report.
Every person you invite to help manage your Hackrate programs gets exactly one role at a given scope. The role defines *what* they can do; the scope defines *where* that permission applies. Getting this combination right means your triage team can work efficiently without accidentally exposing sensitive reports to people who shouldn't see them — and it means you can bring in an external stakeholder for a single report without giving them access to your entire program.
## The Four Roles
Hackrate has four roles, ordered from most to least privileged:
Full access across every feature. A SuperAdmin can see all report statuses — including Pre-submission, New, Needs more info, Duplicate, Invalid, Spam, Out of Scope, and Self-Closed — change any status, award bounties, manage team membership, and alter program settings.
Triage and management access. A StandardAdmin can review, comment on, update reports, award bounties, manage program settings, and invite team members within their scope. They work in a filtered view that hides early-stage and rejection statuses, keeping their queue focused on actionable items.
Read-only access to analytics dashboards and aggregated report data. Useful for management stakeholders who need visibility into program metrics without interacting with individual reports.
Read-only access to reports within the assigned scope. The user can view report details and comments but cannot take any action or see analytics dashboards.
## Role Comparison
The table below shows which actions each role can perform:
| Capability | SuperAdmin | StandardAdmin | Analytics | Read-Only |
| -------------------------------------------------------------------------------------------------- | :--------: | :-----------: | :-------: | :-------: |
| View all report statuses (including Pre-submission, Duplicate, Spam, and other rejection statuses) | ✅ | ❌ | ❌ | ❌ |
| Triage reports (change status, add internal comments) | ✅ | ✅ | ❌ | ❌ |
| Award bounties and bonuses | ✅ | ✅ | ❌ | ❌ |
| Manage program settings | ✅ | ✅ | ❌ | ❌ |
| Manage team members and invitations | ✅ | ✅ | ❌ | ❌ |
| View analytics dashboards | ✅ | ✅ | ✅ | ❌ |
| Export reports to CSV (including sensitive fields) | ✅ | ❌ | ❌ | ❌ |
| View reports (read access) | ✅ | ✅ | ✅ | ✅ |
StandardAdmins see a focused report queue that omits the following statuses: Pre-submission, New, Needs more info, Duplicate, Invalid, Spam, Out of Scope, and Self-Closed. This keeps their inbox clean and prevents premature triage of reports that have not yet passed initial validation or have already been closed as noise.
## Permission Scopes
A role only takes effect within the *scope* it was assigned to. Hackrate supports four scope levels, from broadest to most narrow:
The role applies to every program under your organization. Use this scope for trusted team members who need to work across all programs — for example, your head of security or a platform-wide analytics user.
The role applies only to one specific program and all reports within it. This is the most common scope for triage staff.
The role applies only to the subset of targets assigned to a particular Business Unit. For example, a "Mobile Team" Business Unit might contain only your iOS and Android app targets, limiting a triager's view to those reports only.
The role applies to a single report. This is useful for temporarily bringing in a specialist — a developer who owns the affected component, for instance — without exposing the rest of your program.
## Role Priority
A user may hold multiple roles if they belong to multiple Admin Groups or have been assigned rights at different scopes. Hackrate always applies the **most privileged role** a user holds across all their assignments. The priority order is:
1. SuperAdmin
2. StandardAdmin
3. Analytics
4. Read-Only
For example, if a user is a Read-Only at the organization level but a StandardAdmin on a specific program, they will have StandardAdmin access on that program and Read-Only access everywhere else.
## Assigning Roles
Navigate to your organization dashboard and open the **Team** or **Organization Management** section.
Click **Invite member** to add a new person by email, or select an existing member from the list.
Select the role you want to assign, then choose whether it applies at the organization level, a specific program, a Business Unit, or a single report.
The invitee receives an email. Until they accept, their invitation appears as **Pending** in the team list.
For managing teams of people rather than individuals, use **Admin Groups** instead of assigning roles one person at a time. Any role you assign to a group automatically applies to every member.
Only a SuperAdmin at the organization level can assign the SuperAdmin role to others. Make sure at least two people in your organization hold this role so you are never locked out.
# Setting Up Your Payment Information to Receive Bounties
Source: https://hackrate-bb-app.mintlify.app/researchers/account/payment-settings
Configure your payment method, understand currency and residency requirements, and learn what to expect when your first bounty is ready to be transferred.
Before any bounty can be paid to you, you need to save valid payment information in your account. Hackrate supports two payment methods — bank transfer and PayPal — and the setup takes only a few minutes. Keeping your payment details accurate and current ensures that when a company awards you a bounty, the transfer can proceed without delay.
## Navigating to payment settings
To access your payment settings, go to **Account Settings** and select the **Payment** tab. This page shows you two things: your saved payment details (if any have been entered) and a history of payment transactions associated with your account.
You must be signed in as a researcher to access the Payment settings page. Program administrators use a separate payments workflow.
## Choosing a payment method
Hackrate supports two active payment methods. Select the one that best fits your situation:
Bank transfer sends your bounty directly to a bank account. To use this method, you will need to provide:
* **Account holder name** — the full legal name on the bank account
* **Bank account number** — your IBAN or account number depending on your country
* **Bank name** — the name of your financial institution
* **Bank country** — the country where your bank account is held
* **Country of residence** — your current country of residence
Bank transfers are well suited to larger bounties and to researchers in countries with well-connected banking infrastructure.
PayPal transfers your bounty to a PayPal account using your email address. To use this method, provide:
* **PayPal email address** — the email address linked to your active PayPal account
* **Country of residence** — your current country of residence
PayPal is convenient for smaller bounties and for researchers in countries where international bank transfers involve high fees.
Double-check all payment details before saving. Errors in account numbers or email addresses can result in failed or misdirected transfers that are difficult to reverse. You are responsible for the accuracy of the information you provide.
## Individual vs. company payments
When entering your payment details, you can indicate whether you are receiving payment as an **individual** or as a **company**. This affects how your payout is processed and how invoicing is handled in some jurisdictions. If you operate as a freelance security consultant through a registered business entity, select the company option and ensure the account holder name matches your registered business name.
## Identity verification requirement
Your identity must be verified before your first bounty payout can be processed. This is a platform-wide requirement designed to comply with financial regulations and to protect both researchers and companies.
Go to **Account Settings → Verification** and complete the identity verification flow. You will need a government-issued photo ID, a proof of address document, and a camera for a live photo. See [Verification](/researchers/account/verification) for full instructions.
Return to **Account Settings → Payment** and enter your chosen payment method. You can save payment details before verification is complete, but the payout will not be initiated until your identity is confirmed.
Once a company awards a bounty and your identity is verified, the transfer is initiated. You will see the transaction appear in your payment history on this page.
## Currency considerations
Bounties are denominated in the currency chosen by the program — either **USD (\$)** or **EUR (€)**. The program currency is displayed in the program brief before you start testing.
* If you are paid via **bank transfer**, your bank may apply a currency conversion fee if your account is held in a different currency. Check with your bank for their international transfer rates.
* If you are paid via **PayPal**, PayPal's currency conversion rates and fees apply when the funds arrive in a currency different from your PayPal balance's default.
Consider holding a EUR or USD account if you participate frequently in programs denominated in those currencies — conversion fees can add up across multiple bounties.
## Keeping your payment information up to date
Your payment details are not updated automatically if you change banks or switch PayPal accounts. You are responsible for keeping this information current. Outdated details can result in failed transactions.
Update your payment information any time you:
* Change your bank account or close an existing account
* Update the email address on your PayPal account
* Move to a different country of residence
* Switch between individual and company payment status
If a payment transfer fails due to incorrect details, the funds are typically returned to the program. Contact Hackrate support as soon as possible with your corrected payment information so the transfer can be re-initiated. Providing accurate details at the outset avoids this delay.
## Security tips for your payment data
Your payment information is sensitive. Treat it with the same care you would any financial credential:
* **Never share your account settings credentials** with anyone, including other researchers. Hackrate staff will never ask for your password.
* **Enable two-factor authentication** on your Hackrate account to protect against unauthorized access to your payment details. See [Verification](/researchers/account/verification) for 2FA setup instructions.
* **Use a dedicated email address for PayPal** that is not easily guessable or linked to your public hacker identity.
* **Review your transaction history regularly** on the Payment page. If you see a transaction you do not recognize, contact support immediately.
* **Notify support promptly** if you suspect your account has been compromised, especially before any pending bounties are paid out.
# Identity Verification for Hackrate Bug Bounty Researchers
Source: https://hackrate-bb-app.mintlify.app/researchers/account/verification
Verify your identity on Hackrate to unlock private programs and payouts — covers document requirements, process steps, and verification statuses.
Identity verification on Hackrate confirms that you are who you say you are. Completing verification unlocks the full platform experience: access to private and invite-only programs, the ability to receive bounty payouts, and a verified badge on your public profile that signals credibility to companies. The process is guided and handled through a secure third-party identity verification service. Verification has a validity period; you will be notified before it expires so you can renew it without interruption.
## Why verification matters
Without a verified identity, some platform capabilities are restricted:
Many high-value programs are invite-only or have verification as a prerequisite for access. Your reputation and skill alone are not enough — companies require confirmed identities before sharing sensitive targets.
Identity verification may be required before your first bounty payment can be processed. This protects both you and the companies making payments by ensuring a verified chain of identity.
A blue verified checkmark appears next to your nickname on the leaderboard, on your public profile, and on any Hacktivity entries attributed to you. It is an immediate trust signal for program administrators.
Once verified, your country of residence is confirmed and locked to the issuing country on your identity document. This cannot be changed while your verification is valid.
## Before you begin
You will need the following before starting the verification flow:
* A valid **government-issued photo ID** — passport, national identity card, driving licence, or residence permit
* A **proof of address document** — a recent bank statement or utility bill
* A device with a working **camera** for the live photo (selfie) step
* Your **legal first and last name** as they appear on your identity document
The name you enter at the start of the verification flow must exactly match the name on your identity document. Mismatches will cause the check to fail and use up one of your allowed attempts.
## Starting the verification process
Navigate to **Account Settings** and select the **Verification** tab. You will see your current verification status and, if you have not started yet, a form to begin.
Provide your legal first name, last name, and your current country of residence. This creates your secure verification profile with the identity verification service. Your country of residence will be updated on your account at this point.
Once your profile is created, a guided verification widget loads in your browser. Follow the on-screen prompts to:
* Upload or photograph your **identity document** (passport, national ID, driving licence, or residence permit)
* Upload your **proof of address** (bank statement or utility bill)
* Take a **live photo** (selfie) so the system can match your face to your ID
After completing all captures, submit your documents. Two verification checks run in parallel: a **document check** (validating your ID) and an **identity check** (matching your live photo to your document). Processing typically completes within minutes, though it can take longer in some cases.
You will be notified when your verification result is available. Return to the Verification page to see your status. If both checks pass, your account is marked as verified immediately.
## Accepted document types
The following government-issued identity documents are accepted:
* **Passport** (any country)
* **National identity card**
* **Driving licence**
* **Residence permit**
Documents must be current and not expired. The name on the document must match what you entered when creating your verification profile.
One of the following is required as proof of address:
* **Bank statement** — must show your name and residential address
* **Utility bill** — gas, electricity, water, or broadband; must show your name and residential address
Documents should be recent (typically within the past 3 months). Digital or paper documents both accepted.
## Verification statuses
| Status | What it means |
| ---------------------- | -------------------------------------------------------------------- |
| **Not started** | You have not initiated the verification process yet |
| **Pending** | Your documents have been submitted and checks are processing |
| **Verified** | Both checks passed — your account is fully verified |
| **Requires attention** | One or more checks returned a result that needs manual review |
| **Rejected** | The documents could not be validated; you may be eligible to retry |
| **Expired** | Your verification has passed its validity period and must be renewed |
Verification has a limited validity period. When it expires, your verified status is removed from your account until you complete a new verification. You will be notified before expiry so you can plan ahead.
## Retrying after a failed attempt
If your verification attempt is rejected, you may be eligible to retry the capture step with fresh documents. A limited number of automated attempts are available. If you exhaust those attempts, contact Hackrate support — the team can assist with manual review.
1. Go back to **Account Settings → Verification** and check the status message for details on what went wrong.
2. Ensure your documents are clear, fully in-frame, and not expired.
3. Retry using the capture flow — a fresh attempt resets the captured documents while keeping your verification profile.
4. If the issue persists after your available attempts are exhausted, reach out to Hackrate support for assistance.
## Two-factor authentication (2FA)
While you are in your account security settings, you should also consider enabling **two-factor authentication**. 2FA adds a second layer of protection to your login, requiring approval from your registered authentication method every time you sign in.
Navigate to **Account Settings** and look for the **Two-Factor Authentication** section.
Click **Enable Two-Factor Authentication**. The system will add your account to the 2FA group and immediately revoke your active session.
After enabling 2FA, sign back in. You will now be prompted for a second factor on every login. This is a one-way action — once enabled, 2FA cannot be self-disabled.
Enabling 2FA immediately signs you out of your current session. Make sure you have access to your second factor before confirming. If you lose access to your authentication method, contact Hackrate support.
## Citizenship declaration
After your identity is verified, you may be asked to complete a **Citizenship Declaration** — a statement confirming whether you hold citizenships or nationalities beyond the country on your verified identity document. This declaration is required for eligibility assessment on certain programs and must be renewed each time your verification is renewed. Full instructions are available on the Verification page after your identity check passes.
# Hackrate for Security Researchers: An Introduction
Source: https://hackrate-bb-app.mintlify.app/researchers/introduction
How Hackrate works for ethical hackers: find programs, earn bounties, build a verified reputation, and unlock invitations to exclusive private programs.
Hackrate is an ethical hacking platform that bridges the gap between skilled security researchers and organizations that need their systems tested. As a researcher, Hackrate gives you a structured, legal, and rewarding way to put your skills to work: you find real vulnerabilities in real products, report them through a managed process, earn bounties or reputation points, and build a verified track record that opens doors to more exclusive opportunities.
The platform operates across two types of programs. **Public programs** are listed openly in the [Program Catalog](/researchers/programs/catalog) and are accessible to any registered researcher. **Private programs** are invite-only — they don't appear in the catalog, and you can only participate after receiving or requesting an invitation. Private programs often involve higher bounties and more sensitive targets, and access to them is typically earned by demonstrating consistent, high-quality work on public programs first.
## Your researcher journey at a glance
Every researcher on Hackrate moves through roughly the same lifecycle, from creating an account to receiving payment for a valid finding.
Create your account and configure your public researcher profile. Choose a unique nickname (up to 16 characters) — this is what program owners and the leaderboard will display. Add a bio, your country, social links, and a profile picture to build credibility with program owners.
Before you can receive bounty payouts, you must verify your identity through Hackrate's ID verification process. Verification also unlocks a verified badge on your public profile, which signals trustworthiness to program owners managing private programs.
Browse the public catalog, read program descriptions and policies, and carefully review each program's scope. Every program lists its in-scope targets — the systems you are authorized to test. Only submit reports for assets that are explicitly in scope.
Test in-scope targets within the permitted testing window and according to the program's rules. When you find a valid issue, write a clear, reproducible report and submit it through the platform. Each report should cover exactly one vulnerability.
Valid reports earn you reputation points and, on bounty programs, a monetary reward. Reputation affects your standing on the leaderboard and your chances of being invited to private programs.
## Key concepts for researchers
Get up and running on Hackrate in minutes. Step-by-step instructions from registration through your first report submission.
Browse all publicly available bug bounty and VDP programs, read program details, and find your first target.
Configure your nickname, bio, country, social links, profile picture, and notification preferences.
Learn how to read target lists, identify in-scope assets, understand tier-based bounty implications, and avoid out-of-scope findings.
## Reputation and stats
Your Hackrate profile tracks three key metrics that reflect your effectiveness as a researcher:
* **Reputation score** — accumulated points awarded when your vulnerability reports are accepted and validated. This is the primary metric used by the leaderboard and by program owners evaluating researchers for private program invitations.
* **Vulnerability Rate** — a score reflecting the quality and impact of the vulnerabilities you have discovered.
* **Hacking Rate** — a broader metric of your overall activity and contribution across programs.
These metrics are visible on your public profile and on the leaderboard, which lets you compare your performance against researchers from around the world, filtered by time period or country.
## Identity verification and payouts
Identity verification is required before Hackrate can process any monetary bounty payout. You can participate in programs and submit reports without being verified, but payment will be held until verification is complete. Begin the verification process early so it doesn't delay your first payout.
Verification uses a third-party identity check service. You will be asked to provide a valid government-issued ID document and a live photo. Once verified, your profile displays a verification badge that increases your credibility with program owners and may accelerate invitations to private programs. Verification is periodically renewed to maintain the integrity of the platform.
## Hackrate Elite Club
The most trusted and high-performing researchers on the platform may be selected for the [Hackrate Elite Club](https://elite.hckrt.com). Elite membership represents the highest level of trustworthiness on the platform and typically results in priority invitations to the most exclusive private programs.
# Complete Guide to Your Hackrate Researcher Profile
Source: https://hackrate-bb-app.mintlify.app/researchers/profile-setup
Configure your Hackrate researcher profile: pick a nickname, write a bio, add social links, upload a photo, and tune your email notification preferences.
Your Hackrate researcher profile is your public identity on the platform. Program owners read it when triaging your reports, when deciding whether to invite you to private programs, and when evaluating contested findings. A complete, professional profile signals seriousness and credibility — both of which translate directly into better opportunities.
You can access all profile settings by navigating to **Manage → Profile Settings** after signing in.
## Choosing your nickname
Your nickname is the single most important field on your profile. It appears on every report you submit, on the public leaderboard, and on your public profile page. Choose it thoughtfully before you submit your first report, because it cannot be changed later.
Nicknames are limited to **16 characters** and must be unique across the platform. Once set, your nickname is permanent. Your report history and reputation are permanently tied to it.
Good nicknames tend to be short, memorable, and professional. Avoid usernames that could be perceived as threatening or unprofessional — program owners are more likely to engage constructively with researchers whose identities feel trustworthy.
Your nickname also serves as your platform email alias. Once set, you will have a `@letmehack.it` email alias in the format `yournickname@letmehack.it`, which you can use to receive program communications through the platform.
## Basic profile information
| Field | Details |
| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Your real name. Used for payment records and identity verification. Not displayed publicly by default. |
| **Country** | Your country of residence. Shown on the leaderboard and required for identity verification. After your identity is verified, your country can only be changed through the verification process — it is locked on the profile settings form. |
| **About Me** | A short biography, up to **500 characters**. Hackrate supports [Markdown syntax](https://www.markdownguide.org/cheat-sheet/), so you can use bold, links, lists, and code formatting. Use this space to describe your security background, specialties (web, mobile, API, network), and any certifications or notable work. |
Connecting your professional accounts to your Hackrate profile helps program owners verify your background and expertise. All social link fields are optional, but providing them increases trust.
| Platform | Field format |
| --------------- | ---------------------------------------------------------------------- |
| **GitHub** | Username only — `https://github.com/` is prepended automatically |
| **LinkedIn** | Profile handle — `https://linkedin.com/in/` is prepended automatically |
| **Twitter / X** | Handle — `https://x.com/` is prepended automatically |
| **Facebook** | Username — `https://facebook.com/` is prepended automatically |
| **Website** | Full URL to your personal site, blog, or portfolio |
| **CodersRank** | Full URL to your CodersRank profile |
Your GitHub profile is often the most valuable link for security researchers. A profile with public security tools, CTF write-ups, or proof-of-concept repositories demonstrates hands-on experience more effectively than a written bio alone.
## Uploading a profile picture
A profile picture makes your profile immediately recognizable and adds a personal touch to the reports and leaderboard entries associated with your nickname.
To upload or update your photo:
From **Manage → Profile Settings**, click **Add Photo** in the Actions sidebar on the right.
Choose a JPEG (`.jpg` / `.jpeg`), PNG (`.png`), or GIF (`.gif`) file. The maximum file size is **5 MB**.
The image is stored securely on the platform's CDN. After upload, it will appear on your profile, on the leaderboard, and beside your name in report activity feeds.
EXIF metadata (location data, device information) is automatically stripped from your uploaded photo before storage to protect your privacy.
## Email notification preferences
Hackrate sends email notifications to keep you informed about activity on your submitted reports. You can customize exactly which events trigger emails and how much detail those emails contain.
Navigate to **Manage → Profile Settings** and scroll to the **E-mail preferences** section.
### Notification types
Notifies you when a new report is submitted to a program you are associated with. Most useful if you manage or co-administer a program.
Sends an email whenever the status of one of your submitted reports changes — for example, when it moves from "New" to "Triaged", or from "Triaged" to "Resolved". This is the most important notification type for active researchers.
Notifies you when a program owner or triager adds a public comment to one of your reports. Enable this to stay on top of back-and-forth during the validation process.
Covers comments that are visible only to the program team. Depending on your role on a program, this may include notes about your report that are relevant to its outcome.
Sends a notification when a file is attached to one of your reports — for example, when a program owner uploads a patch confirmation or additional context.
Occasional platform announcements, new program launches, and community news from Hackrate. You can disable this without affecting report-related notifications.
### Content level
In addition to toggling individual notification types, you can control the **level of detail** included in notification emails:
| Level | Setting | Description |
| ----- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| 1 | **Minimal** | Short notifications with just the essential information — report title and status change. No report body or comment text included. |
| 2 | **Typical** | The default. Includes the key details of the update, enough to understand what changed without opening the platform. |
| 3 | **Full** | Complete email content including full report descriptions, comment text, and attachments where applicable. |
The **Typical** content level (level 2) is the recommended setting for most researchers. It keeps you informed without overwhelming your inbox, and it avoids sending sensitive vulnerability details in full through email.
## Security settings
You can access additional account security settings from the **Actions** sidebar on the **Manage → Profile Settings** page:
Reset your account password at any time. Use a strong, unique password that you do not reuse on other platforms.
Enable two-factor authentication (2FA) for an additional layer of account security. Once enabled, sign-ins require both your password and a second factor. 2FA is strongly recommended for all researchers.
## Privacy considerations
Your **nickname**, **About Me** bio, **country**, **profile picture**, and **social links** are all visible to other platform users and to program owners. Your **name** and **email address** are not shown publicly.
You can download a copy of all the personal data associated with your account at any time by clicking **Download** in the **Download Data** section of the Actions sidebar.
If you want to delete your account and have all personal data removed, contact the Hackrate support team at [support@hckrt.com](mailto:support@hckrt.com). Account deletion is handled manually to ensure all associated data is properly removed.
# How to Browse the Hackrate Bug Bounty Program Catalog
Source: https://hackrate-bb-app.mintlify.app/researchers/programs/catalog
Navigate the public program catalog, read program pages, interpret scope and bounty tables, and check activity statistics before committing to a target.
The Hackrate Program Catalog is the central hub for discovering publicly available programs. Every program listed there is open to any registered researcher — no invitation needed. The catalog is your starting point for finding organizations to test, understanding what they offer, and choosing where to invest your hacking time.
Programs in the catalog span a range of industries, target types, and reward structures. Some are **bounty programs** that pay monetary rewards for valid findings; others are **Vulnerability Disclosure Programs (VDPs)** that award reputation points instead of cash. Both types appear in the catalog.
## Reading the catalog cards
Each program in the catalog is displayed as a card. Here is what each card tells you at a glance:
The official name of the bug bounty or VDP program. Click **View program** to open the full detail page.
Programs marked with a **Bounty** badge offer monetary rewards for valid findings. Programs without this badge award reputation points through their VDP process.
A **Hackrate Managed** badge means Hackrate's team handles triage, validation, and researcher communication on behalf of the program owner. **Unmanaged** programs are run directly by the company.
Programs launched within the last 10 days show a **New** badge. Fresh programs often have untouched attack surface — a good opportunity for early findings.
You may also see **Private program** cards in the catalog. These display a placeholder description and a disabled **View program** button. They appear in the catalog listing to signal that private programs exist on the platform, but you cannot access them without a direct invitation. See [Private Programs](/researchers/programs/private-programs) for details.
## The program detail page
Clicking **View program** on a catalog card opens the full program detail page. This is where you spend the most time before deciding to test a program — and before making your first test request.
### Program header
The header of the program detail page shows:
* **Program name and alias** — The alias (e.g., `@acme`) is the short identifier used in report submission and internal references.
* **Company website** — A direct link to the organization's main site.
* **Launch date** — When the program first became active on Hackrate.
* **Testing period** — If the program owner has defined a specific testing window (e.g., `24/7`, or specific days and hours), it appears here. Always respect the stated testing period.
### Activity summary
Below the header, you will find a live summary of program activity:
| Metric | What it means |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **All Bounties / Reports** | On bounty programs: the total amount paid out to researchers (in EUR or USD) and the total report count. On VDP programs: the raw total report count. |
| **Last report** | The date of the most recently submitted report. A recent date means the program is actively being tested and triaged. |
A program with a large bounty total and recent activity is a strong signal that the organization takes the program seriously and pays promptly. A program with zero reports and an old launch date may be less actively maintained.
### Scope section
The **Scope** section lists every **in-scope target** — the systems you are authorized to test. Each target entry shows:
* **Name** — The specific domain, URL, app, or asset name (e.g., `api.example.com`, `Example Android App`)
* **Type** — The asset category (e.g., Web Application, API, Mobile App, Network)
* **Bounty indicator** — Whether this specific target is eligible for monetary rewards (some targets within a bounty program may be VDP-only)
* **Tier** — Tier 1 targets are primary/critical assets with higher bounty rewards; Tier 2 targets are secondary assets with lower rewards
Only the targets shown in the Scope section are authorized for testing. Any asset not listed — even if it belongs to the same company — is outside the program's authorization.
### About company
This section contains a Markdown-formatted description of the organization running the program: what the company does, what products or services are in scope, and any relevant context about their security posture. Read this before testing — understanding the business context helps you identify higher-impact vulnerabilities.
### Program Rules (Policy)
The **Program Rules** section is the legal and operational contract between you and the program owner. It specifies:
* Testing restrictions (e.g., no automated scanning, no denial-of-service attacks)
* Disclosure rules (e.g., coordinated disclosure timelines, embargo periods)
* Vulnerability types that are out of scope even on in-scope targets
* Safe harbor language — the legal protection the company extends to researchers operating within the rules
Violating the Program Rules can result in your report being rejected, your account being suspended, or — in serious cases — legal consequences. Read the policy in full before submitting any report, and re-read it before testing any new type of vulnerability.
### Bounty table
On bounty programs, a **Bounty Table** is displayed below the Program Rules. It shows the exact monetary award for each combination of **severity** (Critical, High, Medium, Low) and **target tier** (Tier 1, Tier 2):
| | Critical | High | Medium | Low |
| ---------- | -------------- | --------------- | --------------- | -------------- |
| **Tier 1** | Highest reward | High reward | Moderate reward | Low reward |
| **Tier 2** | High reward | Moderate reward | Low reward | Minimal reward |
Actual values vary by program. The currency (EUR or USD) is specified per program. Use the bounty table to prioritize your testing — focus on Tier 1 targets with critical or high-severity findings to maximize potential earnings.
### Announcements
If the program owner has posted a recent announcement (for example, a scope change, a known issue exclusion, or a temporary testing pause), it appears as a highlighted alert at the top of the program page. Always read the latest announcement before testing, as it may override information in the main description or policy.
## Evaluating programs before you commit
Not all programs are equally worth your time. Use these signals to evaluate a program before investing significant effort:
Check the **Last report** date in the activity summary. If reports were submitted recently, the program is being actively monitored. A last report date of over six months ago may indicate slow triage or low program owner engagement.
On bounty programs, a fully populated bounty table with competitive rates signals that the company is serious about compensating researchers fairly. Very low bounties (e.g., single-digit dollar amounts) may not justify the time investment for complex findings.
Programs with many diverse in-scope targets give you more surface area to find issues. A program with only one or two targets may be heavily tested already, making new findings harder to find.
A detailed, well-written Program Rules section indicates a mature, well-run program. Vague or minimal policies can lead to disputes over whether a finding is in scope — choose programs where expectations are clear.
# Private Programs: Invitations, Access, and Participation
Source: https://hackrate-bb-app.mintlify.app/researchers/programs/private-programs
Hackrate private programs explained: join by invitation or application, unlock the full scope once accepted, and build reputation to earn more invitations.
Not every program on Hackrate appears in the public catalog. **Private programs** are invite-only engagements where the company has chosen to work with a curated group of researchers rather than the entire Hackrate community. These programs are not discoverable through catalog browsing — you can only access them after receiving an invitation or being accepted through an application process.
Private programs are typically used by organizations with more sensitive systems, higher security maturity, or specific requirements around which researchers they work with. They often offer higher bounties, more focused scope, and more direct communication with the security team. Building a reputation that earns you private program access is one of the most valuable long-term goals for a Hackrate researcher.
## How private programs differ from public ones
Private programs do not appear as clickable cards in the public catalog. You may see a locked placeholder card indicating a private program exists, but you cannot view any details without access.
You need either a direct invitation from the program owner or an accepted application to gain access. Browsing or submitting reports without access is not possible.
Program owners choose exactly who participates. This gives companies confidence in who is testing their systems and lets them build ongoing relationships with trusted researchers.
Even if you know a private program exists, you cannot submit a report against it until you have been formally accepted. Submissions from non-accepted researchers are rejected automatically.
## How to get access to a private program
There are two routes to joining a private program:
### Route 1: Direct invitation from the program owner
Program owners can invite specific researchers directly based on their Hackrate profiles. If you receive an invitation:
1. You will be notified through the platform and by email.
2. The program appears in your **Dashboard** under **Invites** for a limited period (12 days from the invitation date).
3. Accept the invitation to gain full access to the program scope, policy, bounty table, and report submission form.
Invitations expire after **12 days** if not accepted. If you miss the window, you will need to contact the program owner or wait for a new invitation. Check your platform dashboard and notifications regularly so you do not miss time-sensitive invites.
### Route 2: Applying through a public invitation link
Some programs provide a public application link that lets any researcher express interest in joining. When such a link is available, you can submit an application — this creates an access request that the program owner reviews before granting or denying access.
The application process is straightforward:
Public invitation links are shared by program owners through Hackrate communications, their company's security page, or community channels. You will not find them in the catalog itself.
When you open an application link while signed in to Hackrate, your application is recorded. Your public profile — including your nickname, reputation score, verified status, and submitted work history — is what program owners use to evaluate you.
Program owners review applications at their own pace. There is no guaranteed timeline. Building a strong reputation on public programs makes your application more compelling.
If accepted, the program appears in your Dashboard under **Applied Programs**. You can then access the full program page, review scope and policy, and begin submitting reports. If declined, you will be notified — this does not prevent you from applying to other programs.
## What changes once you are accepted
After acceptance, your experience is similar to a public program — but with some meaningful differences:
* **The full program page is unlocked.** You can read the complete scope, policy, bounty table, and any announcements that were previously hidden from you.
* **The report submission form is active.** You can submit vulnerability reports directly to the program.
* **Your accepted status is recorded.** Your access is tracked through a platform access record linked to both you and the program. This cannot be transferred or shared.
* **Higher expectations apply.** Private programs typically expect higher-quality reports, strict adherence to the program policy, and more professional communication than a general public program might. Program owners have chosen to work with you specifically — represent yourself accordingly.
Access to a private program does not mean unlimited testing. You are still bound by the program's scope and policy. Test only in-scope targets, during permitted testing hours, and within the rules set out in the program policy. Access can be revoked if you violate these terms.
## Building toward private program invitations
If you are new to Hackrate and do not yet have access to any private programs, the most reliable path is consistent, high-quality work on public programs. Program owners watch the leaderboard and public researcher profiles when deciding whom to invite.
Reputation is the primary signal program owners look at. Every valid finding on a public program earns reputation points. Aim for steady growth rather than chasing a single large bounty.
Verified researchers receive significantly more private program invitations. The verification badge signals to program owners that you have passed identity and trustworthiness checks. Complete your verification as early as possible.
Reports that are clear, well-documented, and reproducible on the first read reflect positively on you. Program owners remember researchers who make their triage process easy.
The Hackrate leaderboard ranks researchers by reputation, impact, and valid report count. Appearing on the leaderboard — especially in the top positions — makes you highly visible to program owners actively searching for researchers to invite.
The [Hackrate Elite Club](https://elite.hckrt.com) is reserved for the most trusted and accomplished researchers on the platform. Elite members receive priority consideration for all private program invitations. Working toward Elite status is the single most effective way to maximize your private program access over the long term.
# Understanding Program Scope Before You Start Testing
Source: https://hackrate-bb-app.mintlify.app/researchers/programs/understanding-scope
Read program target lists, tell in-scope from out-of-scope assets, understand Tier 1 vs. Tier 2 bounties, and follow policy rules before you start testing.
Scope defines the boundary of what you are legally and contractually authorized to test. It is not a suggestion — it is the agreement between you, the researcher, and the organization running the program. Testing outside scope puts you at legal risk, wastes your time on reports that will be rejected, and can result in your account being suspended. Understanding scope thoroughly before you write your first test request is one of the most important habits you can build as a researcher on Hackrate.
Every program on Hackrate defines its scope through a list of **targets** — specific assets that are either in scope (authorized for testing) or explicitly out of scope (prohibited). Targets also carry additional metadata like their type, tier, and bounty eligibility. This guide explains how to read and interpret all of it.
## How to find and read the target list
On any program detail page, the **Scope** section appears near the top of the page, above the company description and program rules. It shows the complete list of **in-scope targets** — assets that are currently active and have not been marked as out of scope.
Each target entry includes:
| Field | Meaning |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | The specific identifier for the asset — a domain, URL, app store listing name, IP range, or API base URL (e.g., `app.example.com`, `Example iOS App`) |
| **Type** | The category of the asset — Web Application, API, Mobile App (iOS or Android), Network, etc. |
| **Tier** | The importance classification of the target: **Tier 1** for primary/critical assets, **Tier 2** for secondary assets |
| **Bounty indicator** | Whether this target is eligible for monetary rewards, or recognition-only (even within a bounty program, individual targets may be VDP-only) |
## In scope vs. out of scope
Not every asset belonging to a company is authorized for testing, even if it shares the same domain or branding. Hackrate programs distinguish assets using two status flags:
A target is **in scope** when both of the following are true:
* **Currently active** — The target is accepting reports and enabled by the program owner.
* **Not marked out of scope** — The target has not been explicitly excluded from the program.
Only targets that satisfy both conditions appear in the Scope section of the program page. If a target shows up in the list, you have authorization to test it — within the program's rules.
A target is **out of scope** when it has been explicitly excluded by the program owner. Out-of-scope assets do **not** appear in the program's scope list — but the program policy will typically name them or describe the categories.
Common examples of out-of-scope targets:
* Third-party services and integrations not owned by the company
* Internal corporate infrastructure (employee email, HR systems)
* Assets specifically called out in the policy (e.g., `*.cdn.example.com`)
* Social engineering and phishing targets
* Denial-of-service and volumetric testing
* Rate limiting and brute-force enumeration issues (on many programs)
Submitting a vulnerability report for an out-of-scope target will result in the report being closed as **Out of Scope** immediately. It will not earn you reputation points or a bounty, and repeated out-of-scope submissions may affect your standing on the platform. Always verify that the specific asset you are testing appears in the program's target list before testing it.
A target that has been temporarily deactivated by the program owner will not appear in the public scope list. Inactive targets may become testable again in the future if the program owner re-enables them, but they are not currently accepting reports. Do not submit against an asset if you have reason to believe it is inactive — reports against inactive targets will be rejected.
## Tier 1 vs. Tier 2 targets
Programs that offer monetary bounties typically classify their targets into tiers. Tiers reflect the business importance of the asset and determine the bounty amounts associated with it.
Tier 1 targets are the organization's most critical and sensitive assets. This typically includes the main production application, the core API, the primary authentication service, and any system that handles sensitive user data or financial transactions. Vulnerabilities on Tier 1 targets earn the **highest bounty amounts** in the bounty table — finding a critical severity issue on a Tier 1 target represents the maximum payout the program offers.
Tier 2 targets are supporting or peripheral assets — marketing sites, staging environments shared with the scope, secondary APIs, or lower-risk services. Bounty amounts for Tier 2 targets are lower than Tier 1 across all severity levels. These targets are still fully in scope and worth testing, but the reward ceiling is lower.
The bounty table on each program's detail page shows the exact reward matrix:
| | Critical | High | Medium | Low |
| ---------- | -------------- | --------------- | --------------- | -------------- |
| **Tier 1** | Maximum payout | High payout | Moderate payout | Low payout |
| **Tier 2** | High payout | Moderate payout | Low payout | Minimal payout |
When you identify a vulnerability, check which tier the affected target belongs to before estimating your potential reward.
## Reading the program policy
The **Program Rules** section of the program detail page is as important as the target list. The policy extends and clarifies scope with rules that cannot be expressed as a simple list of targets. Always read the full policy before testing.
Key things the policy typically covers:
Most programs forbid specific testing methods regardless of whether the target is in scope. Common prohibitions include automated scanning tools, denial-of-service testing, brute-force attacks on authentication endpoints, and any testing that could cause data loss or service disruption. Some programs permit these techniques with prior written approval — check the policy carefully.
Even on in-scope targets, certain vulnerability classes may be excluded. Typical examples include issues that require physical access to a device, vulnerabilities in third-party components that the company does not control, missing HTTP security headers without demonstrated impact, theoretical vulnerabilities without a working proof of concept, and self-XSS.
Some programs specify when you may test. The **Testing Period** field on the program detail page may indicate allowed testing windows (e.g., business hours only, or 24/7). Respect these windows — testing outside permitted hours can violate the program agreement.
Programs typically require you to keep vulnerability details confidential until the issue is resolved. Public disclosure before the company has patched the vulnerability — even if the finding is legitimate — is a policy violation that can result in loss of your reward and account suspension. Follow the disclosure timeline specified in the policy.
Most well-run programs include a safe harbor clause that confirms you will not face legal action for good-faith security testing within the defined scope and rules. Read this carefully so you understand what protections you have and what behaviors are explicitly not covered.
## Using test credentials
Some programs provide **test credentials** — pre-created accounts, API keys, or test environment access details — to help you test without needing to create real accounts or interact with production user data.
If a program has credentials available, they appear in your **Credential Store** (accessible from your Profiles section after being accepted to the program). Using test credentials where available is strongly encouraged:
* It keeps your testing safely isolated from real user data
* It ensures you are testing an environment the program team expects to be tested
* It avoids policy violations that can arise from testing with real accounts
If a program offers test credentials for a specific target, always use them for that target. Testing with self-created or real user accounts when test credentials are available may be considered a policy violation, even if unintentional.
## Common mistakes to avoid
The scope list is exhaustive. `sub.example.com` being owned by the same company as `example.com` does not make it in scope. Only assets explicitly listed in the Scope section are authorized.
Program owners post announcements at the top of the program page when scope changes, when a known issue should be excluded, or when testing is temporarily paused. Always read the latest announcement before testing — scope can change at any time.
A target can be in scope but not eligible for a monetary bounty. Being in scope means you are authorized to test it; the bounty indicator on each target tells you whether a valid finding will earn a monetary reward or just reputation points.
If you find a vulnerability after an extended period away from a program, reload the program page and re-check the scope before submitting. Programs update their target lists over time, and an asset that was in scope six months ago may now be out of scope.
When in doubt about whether a specific asset, technique, or vulnerability class is in scope, **do not test it first and ask later**. Reach out to the program owner through the platform's messaging features before proceeding. Taking the time to ask is always better than submitting an out-of-scope report or — worse — conducting unauthorized testing.
# Quickstart: Find and Report Your First Vulnerability
Source: https://hackrate-bb-app.mintlify.app/researchers/quickstart
Get started on Hackrate: register, complete your profile, get verified, pick a program, review scope, and submit your first valid vulnerability report.
Getting started on Hackrate takes less than an hour of setup. This guide walks you through every step — from registering your account to submitting your first report — so you can begin hunting vulnerabilities with confidence and without accidentally violating program rules.
Navigate to [hckrt.com](https://www.hckrt.com) and register for a new account. You will need a valid email address. During registration, your account is provisioned as a researcher account, which gives you access to the program catalog, report submission, and the leaderboard.
Use an email address you check regularly. Program owners and the Hackrate team communicate with you through the platform and via email when your reports are updated.
Before you start hunting, take five minutes to fill out your profile at **Manage → Profile Settings**. A complete profile makes a strong impression on program owners reviewing your reports and considering you for private program invitations.
* **Nickname** — Choose carefully. Your nickname is public, shown on every report you submit, and displayed on the leaderboard. It can be up to 16 characters and must be unique across the platform. You cannot change it after it is set.
* **Name** — Your real name (used for identity verification and payment records, not displayed publicly by default).
* **About Me** — A short bio up to 500 characters. Describe your background, specialties, and experience. Markdown formatting is supported.
* **Country** — Your country of residence. This appears on the leaderboard and is required for identity verification.
* **Social links** — Add your GitHub, LinkedIn, Twitter/X, and personal website to help program owners evaluate your background.
* **Profile picture** — Upload a photo (JPEG, PNG, or GIF, max 5 MB) to make your profile recognizable.
Visit **Manage → Verification** to begin the ID verification process. You will need a government-issued identity document (passport, national ID card, or driving licence) and a proof of address document (bank statement or utility bill).
Identity verification is required to receive monetary bounty payouts. Your verification is reviewed by Hackrate's compliance team. The process typically takes one to two business days after you submit your documents. Start early so you are ready the moment your first bounty is awarded.
Once verified, a blue checkmark badge appears on your public profile. Verified researchers are more frequently considered for private program invitations.
Go to the Program Catalog (under the **Catalog** menu in your dashboard) to see all publicly available programs. Each program card shows the program name, whether it offers monetary bounties or recognition points only, the managed/unmanaged status, and the launch date.
Click **View program** on any card to open the full program detail page, which includes:
* **Scope** — the list of in-scope targets you are authorized to test
* **About company** — background on the organization running the program
* **Program Rules** — the policy governing what and how you may test
* **Bounty Table** — the reward amounts for each severity level and target tier (on bounty programs)
If you are new to the platform, start with a program that has many in-scope targets and a detailed program policy. Programs with more targets give you more surface area to find issues and more context to understand what the company considers a vulnerability.
If you receive an invitation to a private program, or if a program provides a public application link, you can apply through your researcher dashboard. Your application creates a request for the program owner to review. Once accepted, the program becomes visible in your dashboard and you can submit reports against it.
If you are just starting out, focus on public programs first. Build your reputation score through validated findings, and private program invitations will follow naturally.
Before you write a single line of test traffic, read the **Scope** section and **Program Rules** on the program detail page. Understand:
* Which targets are **in scope** (active, not marked as out of scope)
* Which assets are **explicitly out of scope** — reports against these will be closed immediately
* Any specific testing restrictions (e.g., no automated scanning, no denial-of-service testing, specific testing hours)
* The testing period, if the program specifies one
Submitting a report for an out-of-scope target wastes your time and reflects poorly on your profile. Always verify a target's scope status before testing it.
Test in-scope targets manually and methodically. Focus on the types of vulnerabilities most likely to affect the target type — for example, injection flaws and authentication weaknesses on web applications, and insecure data storage or API communication issues on mobile apps.
Start with lower severity findings to get familiar with the program's response style and validation process. Once you understand how the program team triages reports, you will be better positioned to write high-severity reports that are accepted on the first submission.
If the program provides test credentials (available in your **Credential Store** under the Profiles section), use them instead of targeting real user accounts. This keeps your testing safe, ethical, and within program rules.
When you find a valid vulnerability, navigate to the program page and click **Submit report**. Follow the report form carefully:
* **One issue per report** — Never bundle multiple vulnerabilities into a single report. Each finding needs its own title, description, and reproduction steps.
* **Provide clear reproduction steps** — The program owner must be able to reproduce the issue from your steps alone. Include screenshots, request/response captures, or a proof-of-concept where appropriate.
* **Select the correct severity** — Be honest about severity. Overstating severity damages your reputation; understating it may reduce your reward.
* **Describe the impact** — Explain what an attacker could achieve by exploiting the vulnerability, not just what the technical flaw is.
After submission, you will receive notifications as the program owner triages, validates, and resolves your report.
## Quick tips for new researchers
Always submit separate reports for separate vulnerabilities, even if they affect the same target. Bundled reports slow down triage and can result in lower rewards.
Program rules vary significantly. Some restrict the use of automated tools; others require you to contact the security team before testing certain endpoints. Skipping the policy is the fastest way to have a report rejected.
A track record of lower-severity, well-written reports is far more valuable than a single high-severity finding with poor documentation. Consistency earns invitations to private programs.
When a program provides test accounts through the Credential Store, always use them. Testing with real accounts — even your own — may violate program rules.
# Evidence Guidelines for Hackrate Vulnerability Reports
Source: https://hackrate-bb-app.mintlify.app/researchers/reports/evidence-guidelines
Learn what types of evidence to collect, how to upload files to your report, and what separates convincing proof-of-concept from weak documentation.
Evidence is the foundation of a credible vulnerability report. No matter how well-written your description is, a finding without proof is difficult for a triage team to verify — and a finding that cannot be verified is far more likely to be rejected, deprioritized, or delayed. Strong evidence makes your report reproducible by an independent reviewer from scratch, which is exactly what the triage team needs to confirm your finding and move it toward acceptance.
This page covers what types of evidence are accepted, how to upload files, what makes evidence compelling, and how to handle sensitive data responsibly.
***
## Why evidence is required
The pre-validation check that runs before every report submission requires **at least one evidence file**. If no evidence is attached, the form will not allow submission. This is intentional — it encourages researchers to document their work before filing, rather than submitting speculative reports and adding evidence later.
Beyond passing validation, good evidence:
* **Speeds up triage.** A clear screenshot or screen recording can confirm a finding in seconds. A text-only report may take many back-and-forth comment rounds to verify.
* **Prevents duplicate disputes.** Timestamped evidence establishes when you found the vulnerability.
* **Supports bounty decisions.** Reward amounts are often finalized after the impact is confirmed, and strong evidence directly supports a higher severity assessment.
* **Demonstrates professionalism.** Well-documented reports build your reputation as a researcher the program team can trust.
***
## Accepted evidence types
The most common evidence type. Capture the browser showing the vulnerability in action — the URL bar, any relevant request parameters, and the proof of exploitation should all be visible. Annotate with arrows or highlights if clarity helps.
Ideal for vulnerabilities that involve multi-step interactions, timing-dependent behavior, or client-side execution (XSS firing, CSRF in action, etc.). A short video demonstrating the full exploit flow is often more persuasive than a series of screenshots.
Captured traffic from a proxy tool (Burp Suite, OWASP ZAP, etc.) exported as a text file. Include the full request and the server's response. For injection vulnerabilities, show the payload in the request and the evidence of successful execution in the response.
A script, exploit module, or minimal reproducible example that triggers the vulnerability. PoC code is especially valuable for authentication bypasses, logic flaws, and API vulnerabilities. Include comments explaining each step.
Application error logs, stack traces, or debug output that confirm unexpected behavior or information disclosure. Particularly useful for server-side findings.
If the vulnerability is in a publicly available source repository or client-side JavaScript, a snippet showing the vulnerable code path alongside the exploit helps triagers locate and fix the root cause faster.
***
## Accepted file formats and size limits
The evidence uploader accepts the following file types:
| Category | Formats |
| ----------- | -------------------------------------- |
| Images | `.jpg`, `.jpeg`, `.png`, `.gif` |
| Videos | `.mp4`, `.avi`, `.flv`, `.wmv`, `.mov` |
| Text & code | `.txt`, `.md`, `.mdx` |
**Maximum file size:** 150 MB per file.
You can upload multiple evidence files to a single report, either during initial submission or afterward via the **Upload new evidence** panel on your report's detail page. You can add evidence to a report after submission as long as the report is still open.
***
## How to upload evidence
### During report creation
Have all evidence files ready on your machine before you start filling out the report. The uploader appears at the bottom of the form.
Scroll to the **Upload Evidences** section at the bottom of the report form. The upload area supports drag-and-drop or click-to-browse.
Drag your files into the drop zone or click to open the file picker. Files are uploaded via a secure presigned URL directly to storage — they never leave Hackrate's infrastructure.
Each file shows an upload progress indicator. Wait for all files to finish uploading before clicking **Submit**. Partially uploaded files will not be attached to the report.
### After submission
You can add additional evidence to an existing report from the report's detail page at any time while the report is open:
1. Navigate to **My Reports** and open the relevant report.
2. Scroll to the **Upload new evidence** panel on the right side.
3. Drop or select a single file. (Evidence is added one file at a time after submission.)
4. Click **Upload** to finalize. A comment is automatically added to the report's timeline noting the new upload.
***
## What makes evidence compelling
Not all evidence is equal. Triagers review dozens of reports — clear, well-organized evidence is noticed and appreciated.
* Show the full browser window including the URL bar so the endpoint is clearly visible
* If demonstrating XSS or injection, include both the payload in the input and the proof of execution (alert box, exfiltrated data, reflected content)
* For IDOR or access control issues, show the account context (logged in as User A) and the unauthorized access (data belonging to User B)
* Annotate with arrows, boxes, or highlights to draw attention to the key part of the image
* Use a consistent naming convention: `01-login-page.png`, `02-payload-injected.png`, `03-xss-fired.png`
* Keep recordings short and focused — under 3 minutes if possible
* Narrate or annotate key steps in the recording itself (captions, on-screen text)
* Start from a clean, unauthenticated (or freshly authenticated) state to show the full attack chain
* Include a brief setup section showing that the vulnerability is not already known/pre-configured
* Export the full request including all headers, not just the body
* Include the complete server response — status code, headers, and body
* Redact your own authentication tokens from evidence if not needed for context (replace with `[REDACTED]`)
* For multi-step exploits, include the full sequence in order with clear labels
* Include comments explaining what each section does
* Document prerequisites (target URL, required session tokens, environment setup)
* Keep it minimal — a 20-line PoC is more trusted than a 2,000-line framework
* Test your PoC before including it to verify it actually works against the target
***
## Handling sensitive data in evidence
When you find a vulnerability that exposes real user data, you face a responsibility to minimize the harm caused by your own research.
**Do not capture, store, or include real user data (PII, credentials, financial data) in your evidence files unless strictly necessary to demonstrate the vulnerability.**
Follow these practices:
* **Use your own test accounts.** When demonstrating data access, use accounts you control. If you must demonstrate cross-account access, use a second test account you own rather than accessing real user data.
* **Blur or redact real data in screenshots.** If real data is visible in a screenshot, blur it before uploading. The presence of the data field is usually enough — the actual values rarely need to be readable.
* **For mass data exposure, demonstrate scope without extracting.** A screenshot showing the first row of a database dump with the rest blurred, combined with a clear description of the structure, is sufficient. You do not need to include hundreds of rows.
* **Delete local copies.** Once uploaded to your report, delete any locally stored copies of data that contains real user information.
Responsible handling of sensitive data is part of the ethical standards all Hackrate researchers are expected to uphold.
***
## File validation
After you upload a file, it goes through an automated validation process. Each file shows one of three states in your report:
| Status | Meaning |
| ----------- | -------------------------------------------------------------------------------------------- |
| **Pending** | The file has been uploaded and is queued for validation |
| **Valid** | The file passed validation and can be downloaded by triagers |
| **Invalid** | The file failed validation (e.g., unsupported format, corrupted file) — upload a replacement |
If a file shows **Invalid**, upload a replacement before submitting or following up with the triage team. Triagers cannot access invalid files.
***
## Common evidence mistakes to avoid
Reports without evidence are blocked by pre-validation. Even a single screenshot of the vulnerability in action is better than nothing.
A cropped screenshot that shows a result but not the URL, account context, or payload makes verification much harder.
Including actual names, emails, or financial data in screenshots or dumps is a serious ethical violation. Blur or redact it.
Do not link to external services (Google Drive, Dropbox, Imgur) for evidence. Upload directly to the report. External links expire and cannot be archived.
Evidence that shows something different from what the Description says creates confusion. Make sure your files match the steps you describe.
Untested PoC that doesn't work undermines the entire report. Run it at least once against the target before uploading.
# Understanding Every Report Status on Hackrate Platform
Source: https://hackrate-bb-app.mintlify.app/researchers/reports/report-statuses
A complete reference of all 14 report statuses on Hackrate — what each means for you as a researcher, what action to take, and when bounties are awarded.
Every report you submit on Hackrate moves through a defined set of statuses that reflect where it is in the triage and remediation lifecycle. Knowing what each status means — and what you should or should not do at each stage — helps you manage your pipeline effectively, respond to triagers promptly, and understand when to expect a bounty decision.
You can see the status of all your reports at any time by navigating to **My Reports** from the main navigation. The table shows each report's ID, title, program, creation date, last activity date, status, and severity. You can sort by any column and filter by status or program.
***
## Status overview
Statuses fall into two categories:
* **Open** — the report is active and still being worked on by you and/or the triage team
* **Closed** — the report has reached a terminal state; no further triage action is expected
You can always add evidence or comments to an open report. Once a report is closed, normal editing is no longer available, but you can still use the comment thread to communicate with the triage team if you have questions.
***
## Open statuses
These statuses indicate your report is in an active state. Pay close attention to them — especially **Needs More Info**, which requires a response from you.
**Your report was saved but not yet formally submitted.**
This status appears when a report has been created but not completed. If you see this status, it means the report did not go through the full submission process. Return to the report and complete all required fields, then submit it properly so the triage team can review it.
**Your report was submitted successfully and is awaiting triage.**
This is the first active status after a successful submission. The company's triage team has been notified and will begin reviewing your report. No action is required from you at this point — the ball is in the triage team's court.
Depending on program volume, initial triage can take anywhere from a few days to a couple of weeks. Be patient and avoid sending follow-up messages demanding a faster response.
**Your report came in via an embedded report form and is pending initial assignment.**
This status is specific to reports submitted through a program's embedded form rather than the standard Hackrate platform. It functions similarly to **New** — the report is awaiting initial review and assignment to a triager. No action is required from you.
**The company confirmed your finding is valid and is actively working on a fix.**
Great news — your report has been triaged, the vulnerability has been verified, and the program team considers it a real security issue. The team is now working on remediation. You may receive updates as the fix progresses.
A bounty decision is typically made before or when the status moves to **Resolved**. In some programs, a bounty may be awarded while the report is still in Accepted status.
**The triage team needs additional details from you to continue their review.**
This is the most action-critical open status. Check the **Timeline** (comment thread) on your report immediately — the triager has left a specific question or request. Common requests include:
* Clarification on reproduction steps
* Additional evidence (different browser, authenticated session, specific account type)
* Confirmation that the issue still exists on the latest version
* Explanation of the attack scenario or impact
**Respond as soon as possible.** Reports left in Needs More Info without a response from you may eventually be closed as Not Accepted (Invalid) or Not Accepted (Self-Closed). A timely, detailed response keeps the triage process moving and shows professionalism.
***
## Closed statuses
Closed statuses represent the final outcome of a report. Understanding the distinction between them helps you learn from each submission and improve future reports.
**The vulnerability has been fixed by the company.**
This is the ideal outcome for a security finding. The program team has patched or mitigated the vulnerability you reported. If a bounty is applicable for this finding, it is typically awarded when the report reaches Resolved status (or sometimes when it first reaches Accepted). Check the **Bounty** field on your report detail page to see if a payment has been recorded.
**The company is aware of the vulnerability but has decided to accept the risk rather than fix it.**
This is a legitimate business decision. The company reviewed your finding, considered the effort and impact of remediation, and concluded that the risk is within their acceptable threshold. This does not mean your report was wrong — the finding was valid. A bounty may or may not be awarded depending on the program's policies. Check the comment thread for context on the decision.
**Your report was a duplicate of an earlier submission, but it was recognized as high quality.**
Another researcher submitted the same vulnerability before you, so the first reporter is the primary recipient of any bounty. However, the triage team has flagged your report as well-written, well-evidenced, or otherwise noteworthy. You may receive recognition (such as acknowledgment in the hall of fame) even without a full bounty payout. This status is a signal that your reporting methodology is strong — keep it up.
**Your finding is noted but is not classified as an exploitable security risk.**
The triage team reviewed your report and determined that, while the behavior you observed may be unintended or suboptimal, it does not represent a real security vulnerability under their threat model. This might happen if the "vulnerability" has no realistic attack path, requires impossible attacker preconditions, or is a known and accepted design trade-off. No bounty is awarded for Informative findings. Consider reviewing the program's scope and out-of-scope descriptions before testing similar areas.
**This vulnerability was already reported by another researcher.**
A report with the same root cause and affected component was submitted before yours. Only the first reporter of a valid vulnerability is eligible for a bounty. The **Duplicate of** field on your report detail page may reference the original report ID.
If you believe the duplicate marking is incorrect — for example, your report covers a different attack path or a different affected component — leave a comment explaining the distinction and ask the triage team to reconsider.
**The report does not demonstrate a real vulnerability.**
The triage team reviewed your submission and could not reproduce the issue, or determined the behavior is intentional and not a security concern. Check the comment thread for a specific explanation. Common reasons include:
* Steps could not be reproduced as written
* The behavior is a known and accepted design decision
* The reported issue requires attacker prerequisites that are equivalent to the damage (e.g., already having admin access)
* The finding is theoretical with no demonstrated exploit path
Review the feedback, improve your methodology, and try again on a future finding.
**The report was low quality, automated, or did not follow program rules.**
This outcome is reserved for reports that show clear signs of automated scanning output, copy-pasted CVE descriptions without program-specific verification, or submissions that disregard the program's guidelines. To avoid this outcome, always test manually, verify findings in the specific program context, and read the program rules before submitting.
**The vulnerability was in an asset not covered by the program.**
The target you reported against is not listed as an in-scope asset, or the asset type is explicitly excluded in the program's scope table. Always verify scope before testing. If you believe the target should be in scope, you can reach out to the program team, but do not resubmit without clarification.
**The report was closed at your own request, or was closed without a resolution after inactivity.**
You can self-close a report that is in **Pre-submission**, **New**, or **New – To Review** status from the Actions section of the report detail page. This is useful if you realize you submitted a report in error, found a duplicate yourself, or no longer want to pursue the finding. Reports can also be moved to this status after extended periods without a researcher response to a Needs More Info request.
***
## Full status reference table
| Status | Type | What it means for you |
| --------------------------- | ------ | ---------------------------------------------------------- |
| Pre-submission | Open | Draft saved — complete and resubmit |
| New | Open | Submitted, awaiting triage — no action needed |
| Accepted | Open | Finding confirmed valid — fix in progress |
| Needs More Info | Open | **Respond in the comment thread promptly** |
| New – To Review | Open | Embedded form submission awaiting assignment |
| Resolved | Closed | Vulnerability fixed; bounty typically awarded here |
| Informative | Closed | Noted but not a security risk; no bounty |
| Duplicate | Closed | Already reported; no bounty for you |
| Good Quality Duplicate | Closed | Duplicate but recognized for quality; possible recognition |
| Not Accepted (Invalid) | Closed | Could not verify; no bounty |
| Not Accepted (Spam) | Closed | Low quality or violated rules; no bounty |
| Not Accepted (Out of Scope) | Closed | Asset not covered by program; no bounty |
| Not Accepted (Self-Closed) | Closed | Closed without resolution |
| Accepted Risk | Closed | Valid but company chose not to fix it |
***
## Bounty timing
Bounties are awarded by the program team and are not automatic. Here is the general timing:
* **Accepted → Resolved:** Most bounties are paid when the status moves from Accepted to Resolved, confirming the fix is in place.
* **Accepted (while open):** Some programs award bounties as soon as the finding is confirmed valid, before the fix is deployed.
* **Accepted Risk:** The program may choose to award a bounty even though the vulnerability will not be fixed, depending on its policies.
* **Duplicate:** Only the first reporter receives the bounty. If you were marked as **Good Quality Duplicate**, you may receive partial recognition or acknowledgment but not the primary reward.
* **All other closed statuses:** No bounty is awarded.
Check the program's **Rewards** table for details on when and how bounties are paid, as policies differ between programs.
***
## What to do — and what not to do
This is the most important action you can take. Read the triager's request carefully, gather the requested evidence or clarification, and respond clearly in the comment thread. Fast, complete responses are the single biggest factor in keeping a report on track.
If you find additional proof that strengthens your report, upload it via the **Upload new evidence** panel. More evidence is almost always better.
Sending repeated comments asking for a status update does not speed up the review process and reflects poorly on you as a researcher. Allow the program's stated response time before following up once.
Reports with Open status must not be shared publicly. The platform displays a reminder of this on every open report. Public disclosure before the vulnerability is resolved can harm users and result in your removal from the program.
***
## Tracking your reports
Your **My Reports** inbox shows all the reports you have submitted, across all programs. You can:
* **Sort** by ID, title, program, creation date, last activity, status, or severity
* **Search** by keyword to find a specific report quickly
* **Click any report** to open the full detail view, including the comment thread, evidence files, and current status
The **Last Activity** column shows the timestamp of the most recent comment on a report — useful for spotting reports that have had recent triage activity and may need your attention.
# Severity Levels and CVSS Scoring Guide for Hackrate
Source: https://hackrate-bb-app.mintlify.app/researchers/reports/severity-cvss
Understand how Hackrate's five severity tiers work, how to use the built-in CVSS calculator, and how your rating affects bounty amounts.
Severity is one of the most important decisions you make when filing a report. It shapes how quickly the triage team prioritizes your submission, determines the bounty tier your finding falls into, and signals to the company the urgency of remediation. Getting severity right — not too high, not too low — reflects well on your judgment and builds long-term trust with program owners.
This page explains each severity level, how the CVSS calculator works, how the two relate to each other, and what triagers look at when they reassess your rating.
***
## Severity levels
Hackrate uses five severity levels. Four of them are available to self-assign when you submit a report; the fifth is reserved for exceptional cases.
Minor issues with limited real-world impact. Often requires unusual conditions or significant attacker access that is already equivalent to the damage caused. Examples: open redirects, low-impact CSRF affecting only the current user's own data, missing security headers with no exploitable consequence.
Moderate risk. The vulnerability is real and exploitable, but requires specific conditions such as user interaction, a particular account type, or a non-default configuration. Examples: reflected XSS requiring a crafted link, CSRF with meaningful but limited impact on the victim's account.
Significant risk that can lead to data exposure, privilege escalation, or account takeover. Authentication bypass on non-critical but sensitive systems, stored XSS that fires without user interaction, and access to other users' data are typical High findings.
Severe vulnerability that can lead to full system compromise, mass data leakage, or complete loss of confidentiality, integrity, or availability for the affected system. Includes SQL injection with read/write access, remote code execution, full database dumps, and access to all customer personal data.
Reserved for extraordinary findings — typically RCE or equivalent impact on core Hackrate infrastructure, or a chained exploit with catastrophic cross-tenant consequences. **Do not self-assign Exceptional.** This level is assigned by the program team after review.
### Real-world examples by severity
* Remote code execution on the application server
* SQL injection with full database read and write access
* Access to all customer personal details (PII dump)
* Authentication bypass granting admin access without credentials
* Full takeover of any user account without interaction
* Stored XSS that executes without any victim interaction
* Privilege escalation from a regular user to an admin role
* Insecure direct object reference exposing another user's sensitive data
* Authentication bypass on important but non-core systems
* Reflected XSS requiring a victim to click a crafted link
* CSRF that changes security settings (email, password) with significant but scoped impact
* Server-side request forgery (SSRF) with limited internal access
* Broken access control that exposes partial user data
* Open redirect to an external domain (no data exposure)
* CSRF affecting low-value, easily reversible actions
* Missing `Secure` or `HttpOnly` cookie flags without a practical attack path
* Clickjacking on pages that do not perform sensitive actions
***
## What is CVSS and why does it matter?
**CVSS (Common Vulnerability Scoring System)** is an industry-standard framework for rating the severity of security vulnerabilities. It produces a numeric score between 0.0 and 10.0 based on a set of defined metrics describing how a vulnerability is exploited and what the consequences are.
Hackrate uses CVSS scores alongside severity labels to give the triage team a quantitative reference point. The CVSS vector string you generate is stored with your report and is visible to reviewers.
### CVSS metrics overview
| Metric | What it measures |
| ---------------------------- | ---------------------------------------------------------------------------------------- |
| **Attack Vector (AV)** | How the attacker reaches the vulnerable component: Network, Adjacent, Local, or Physical |
| **Attack Complexity (AC)** | Whether special conditions beyond the attacker's control are required: Low or High |
| **Privileges Required (PR)** | What level of privilege the attacker needs: None, Low, or High |
| **User Interaction (UI)** | Whether a human victim must take an action: None or Required |
| Metric | What it measures |
| ----------------------- | ----------------------------------------------------------------------------------------------- |
| **Scope (S)** | Whether the vulnerability can affect components beyond the vulnerable one: Unchanged or Changed |
| **Confidentiality (C)** | Impact on data secrecy: None, Low, or High |
| **Integrity (I)** | Impact on data trustworthiness: None, Low, or High |
| **Availability (A)** | Impact on system availability: None, Low, or High |
***
## Using the built-in CVSS calculator
The report submission form includes a **CVSS calculator panel** directly on the page — you do not need any external tools. To use it:
On the report form, find the **CVSS Calculator** field below the Target selector. The interactive calculator is embedded inline.
Click through each metric group and select the value that best describes your finding. The calculator updates the score and vector string in real time as you make selections.
Check the overall numeric score before moving on. Use the guidance below to verify it aligns with the severity level you intend to select.
Choose the Severity dropdown value that corresponds to your CVSS score range. The score is automatically saved to your report — you do not need to copy it anywhere.
The CVSS vector string and numeric score are saved as part of your report. Triagers use this data when reviewing your severity self-assessment, so take time to set each metric thoughtfully.
***
## Mapping CVSS scores to severity
Use this table as a guide when deciding which severity label to select. Note that CVSS score ranges are guidelines, not strict rules — the actual business impact of a finding may cause a triager to adjust severity up or down.
| Severity | Typical CVSS range | Notes |
| --------------- | ------------------ | ---------------------------------------------------------- |
| **Low** | 0.1 – 3.9 | Limited exploitability or minimal impact |
| **Medium** | 4.0 – 6.9 | Exploitable but requires conditions; partial impact |
| **High** | 7.0 – 8.9 | Network-reachable, low complexity, significant impact |
| **Critical** | 9.0 – 10.0 | High impact across C/I/A with low barriers to exploitation |
| **Exceptional** | Typically 9.5+ | Assigned by program team only |
***
## How severity affects bounty amounts
Bounty amounts on Hackrate are impact-based and structured around both severity and the tier of the target you reported against. Higher-tier targets that form the core of the program's product command higher rewards.
The general bounty priority order is:
1. **Tier 1 Critical** — highest possible reward
2. **Tier 1 High**
3. **Tier 2 Critical**
4. **Tier 1 Medium**
5. **Tier 2 High**
6. …and so on down the tier and severity matrix
Bounty amounts are set by the program owner and vary between programs. Check the program's **Rewards** table for the exact payout structure before testing.
***
## How triage reassesses your severity
After you submit, the company's triage team reviews your CVSS vector and severity label independently. Severity adjustments during triage are normal and expected — they are not automatically a negative signal about your work.
Common reasons for a downgrade:
* The vulnerability requires significantly more attacker access than indicated (e.g., PR: None set when admin credentials are actually required)
* The impact is more limited in the program's specific architecture than a generic CVSS score would suggest
* The finding is already mitigated by a compensating control not visible from the outside
Common reasons for an upgrade:
* The triage team identifies a more severe exploit path than you described
* The finding has broader blast radius than the initial assessment suggested
Intentionally inflating CVSS scores (e.g., setting Attack Vector to Network and Privileges Required to None for a vulnerability that actually requires local access and admin rights) is considered poor practice and can damage your reputation with the program team.
***
## Quick self-assessment checklist
Before finalizing your severity selection, ask yourself:
* Can this be exploited remotely over the network, or does it require local access?
* Does exploitation require any special privileges or user interaction?
* What is the worst realistic outcome if someone exploited this right now?
* Does the impact affect a single user, a subset of users, or all users?
* Is there a compensating control (rate limiting, WAF, MFA) that reduces real-world exploitability?
Answering these honestly will guide you to a defensible severity rating that stands up to triage scrutiny.
# How to Write a High-Quality Vulnerability Report on Hackrate
Source: https://hackrate-bb-app.mintlify.app/researchers/reports/writing-a-report
A step-by-step guide to crafting clear, complete vulnerability reports on Hackrate that maximize your chances of acceptance and reward.
Every great bug bounty payout starts with a great report. Even the most critical vulnerability can be rejected — or downgraded — if it is poorly written, lacks evidence, or fails to explain the real-world impact. This guide walks you through how to navigate to the report form, fill in every field correctly, and submit work that triagers can act on immediately.
**One issue per report.** Submit each security issue as a separate report. The only exception is when multiple vulnerabilities form a single, inseparable exploit chain — in that case you may combine them in one report and clearly explain how each step builds on the previous.
## Before you start
Make sure you have:
* **Confirmed the target is in scope.** Check the program's scope table before testing. Reports targeting out-of-scope assets will be closed as **Not Accepted (Out of Scope)**.
* **Collected your evidence.** Screenshots, screen recordings, HTTP request/response logs, or PoC code should be ready before you open the form.
* **Verified reproducibility.** Run through the full reproduction path at least once from scratch so your steps are accurate.
***
## Step-by-step: submitting a report
Open the program page you want to report to. You must be an approved participant in the program — private programs require an accepted application before the Submit Report button is visible.
On the program page, click the **Submit Report** button. This opens the report creation form scoped to that program.
Complete every field described in the section below. The platform will run pre-validation checks before accepting your submission — incomplete reports will be blocked at this stage.
Use the **Upload Evidences** panel at the bottom of the form to drag and drop your files. You need at least one evidence file for the report to pass pre-validation.
Re-read your report before clicking **Submit**. Once submitted, the report enters **New** status and the company triage team is notified.
***
## Field reference
### Report Name
The title of your report — up to 127 characters. A good title is specific enough that a triager immediately understands what type of vulnerability it is and where it lives.
`Stored XSS in profile bio field allows session hijacking`
`XSS found` or `Security bug`
Write the vulnerability class, the affected component, and the primary impact. Avoid vague titles like "Multiple issues" — that is a signal to triagers that the report may violate the one-issue rule.
***
### Target
Select the affected asset from the program's in-scope target list. Only active, in-scope targets are shown. If the asset you tested is not in the list, it is either out of scope or not yet included in the program — do not submit reports against unlisted assets.
***
### CVSS Score
The report form includes a **built-in CVSS calculator**. Use it to score the vulnerability by setting each metric (Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality, Integrity, Availability). The calculator outputs a numeric score and a vector string that are automatically attached to your report.
Be honest with your CVSS assessment. The triage team will re-evaluate the score independently. Artificially inflating CVSS to boost severity is a common mistake that damages your credibility with reviewers.
For guidance on matching CVSS scores to severity levels, see [Severity & CVSS](/researchers/reports/severity-cvss).
***
### Severity
Select one of the following levels from the dropdown:
| Severity | When to use it |
| --------------- | ------------------------------------------------------------------------------------------------------------------ |
| **Low** | Minor issues with limited real-world impact |
| **Medium** | Moderate risk; requires certain conditions to exploit |
| **High** | Significant risk; data exposure or privilege escalation possible |
| **Critical** | Severe; can lead to full system compromise or mass data leak |
| **Exceptional** | Reserved for extraordinary findings (e.g., RCE on core infrastructure) — do not self-assign unless you are certain |
The company may adjust your chosen severity during triage. This is normal and not a penalty.
***
### Summary
A concise executive summary — a few sentences that capture *what* the vulnerability is and *why* it matters. Write for a non-specialist reader: a manager or legal reviewer should be able to understand the summary without reading the full technical description.
**Markdown is supported.** You can use bold text, inline code, and short bullet lists if they improve clarity.
* State the vulnerability class upfront (e.g., "A stored cross-site scripting vulnerability exists in…")
* Name the affected component or endpoint
* Mention the highest-impact consequence in one sentence
* Keep it under 10 sentences — save technical depth for the Description field
* Avoid copy-pasting from OWASP or CVE descriptions; write in your own words based on what you observed
***
### Description
The full technical write-up of the vulnerability. This section must include **step-by-step reproduction instructions** that an independent researcher could follow without any prior context.
**Markdown is supported.** Use numbered lists for reproduction steps, code blocks for payloads and HTTP requests, and headings to separate logical sections.
A strong Description answers these questions:
1. What is the root cause of the vulnerability?
2. Exactly how do you reproduce it? (Numbered steps, specific URLs, parameters, payloads)
3. What environment or configuration is required? (Authenticated vs. unauthenticated, specific role, etc.)
4. What did you observe that proves the vulnerability exists? (Error messages, unexpected responses, etc.)
```
## Vulnerability
[One sentence description of the root cause]
## Prerequisites
- [Account type / role required]
- [Any special configuration or state needed]
## Steps to Reproduce
1. Navigate to [URL]
2. [Action taken]
3. Observe [result that demonstrates the bug]
## Observed Behavior
[What happens, including any payloads, responses, or error messages]
## Expected Behavior
[What should happen instead]
```
***
### Impact
Describe what a malicious actor could realistically do if they exploited this vulnerability. Be specific — "an attacker could read other users' private messages" is far stronger than "there is a data exposure risk."
**Markdown is supported.** Consider bullet points when there are multiple distinct impact scenarios.
Good impact statements cover:
* **Who is affected** (single user, all users, administrators, the organization itself)
* **What data or actions are at risk** (PII, financial records, authentication tokens, arbitrary code execution)
* **Realistic attack scenarios** (e.g., phishing amplification, session takeover, lateral movement)
Avoid overstating impact. Claiming that a low-severity reflected XSS "could lead to full database compromise" without a realistic chain is a fast path to a downgrade or rejection.
***
### Vulnerability Type (CAPEC)
Select the most appropriate CAPEC (Common Attack Pattern Enumeration and Classification) category from the dropdown. This helps the triage team categorize and route the report correctly.
***
### CWE Type
Select the CWE (Common Weakness Enumeration) identifier that best matches the underlying root cause. CWE and CAPEC are complementary:
* **CWE** describes the *weakness* in the code (e.g., CWE-79: Improper Neutralization of Input During Web Page Generation)
* **CAPEC** describes the *attack pattern* (e.g., CAPEC-86: XSS Through HTTP Request Headers)
You can provide either or both. If you are unsure, CWE is more commonly used in vulnerability classification.
***
### CVE
If a CVE identifier has already been assigned to this vulnerability (e.g., because it affects a third-party component), enter it here. This field is optional — leave it blank if no CVE exists.
***
### Evidences
Upload your proof-of-concept files using the evidence uploader. The platform accepts screenshots, videos, PoC code files, and text files up to **150 MB per file**. Accepted formats include `.jpg`, `.jpeg`, `.png`, `.gif`, `.txt`, `.md`, `.mp4`, `.avi`, `.flv`, `.wmv`, `.mov`.
**At least one evidence file is required.** Reports without evidence will be blocked by pre-validation before submission.
For detailed guidance on what makes good evidence and how to handle sensitive findings, see [Evidence Guidelines](/researchers/reports/evidence-guidelines).
***
## Common mistakes to avoid
Without clear steps, triagers cannot verify the issue. Always write steps you could hand to a stranger and have them reproduce the bug.
Bundle separate issues and the whole report may be rejected. One issue, one report — except for genuine exploit chains.
"This could be dangerous" is not impact. Describe who is affected, what is at risk, and how.
Reports without a screenshot or PoC are difficult to verify and are more likely to be rejected or deprioritized.
Always verify the target is listed and active in the program scope before submitting.
Self-assigning Critical to every report signals poor judgment. Accurate severity self-assessments build reviewer trust.
***
## Markdown support
The **Summary**, **Description**, and **Impact** fields all support [Markdown syntax](https://www.markdownguide.org/cheat-sheet/). Use it to format code blocks, create numbered lists for reproduction steps, bold key terms, and add inline code for payloads or parameter names. Well-formatted reports are faster to review and make a stronger impression.
***
## After you submit
Once you click **Submit**, your report's status changes to **New**. The company triage team receives a notification and will begin reviewing your report. You will be notified when the status changes.
If the team needs more information, the status will move to **Needs More Info** — check the report's comment thread and respond promptly. For a full explanation of every possible status, see [Report Statuses](/researchers/reports/report-statuses).
# Understanding Hackrate Bounties, Bonuses, and Awards
Source: https://hackrate-bb-app.mintlify.app/researchers/rewards/bounties
Learn how monetary bounties are calculated, when they are paid, how bonus rewards work, and what non-monetary awards you can earn on Hackrate.
When a company accepts your vulnerability report on Hackrate, you are eligible to receive a bounty — a monetary reward that reflects the real-world value of your finding. The bounty amount is set by the company running the program and depends on both the severity of the vulnerability and the tier of the target you discovered it in. Understanding how this system works helps you prioritize your research and maximize what you earn.
## How bounties are calculated
Each bug bounty program defines its own payout table. The two main factors that determine your bounty are:
* **Severity** — how critical the vulnerability is, rated across levels such as Informational, Low, Medium, High, and Critical.
* **Target tier** — the relative importance of the affected asset within the program (for example, a core production API typically falls in a higher tier than a staging environment or a marketing subdomain).
Higher severity combined with a higher-tier target produces the largest payouts. When you submit a report, you select the severity you believe applies. The company may adjust this rating during triage; the final bounty is based on their determination.
Programs display their bounty table in the program brief. Always review it before you start testing so you know what payouts to expect for each combination of severity and target tier.
## Bonus payments
In addition to the standard bounty, a program may award a **bonus** on top of your base payout. Bonuses are discretionary and are typically granted when a finding is especially impactful, demonstrates exceptional research quality, or comes with a particularly thorough write-up and proof of concept. A bonus is issued as a separate bounty record and appears as its own reward entry in your account activity log alongside the original bounty.
To maximize your chances of receiving a bonus, include a clear reproduction path, a CVSS score breakdown, and a well-reasoned impact statement in your report.
## When bounties are paid
Bounties are awarded by the company after your report reaches **Accepted** or **Resolved** status. The timeline looks like this:
Write up your finding and submit it through the program's report form. The report enters a pending or triaging state.
The security team reviews your report, may ask clarifying questions, and confirms reproducibility. Severity may be adjusted at this stage.
Once the company accepts the validity of your finding or marks it resolved, the report moves to a qualifying status. This is the trigger for a bounty award.
The company sets the bounty amount. You receive a notification and the reward appears in your account activity log.
Your payment is processed to the method you have configured in your account. Make sure your payment information is up to date before this step.
You must have valid payment information saved in your account settings before a bounty can be paid out. If your payment details are missing or incomplete, the transfer cannot be initiated. See [Payment Settings](/researchers/account/payment-settings) to set up your details.
## Currency
Programs on Hackrate denominate their bounties in either **USD (\$)** or **EUR (€)**. The currency used is set by the company and is shown in the program brief. You will be paid in the program's designated currency, so factor this into your expectations when participating in programs across different regions.
## Non-monetary awards
Not every recognition on Hackrate takes the form of a cash payout. Companies can issue **Awards** — named acknowledgements tied to a specific program and linked to your profile. Awards are visible on your public hacker profile and contribute to your standing on the platform.
A thanks award is a lightweight acknowledgement from a company — often given for a report that was informational or out of scope but still considered valuable feedback.
Program-specific awards carry the name chosen by the company and can represent milestones such as "First Blood," "Most Creative Finding," or program-specific recognition tiers.
Awards appear on your profile alongside your reports and reputation score, helping demonstrate your track record to programs that review researchers before granting access.
## Your shareable bounty page
Each bounty you earn has a unique, publicly shareable page. You can access it from your account activity log by clicking the bounty entry. This page displays:
* Your nickname and profile picture
* The bounty amount and currency
* The name of the program (or "a private program" if the program is private)
* The date the bounty was awarded
Share your bounty page on social media or your portfolio to celebrate your earnings and demonstrate your work to the security community. The page includes open graph metadata optimized for Twitter and LinkedIn.
## Setting up payment information
Before your first bounty can be transferred to you, you need to configure your payment details. Navigate to **Account Settings → Payment** to add or update your information. See [Payment Settings](/researchers/account/payment-settings) for a full walkthrough, including the identity verification requirement that applies to first payouts.
# Hacktivity Feed: Public Security Disclosure on Hackrate
Source: https://hackrate-bb-app.mintlify.app/researchers/rewards/hacktivity
Understand how the Hackrate Hacktivity feed works, what information is shared in disclosed reports, and why published findings build your reputation.
Hacktivity is the platform-wide public feed of disclosed security findings. When a company resolves a vulnerability and chooses to share it publicly, the report becomes a Hacktivity entry — a permanent, indexed record of your research that anyone can read. It serves as the platform's transparency layer, showing the security community what kinds of vulnerabilities are being found and fixed across participating programs.
## How a finding gets published
The decision to publish a report to Hacktivity rests entirely with the company, not the researcher. After a report reaches a resolved or accepted status, the company can submit it for publication. Platform administrators review and approve the submission before it goes live on the public feed.
Your report reaches a closing status — such as Resolved or Accepted Risk — after the company has addressed or acknowledged the finding.
The company opts to share the report publicly. They may add a Team Summary, adjust visible fields, and choose what details to include in the disclosure.
Hackrate administrators review the submission to ensure no sensitive details are inadvertently exposed before publication.
The entry becomes visible on the public Hacktivity feed and receives a permanent, shareable detail page that you can link to from your portfolio.
You cannot self-publish a report to Hacktivity. Disclosure is always initiated by the company after resolution. If you want your finding disclosed, discuss it with the program team once the issue is fully resolved.
## What each Hacktivity entry shows
The feed lists all published entries in reverse-chronological order. Each card on the feed displays:
| Field | Description |
| -------------------- | ------------------------------------------------------------------------- |
| **Title** | The title of the finding as published |
| **Program** | The name of the company or program that the report belongs to |
| **Author** | Your researcher nickname, linked to your public profile |
| **Severity** | The severity level assigned to the finding (e.g., Critical, High, Medium) |
| **Status** | The final report status at time of disclosure |
| **Publication date** | When the entry was published to the feed |
| **Summary** | A short description of the finding |
## Viewing full disclosure details
Clicking the **Details** button on any feed entry takes you to the full disclosure page for that finding. This page includes:
The full detail view shows the program name, affected target and its tier, severity, CVSS score (if provided), CVE number (if assigned), affected versions, and CWE weakness classification. These fields give readers the technical context to understand the vulnerability class and its potential impact.
The publication includes a researcher-authored summary and description of the finding, rendered in formatted Markdown. Well-written summaries make your disclosed work more valuable as a portfolio piece.
A dedicated Impact section describes what an attacker could have achieved by exploiting the vulnerability — for example, data exfiltration, privilege escalation, or denial of service.
If the company added a Team Summary, it appears at the top of the disclosure. This is the company's perspective on the finding — typically acknowledging the researcher's contribution and describing how they responded.
The disclosure includes a curated timeline drawn from the report's activity log, showing key milestones such as when the report was created, when it was accepted, when severity was adjusted, and when the bounty was awarded.
If a bounty was awarded and the company chose to include it in the disclosure, the amount is shown on the detail page.
## Public vs. private programs
The way your name appears in a Hacktivity entry depends on the program's visibility setting:
When a finding from a public program is disclosed, the full program name appears on the entry. Your nickname, severity, status, and all approved metadata are displayed. The entry is fully indexed and searchable.
For private programs, the program name may be withheld from the public entry to protect the company's confidentiality. Your nickname still appears as the author of the finding, and the technical details remain visible, but the program context is redacted.
## Why Hacktivity matters for your reputation
Having your reports published to Hacktivity provides benefits that go beyond the bounty itself:
Disclosed findings link to your public profile. Potential employers, clients, and program administrators can see your track record of real-world vulnerabilities — not just your score, but the actual work.
A strong Hacktivity presence demonstrates that companies trust you enough to disclose your work publicly. It signals quality and professionalism to the broader security community.
Disclosed entries show your verified status badge if your identity is confirmed. This increases credibility and is visible to anyone reading the feed.
Published findings contribute to the platform's public record of security improvements — helping other researchers understand what vulnerability classes are in scope and what companies value.
Write your report summaries and impact sections with public disclosure in mind. A well-articulated technical write-up that is later disclosed becomes a lasting demonstration of your research depth. Even if you do not control whether the company discloses, you can always ensure the underlying report is worth sharing.
# Hackrate Leaderboard: Rankings and Scoring Explained
Source: https://hackrate-bb-app.mintlify.app/researchers/rewards/leaderboard
Discover how the four Hackrate leaderboard categories work, what each score measures, and practical ways to climb the rankings over time.
The Hackrate Leaderboard is a public ranking of security researchers on the platform. It gives companies a fast way to discover top talent and gives you a visible, verifiable record of your hacking effectiveness. Rankings are refreshed from cached data updated every 24 hours, so changes you make today will be reflected by the following day.
## The four leaderboard categories
The leaderboard is divided into four distinct boards. Each measures a different dimension of your performance, so the rankings recognize different types of excellence rather than a single score.
Ranks researchers by total reputation points accumulated through valid, accepted reports. Reputation is the primary measure of your overall standing on the platform.
Ranks researchers by the number of Critical and High severity findings in accepted reports. This board highlights researchers who consistently uncover the most dangerous vulnerabilities.
Ranks researchers by the raw count of valid (accepted) reports. This board rewards consistency and volume — finding many real vulnerabilities across many programs.
Ranks researchers within a selected country by reputation. Use the country filter to see how you compare to researchers in your region.
## Time period filters
You can filter any leaderboard view by time period to see both long-term standings and recent momentum:
Shows the cumulative leaderboard since each researcher joined the platform. Reputation points are drawn directly from your profile's total. This view rewards sustained, long-term contributions to the community.
Shows only activity from the past 90 days. Reputation for this view is calculated from earned reputation events within the window, so recently active researchers can appear prominently even if they are newer to the platform. This is a great way to see who is most active right now.
Leaderboard data is cached for up to 24 hours. If you just had a report accepted, your ranking may not update until the next cache refresh.
## How reputation points are earned
Your reputation score increases each time a company accepts one of your reports. The number of points awarded per report depends on the severity of the finding:
| Severity | Points awarded |
| ------------- | ----------------------- |
| Critical | Highest point value |
| High | Significant point value |
| Medium | Moderate point value |
| Low | Smaller point value |
| Informational | Minimal or no points |
In addition to your raw reputation score, your profile also tracks two performance ratios:
* **Hacker Power (Vulnerability Rate)** — reflects the proportion of your reports that contain High or Critical severity findings. A higher Hacker Power means your submissions tend to target the most impactful vulnerabilities.
* **Hacker Rate** — reflects the overall validity rate of your reports. A higher Hacker Rate means a greater proportion of everything you submit is accepted as a genuine finding, rather than marked as duplicate, out of scope, or informational.
Both ratios are visible on your public profile and on the leaderboard, giving companies additional context beyond raw score.
## Country filter
On the Countries board, you can filter rankings by a specific country to see how researchers from a particular region compare. Your country is set on your profile and — once your identity is verified — is locked to your verified country of residence.
If your country is not appearing, make sure you have set your country in **Account Settings → Profile**. Researchers who have not shared their country will not appear on any country-specific board.
## What reputation unlocks
Your reputation is more than a vanity metric. Companies use it to gate access to their most sensitive and rewarding programs:
Many companies run invite-only or private programs that are not visible to all researchers. When evaluating who to invite, program administrators often look at reputation score, Hacker Rate, and whether your account is verified. A higher reputation significantly increases the likelihood that you receive invitations to high-value private programs.
Researchers with strong reputations and verified identities appear with distinctive profile indicators (such as the verified badge and elite status badge). These signals build trust with companies that are considering working with you.
The platform distinguishes Elite researchers based on a combination of factors including reputation, track record, and program feedback. Elite status appears on your public profile and on the leaderboard, further increasing your visibility.
## How to improve your ranking
A single Critical severity finding earns more reputation than several Low severity reports. Prioritize deep investigation of high-value targets within a program's scope.
Mis-rating severity — claiming Critical when a company rates the issue as Medium — can slow triage and reduce trust. Study the CVSS scoring criteria and use it consistently; accuracy builds your Hacker Rate over time.
Well-documented reports with clear reproduction steps, CVSS breakdowns, and impact analysis are accepted faster and are more likely to earn bonuses. Faster acceptance means faster reputation gains.
Even if your all-time ranking is static, being active in the current 90-day window keeps you visible to companies browsing the recent leaderboard.
Verified researchers appear with a badge on the leaderboard. Verification also unlocks access to more programs, giving you more opportunities to earn reputation points. See [Verification](/researchers/account/verification) for details.