What we learned by taking our bug bounty program public

This post details the evolution of GitLab's bug bounty program after opening it to the public. Key contributions include: the introduction of an automated bot for initial report responses and triage ETAs; the use of a Slack command to import triaged HackerOne reports into confidential GitLab issues, assigning them to product managers for scheduling fixes; analysis of report volume, reporter demographics (doubling new reporters), and vulnerability types (critical and high-severity); identification of an increase in false positives and the use of these to refine triage processes; enhancements to communication with reporters, including automated fix date estimations via the GitLab API; implementation of a weekly rotation schedule for dedicated H1 response and triage; a shift in fix scheduling where the security team assigns due dates and product managers balance feature/security deliverables; and insights gained that prompted refinements in the permissions model (investigating automated CI checks) and advocacy for code reuse via security-focused libraries to prevent recurring vulnerability classes.