Internal Bug Bounties Programmes

Back to list of all Outcomes

Original Working Session content: Internal Bug Bounties Programmes


Outcomes

Synopsis/Takeaways

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 with set timeframe
  • 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

Pros and Cons

Pros

  • Education for employees
  • Reduce 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

Cons

  • No guarantee of any favourable outcome
  • Resources taken from other key areas
  • Conflict of interest
  • Scalability can be a complex issue


Back to list of all Outcomes

Edit this page here