I Automated the Boring Part of Bug Bounty Hunting

Description and use

The bounty‑watch automation uses GitHub Actions, Issues, and Pages to monitor bug‑bounty program changes without manual effort, relying on a public dataset and free GitHub services.

Problem

Bug bounty hunters need to monitor program scope changes across multiple platforms but manual checks are tedious and error‑prone.

Outcome

The bounty‑watch automation reduces manual monitoring to a scheduled diff process, alerts only on meaningful scope changes, and leverages free GitHub services to eliminate infrastructure costs.

Workflow

• 1. Use GitHub Actions to schedule a cron every six hours.
• 2. Pull the latest JSON files from the public dataset repo arkadiyt/bounty-targets-data.
• 3. Flatten program data into a key/value structure (e.g., "h1:shopify").
• 4. Compare current snapshot to the previous run to detect new programs, added/removed assets, pauses and resumes.
• 5. On first run, record baseline and suppress alerts.
• 6. For watchlisted programs, query crt.sh for new subdomains under wildcard scopes, perform liveness checks and flag takeover risks.
• 7. Fingerprint in‑scope sites (JS bundle names, headers, generator tag, title) and detect changes to identify new deployments.
• 8. Mine changed JavaScript for new API endpoints, GraphQL operations, feature flags, and mobile app version bumps.
• 9. When any change is detected, open a GitHub Issue to trigger an email notification.
• 10. Write updated data back to the repo; GitHub Pages renders a public dashboard.
• 11. Maintain a hunt score for each program based on freshness, new surface, attack surface, reward, and saturation.
• 12. Rely on free GitHub infrastructure (Actions, Issues, Pages) to avoid server costs.
• 13. Keep the script dependency‑free, using only the Python standard library.
• 14. Iterate and refine the scoring model as needed.

Evidence

I built a thing that does it for me, every six hours, for free, and emails me when something actually changes.

Source

Turns out I didn’t have to. There’s a public dataset, arkadiyt/bounty-targets-data, that already aggregates the public program and scope info for the major platforms and refreshes itself every half hour or so.

Source

Actions is the scheduler. A cron fires the script every six hours.

Source

Issues is the mailer. When something worth knowing happens, the workflow opens an issue, and since GitHub emails you about issues in your own repos, I get an email for free without ever touching SMTP or paying for an email API.

Source

The script writes its data as JSON back into the repo, and one static page reads that and renders the feed, the scope changes, all of it, at a public URL.

Source