I Automated the Boring Part of Bug Bounty Hunting
说明与用途
bounty-watch 自动化脚本利用 GitHub Actions、Issues 和 Pages 监控漏洞赏金项目的变更,无需人工干预,依赖公共数据集和 GitHub 免费服务。
问题
Bug bounty hunters need to monitor program scope changes across multiple platforms but manual checks are tedious and error‑prone.
结果
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.
工作流
- 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.
证据
I built a thing that does it for me, every six hours, for free, and emails me when something actually changes.
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.
Actions is the scheduler. A cron fires the script every six hours.
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.
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.
- 记录日期: 2026-10-03T20:55:48.828Z