Internal Bug Bounties Programmes
Most companies are not ready to do public bug bounties because they don’t have the workflows, or they have too many vulnerabilities, or they don’t have enough processes in place. To circumvent this problem, some companies run internal bug bounties. Internal bug bounties can be managed by some of the bug bounty services, or they can be managed by external, private bug bounty companies. An internal bug bounty is a good first step towards running a public bug bounty.
This Working Session aims to leverage the knowledge of those who have experience in internal bug bounties. The session will create a playbook that sets out the steps, and creates a workflow for an internal bug bounty. Anyone who wants to run a bug bounty will leave the session knowing what to do next.
- How to make an internal bug bounty work
- What to expect
- Who to contact
- What funds will I need to allocate?
- What are the governance issues?
- What are the risks?
- What commercial companies can run a bug bounty?
The session discussed the uses and implementations of internal Bug Bounties, which require selecting the correct applications and team (Non-crunch team) to give an adequate return on resources invested.
Organisational examples include:
- Starting with small controlled experiments in a set window of time
- Insuring the correct participants are identified
- Creation of roadmap for bug bounty program
- Community-driven effort rather than HQ engineer-led
- Set ranges for all monetised, gift and concessions
- Work with payroll to create plan for distribution of payments
- Voluntary security training to identify key testers internally
- Test accounts created with admins in place to provide support
- Inclusion/Exclusions of certain items (low priority)
- Encourage the focus on selected (high-risk) areas that give the best outcomes
- Expectation setting (rules)
- Use a recognition based scoreboard that showcases the best internal talent for later projects
- Tracking system: Format standard for reporting, Unit tests, expectations of formal documentation, technologies used to create the bug and a platform to send the report (GitHub/Jira etc.)
- Testing layer defences ethically from an internal, pre-approved point of view
- Education for employees
- Reducing the risk for the organisation
- Security Outreach
- Reduction of security bias
- Identify patterns in organisations for defects
- When compared to external bug bounties which are black box, an internal bounty is a white/grey box which can increase efficiency and allow lessons learned to be shared across similar teams
- No guarantee of any favourable outcome
- Resources taken from other key areas
- Conflict of interest
- Scalability can be a complex issue
The target audience for this Working Session is:
- People who have participated in or managed bug bounties in the past
- People who want to run bug bounties in the future
- Developer teams
- Draft playbook for internal bug bounties
- Please add as much information as possible before the session
Back to list of all Working Sessions and Tracks
Edit this page here