Mining Bug Bounty Scopes: How bounty-targets-data Automates Security Reconnaissance
Hook
Every hour, thousands of domains become fair game for security testing. Bug bounty hunters who wait to discover them manually are already hours behind the competition.
Context
Bug bounty hunting requires knowing what’s in scope before you start testing. Each platform—HackerOne, Bugcrowd, Intigriti, YesWeHack, Federacy—maintains its own list of programs and eligible domains, updated as companies launch new initiatives or expand existing ones. Manually checking these platforms daily is tedious and error-prone. By the time you discover a new program through casual browsing, other researchers have already scanned the attack surface and identified low-hanging fruit.
The bounty-targets-data repository solves this coordination problem by automating the aggregation of scope data across all major platforms. It scrapes each platform hourly, extracts eligible domains, and commits the results to a version-controlled GitHub repository. The result is a continuously-updated, machine-readable database of bug bounty targets that researchers can query programmatically or integrate into their reconnaissance pipelines. With over 3,600 stars, it’s become infrastructure for the security research community.
Technical Insight
The architecture is elegantly simple: bounty-targets-data is purely a data repository, while the actual scraping logic lives in a companion repository called bounty-targets. The scraper runs on a schedule (hourly according to the repo description), fetches program data from each platform, parses the scope information, and commits the results back to this data repository. This separation of concerns keeps the data accessible even if the scraper needs maintenance.
The repository provides two critical files for different use cases. The domains.txt file contains a clean list of exact domains without wildcards—perfect for feeding into subdomain enumeration tools or passive DNS queries. The wildcards.txt file contains entries like *.example.com, which indicate that all subdomains under that parent are in scope. This separation matters because wildcards require different reconnaissance strategies. If you see *.stripe.com in wildcards.txt, you know to invest time in subdomain discovery tools like amass or subfinder, whereas an exact domain like security.stripe.com suggests focused application testing.
For researchers building custom automation, the platform-specific JSON files are the real treasure. The repository provides raw data files for each major platform:
{
"bugcrowd_data.json": "Raw Bugcrowd program data",
"hackerone_data.json": "Raw HackerOne program data",
"federacy_data.json": "Raw Federacy program data",
"intigriti_data.json": "Raw Intigriti program data",
"yeswehack_data.json": "Raw YesWeHack program data"
}These JSON files preserve the original structure from each platform, potentially allowing you to extract metadata beyond just domains. The Git commit history functions as a time-series database, with each commit representing a snapshot of the bug bounty landscape. For researchers studying the bug bounty ecosystem itself, this historical data could be valuable for trend analysis.
The hourly update frequency keeps the data reasonably current without constant changes. The automated approach means the data stays current without manual intervention.
Gotcha
The most critical limitation is buried in the README’s wildcard warning: “A program might have *.example.com in-scope but excluded.example.com out-of-scope.” The repository provides no information about exclusions, special rules, or out-of-scope subdomains. If you blindly test everything in wildcards.txt without reading the actual program policy, you risk submitting invalid reports or worse—testing assets the company explicitly excluded. The data tells you where you can hunt, but not where you can’t.
The hourly update interval creates a gap between program publication and data availability. If a company launches a new bug bounty program mid-hour, it won’t appear in the repository until the next scrape cycle completes—potentially an hour or more later. Additionally, data accuracy depends entirely on the scraper’s ability to parse each platform correctly. UI changes on HackerOne or Bugcrowd could break the extraction logic, causing missing or stale data until the bounty-targets scraper is updated. The README points to the scraper repository for the actual code, but there’s no SLA or guaranteed uptime—this is a community project, not a commercial service.
Verdict
Use bounty-targets-data if you’re building reconnaissance automation, monitoring for new programs across multiple platforms, or need a comprehensive starting point for target discovery. It’s essential infrastructure for bug bounty hunters who work at scale and want to eliminate manual platform checking. The separated domain and wildcard files make it trivial to integrate into existing toolchains. Skip it if you only hunt on a single platform where the native interface is sufficient, if you need real-time notifications (the hourly lag may be too slow for time-sensitive opportunities), or if you require detailed program rules and exclusions. Most importantly, skip relying on it as your only source of truth—always verify scope details and exclusions on the actual platform before testing. Think of this repository as a discovery layer, not a complete scope specification.
