Building a Low Overhead Bug-Bounty Program

This is the story of why and how we built an in-house Bug Bounty program with almost all features of a SaSS platform at invideo.io in 15days; using tools that were available to us:
- Zapier
- Google Forms
- Google Sheets
- Linear.app
- Slack
- Gmail

Transcript

1. Building a Low Overhead Bug-Bounty Program @invideo.io
2. We are… 2 Joy B. Pankaj Mouriya DevOps & Security Architect @invideo.io Sr. Security Engineer @invideo.io
3. Roadmap 3 1 3 5 6 4 2 Why? The Pipeline Thinking ahead How? Is it Perfect? Tips & Tricks
4. Why and How? Constraints & assumptions we were working under 1
5. Why did we need a bug-bounty program? ▸ Vulnerabilities reports were already being piped to us via informal channels and unstructured mail-threads. ▸ This was significantly taking up leadership’s time for ad hoc responses ▸ We wanted to formalize this process and bring in a semblance of order to the chaos. ▸ Engineering needed prioritized and grouped list of vulnerabilities to fix, focusing their energies for maximum impact. ▸ Dedicated engineering bandwidth to classify and rank reported vulnerabilities. 5
6. How? 1
7. Tools & Platforms ▸ Build In-house bug bounty Program? ▸ Go with Well known/Crowdsourced vulnerability disclosure platforms ▹ BugCrowd ▹ HackerOne 7 https://github.com/disclose/bug-bounty-platforms ▸ List of known bug bounty platforms
8. What did we choose & Why? ▸ In-house bug bounty program 8 ▸ Exposing our applications to a global community of security researchers using crowdsourced platforms would invite a significant volume of threat actors. ▸ It would cause a significant engineering overhead to fix discovered vulnerabilities at scale and within expected turn-around times. ▸ Our applications were not yet internally pentested for vulnerabilities. Why?
9. The End to End Pipeline ▸ Tools we used? ▹ Google Form ▹ Google Spreadsheet ▹ Google Apps Script ▹ Zapier ▹ Linear.app (Issue tracking) ▹ Slack ▹ Gmail 9 ▸ Miro - For brainstorming and the Bug Bounty program workflow
10. Pipeline - I 10 Initial Report
11. Pipeline - II 11 Issue Triage
12. Pipeline-III 12 Prioritization & Fixing Vulnerability States
13. Pipeline - IV 13 Alerting Engineering
14. Pipeline - V 14 Bounty invoicing
15. What worked 15 ▸ For us, the integrations does the job well ▸ The implementation gives enough confidence like any other well-known bug bounty management platform ▸ Most of the comms between the InVideo security team and external researcher is handled via this workflow ▸ Within less than 2 months, our workflow was setup and we were hands free, managing everything inside Linear.app with just Labels
16. And, what did not ▸ While using this workflow we identified few gaps ▸ The Zapier integration takes few seconds to trigger the events 16
17. Thinking ahead ▸ The program is completely managed by our security team ▸ We made the choice of not offloading the program management to a third party 17 ▸ End to end control of the program ▸ Not at the mercy of third parties when it comes to the report timeline or fixing bugs ▸ Complete control lets us build our product and fix the bugs depending upon severity and org priorities ▸ The volume of bugs that gets fixed by an internal program due to lack of external pressure is lesser Rewards?
18. Thinking ahead… 18 (*this could be its own talk)
19. Tips & Tricks 19 CVSS Product Goals CRIT HIGH MID LOW Vulnerable Services Internal Test / Red team Security Research Community Secure services Automation Subject Matter Expertise Velocity Qualitative Assessment Fast and Impactful Security Fixes Security Posture Acceptable Risk
20. 20 THANKS! Any questions? You can find us at: ▸ @pankajmouriya ▸ pankaj.mouriya@invideo.io ▸ @hashfyre ▸ joy.bhattacherjee@invideo.io