HackerOne Integration for Elastic
| Version | 0.1.1
|
| Subscription level What's this? |
Basic |
| Developed by What's this? |
Elastic |
| Ingestion method(s) | API |
| Minimum Kibana version(s) | 9.1.0 8.19.0 |
To use pre-release integrations, go to the Integrations page in Kibana, scroll down, and toggle on the Display beta integrations option.
The HackerOne integration brings your bug bounty and vulnerability disclosure reports into Elastic Security. Use it to monitor submissions from security researchers, track report status, and analyze vulnerability data alongside your other security tools.
The integration checks HackerOne on a schedule you choose and pulls in new or updated reports. After the first run, it only collects reports that changed since the last check, so you stay up to date without duplicate data.
This integration works with the HackerOne Customer API. You need an organization API token from a Professional, Community, or Enterprise program. You can also use the free Sandbox program to test the integration.
On each scheduled run, the integration:
- Connects to HackerOne using your API token.
- Fetches reports for the programs or inboxes you specify.
- Sends each report to Elasticsearch for search, dashboards, and alerting.
When a report is updated in HackerOne (for example, triaged or resolved), the integration picks up the change on the next run.
Each report includes details such as:
- Status and timeline — when the report was created, triaged, closed, disclosed, and last updated.
- Vulnerability details — title, description, severity rating, CVSS score, weakness type, and CVE IDs when available.
- People involved — the researcher who submitted the report, assignee, program, and collaborators.
- Scope and rewards — the affected asset, bounty and swag awards, attachments, and remediation guidance.
- Monitor vulnerability disclosure programs from a single place in Elastic Security.
- Build SLA dashboards using response-time and resolution-time metrics.
- Track bounty spending across programs.
Before you install the integration, gather the following from your HackerOne organization:
- API access. API tokens are available on Professional, Community, and Enterprise programs. Use the free Sandbox program for testing.
- An organization API token with Report management permission. As an Organization Administrator, go to Organization Settings → API Tokens to create one. Save both the identifier and the value when the token is created — the value is shown only once.
- At least one program handle or inbox ID to tell the integration which reports to collect.
- Program handle — the name in your program URL:
https://hackerone.com/<handle>(for example,acme). - Inbox ID — the numeric ID from your inbox settings page URL.
- Program handle — the name in your program URL:
- (Optional) IP allowlist entry — if your organization restricts API access by IP, add the outbound IP address of the Elastic Agent host.
Elastic Agent must be installed. For more details, check the Elastic Agent installation instructions. You can install only one Elastic Agent per host.
- In Kibana, go to Integrations and search for HackerOne.
- Click Add HackerOne.
- Fill in the required settings:
- URL — HackerOne API address (default:
https://api.hackerone.com). - API token identifier — the identifier from your API token.
- API token value — the secret value from your API token.
- Program handles and/or Inbox IDs — at least one is required.
- Interval — how often to check for new reports (default: every 5 minutes).
- Initial lookback — how far back to fetch reports on the first run (default: 24 hours).
- Page size — number of reports retrieved per request (default: 100).
- URL — HackerOne API address (default:
- Optionally narrow what is collected with State filter and Severity filter.
- Save the integration policy and assign it to an Elastic Agent policy.
After the integration is running, open Discover in Kibana and search for event.dataset: "hackerone.report". You should see reports within one polling interval (default: 5 minutes) after they are created or updated in HackerOne.
For help with Elastic ingest tools, check Common problems.
- 401 Unauthorized — The API token identifier or value is wrong. Make sure you entered the token identifier (not your email address) in the identifier field.
- 403 Forbidden — The token is valid, but access was denied. Check that the Elastic Agent's IP address is on your organization's allowlist, and that the token has access to the programs you configured.
- 429 Too Many Requests — HackerOne limits how many requests you can make per minute. Try increasing the polling interval or collecting fewer programs with a single agent.
- No documents indexed — Confirm that at least one Program handle or Inbox ID is set. The integration needs at least one to know which reports to collect.
For guidance on scaling data ingestion, see Ingest Architectures.
A single agent can handle many programs at the default 5-minute interval. If you set a long initial lookback (for example, 30 days or more), the first run may take longer while historical reports are collected.
The report data stream collects bug bounty reports from HackerOne. Each report is stored as one document. When a report is updated, a new document is indexed with the latest information.
Exported fields
| Field | Description | Type |
|---|---|---|
| @timestamp | Event timestamp. | date |
| data_stream.dataset | Data stream dataset. | constant_keyword |
| data_stream.namespace | Data stream namespace. | constant_keyword |
| data_stream.type | Data stream type. | constant_keyword |
| ecs.version | ECS version this event conforms to. ecs.version is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. |
keyword |
| error.message | Error message. | match_only_text |
| event.action | The action captured by the event. This describes the information in the event. It is more specific than event.category. Examples are group-add, process-started, file-created. The value is normally defined by the implementer. |
keyword |
| event.category | This is one of four ECS Categorization Fields, and indicates the second level in the ECS category hierarchy. event.category represents the "big buckets" of ECS categories. For example, filtering on event.category:process yields all events relating to process activity. This field is closely related to event.type, which is used as a subcategory. This field is an array. This will allow proper categorization of some events that fall in multiple categories. |
keyword |
| event.created | event.created contains the date/time when the event was first read by an agent, or by your pipeline. This field is distinct from @timestamp in that @timestamp typically contain the time extracted from the original event. In most situations, these two timestamps will be slightly different. The difference can be used to calculate the delay between your source generating an event, and the time when your agent first processed it. This can be used to monitor your agent's or pipeline's ability to keep up with your event source. In case the two timestamps are identical, @timestamp should be used. |
date |
| event.dataset | Event dataset. | constant_keyword |
| event.end | event.end contains the date when the event ended or when the activity was last observed. |
date |
| event.id | Unique ID to describe the event. | keyword |
| event.kind | This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. event.kind gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data is coming in at a regular interval or not. |
keyword |
| event.module | Event module. | constant_keyword |
| event.original | Raw text message of entire event. Used to demonstrate log integrity or where the full log message (before splitting it up in multiple parts) may be required, e.g. for reindex. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from _source. If users wish to override this and index this field, please see Field data types in the Elasticsearch Reference. |
keyword |
| event.outcome | This is one of four ECS Categorization Fields, and indicates the lowest level in the ECS category hierarchy. event.outcome simply denotes whether the event represents a success or a failure from the perspective of the entity that produced the event. Note that when a single transaction is described in multiple events, each event may populate different values of event.outcome, according to their perspective. Also note that in the case of a compound event (a single event that contains multiple logical events), this field should be populated with the value that best captures the overall success or failure from the perspective of the event producer. Further note that not all events will have an associated outcome. For example, this field is generally not populated for metric events, events with event.type:info, or any events for which an outcome does not make logical sense. |
keyword |
| event.start | event.start contains the date when the event started or when the activity was first observed. |
date |
| event.type | This is one of four ECS Categorization Fields, and indicates the third level in the ECS category hierarchy. event.type represents a categorization "sub-bucket" that, when used along with the event.category field values, enables filtering events down to a level appropriate for single visualization. This field is an array. This will allow proper categorization of some events that fall in multiple event types. |
keyword |
| event.url | URL linking to an external system to continue investigation of this event. This URL links to another system where in-depth investigation of the specific occurrence of this event can take place. Alert events, indicated by event.kind:alert, are a common use case for this field. |
keyword |
| hackerone.report.attributes.bounty_awarded_at | Timestamp when a bounty award was recorded. | date |
| hackerone.report.attributes.closed_at | date | |
| hackerone.report.attributes.created_at | Report creation time from attributes. | date |
| hackerone.report.attributes.cve_ids | Full CVE identifiers when present beyond the ECS vulnerability.id primary. | keyword |
| hackerone.report.attributes.disclosed_at | Public disclosure timestamp. | date |
| hackerone.report.attributes.first_program_activity_at | First program-side activity time. | date |
| hackerone.report.attributes.hai_is_priority | boolean | |
| hackerone.report.attributes.hai_is_priority_reason | keyword | |
| hackerone.report.attributes.issue_tracker_reference_id | keyword | |
| hackerone.report.attributes.issue_tracker_reference_url | keyword | |
| hackerone.report.attributes.last_activity_at | Last activity time on the report (primary polling cursor). | date |