- HOME
- Thought leadership
- Begin your bug bounty program with shared inboxes
Begin your bug bounty program with shared inboxes
- Published : October 7, 2022
- Last Updated : November 2, 2023
- 1.0K Views
- 7 Min Read
“What I did in my youth is hundreds of times easier today. Technology breeds crime.” - Frank Abagnale
At 2019 Gartner summit, I had a chance to sit in the front row for the keynote speech by Frank Abagnale. Abagnale is famous for the cons documented in the Hollywood blockbuster, Catch Me If You Can, starring Leonardo de Caprio. Abagnale later went on to work with the FBI uncovering check forgers.
In the same way Frank Abagnale helped the FBI, a bug bounty program can help your organization.
Bug bounty programs unite ethical hackers and researchers to help organizations stay one step ahead of the bad guys (or threat actors), and detect vulnerabilities in their environment.
You could be a growing startup with a paying B2B customer base. You have a small team of developers and product managers, who are also responsible for the security of your application. With an increasing number of bugs being reported on social media and public domains, you want to implement a bug bounty program for your mobile app, that will be used by your clients’ employees.
Or
You could be an enterprise with a large B2B footprint offering multiple products across various domains. You already have a private bug bounty program for all your critical offerings through crowdsourced platforms, like Bugcrowd or Hackerone. However, your security department would like to set up an in-house program, with limited scope and a small internal team, to accept and triage bug reports from users across all channels.
Running an in-house bug bounty program can be quite overwhelming, and may lead to a flood of emails from hackers and researchers reporting bugs. With no reputation system in place, your security team will have to screen each report for non-issues, duplicates, and out-of-scope information.
From our own bug bounty program at Zoho Mail, fewer than 5% of reported bugs are actual defects that lead to compensation, and only about 2% are informative. 25% of reports are not issues and over 10% are duplicates.
A number of disparate teams become involved at different stages of the bug lifecycle, from reporting to disbursement of bounty. Smooth functioning of the bug bounty program requires screening and skillfully organizing submissions, collaborating for triage, timely assignment of ownership, and automation of repetitive processes.
Every team ends up running a bug bounty on one of the platforms at some point along their growth journey. But it always begins with good old mail.
We've reimagined the bug bounty process with shared inbox—an inexpensive yet intutive tool with applications in a number of team collaboration use cases. A shared inbox (or team inbox) provides a unified collaborative space so multiple users can access, read, and send emails. This enhances team productivity and ensures transparency, visibility and credibility among members. Here is a useful article on shared inboxes and how they help organize workspaces.
In this article, we’ll discuss ways to build and optimize your bug bounty program using a shared inbox to consistently improve productivity and maintain healthy relationships with the hacker and research communities.
1) Identify the stakeholders: A shared inbox is a suitable application for this use case because bug bounty programs involve considerable cross-functional collaboration over submitted bug reports.
Triage team: Once selected, the members of your triage team can be added to a mail group in your shared inbox. Ideally, the triage team is comprised of the product manager, lead tester, technical lead, and development lead.
Depending on your internal processes and anticipated inflow, you may choose to create a siloed group inbox or folder just for triaging. However, to begin the program with a small team and limited scope, you can form a single group with all stakeholders.
At various stages of the bug life cycle, you can members from additional teams, such as legal, compliance, PR, and corporate communications, to your bugbounty@ group, along with your data protection officer (DPO).
2) Vulnerability management and a "level zero" approach: It's important to define the process your teams will follow once a bug is confirmed. A bug bounty program demands the time and effort of existing resources to respond to researchers and fix bugs without disrupting business continuity.
Level zero: As with all use cases that involve external communications, your inbox is "level zero," for your bug bounty program. Manage all the screening, organizing of incoming emails, and replies within your inbox, without needing to forward messages or copy collaborators.
Instead of subjecting technical teams to a flood of submissions, consider training a junior level resource as the "level zero agent" for your program.
Establish necessary automation rules and triggers, including blacklisting or whitelisting emails to filter out spam and out-of-scope messages.
3) Documentation: There is a considerable amount of documentation that goes into the launch of a bug bounty program. All involved parties should have access to necessary information, and should be able to produce it to hackers whenever necessary. Start with a bounty brief that describes the rules of engagement for hackers, the code of conduct, terms of disclosure, and the research terms and conditions. The following are essential elements for your documentation:
Scope: Define the scope of the program. Where should researchers focus their testing? What’s in scope? What’s out of scope?
Access: Provide researchers with access to your scope and help docs, source code, and libraries.
Standards: How will you rate submissions? Define and share the standards you would like the hackers to refer to, such as common weakness enumeration (CWE) by MITRE’s, OWASP top ten, or Bugcrowd’s vulnerability rating taxonomy.
Reward range: Disclose how much you will pay for vulnerabilities upfront.
Safe harbor: Assure researchers that they’ll be safe from legal action and exempt from your end user license agreement(EULA) when operating within the rules of your bounty brief.
4) Announcement: Once you're prepared to launch your bug bounty program, send an announcement across channels to reach your target audience of ethical hackers and researchers. The announcement should carry the bounty brief and provide an email address (bugbounty@) where bug reports can be sent.
You should also advise your employees in public-facing roles on how to handle security reports and escalate potential security issues.
Stage | Workflow within the shared inbox |
Submission | Hackers submit bug reports to the bugbounty@ email address. The bug reports are delivered to the shared inbox group set up for bugbounty@. All group members can access the emails. If hackers send bug alerts to other company email addresses, teams forward bug related emails to bugbounty@ with the hacker marked, and the email is delivered to the group mailbox. |
Screening | The level zero agent screens/ filters the bug reports for duplicate submissions and compares reports with previously labeled emails. All evident duplicate submissions receive an immediate response with a pre-drafted email. The original report or relevant evidence should be included. All duplicate reports are then archived. |
Triage | The testing lead vets all open reports. The testing lead tags the level zero agent on all submissions that are non-defects, out of scope, or duplicates, to initiate responses with the scope document for reference. When a relevant report is received, the testing lead invites the development lead and corresponding product manager for a triage via tagging/commenting on the hacker's email. They discuss on private chat and leave notes on the email. The testing lead gives an RCA for the defect. The project manager adds the SLA to commit. |
Label and organize | The testing lead labels all bugs based on a) severity b) defect category The email containing the bug report is tagged appropriately to function as a reference to compare duplicate reports. |
Assign | The development lead assigns the defect to the developer. They can directly raise a defect on the defect tracker tool in the inbox through the appropriate plugin (shared inbox tools have OTB integrations with tools such as Jira, Zoho, and Monday, or can be connected via Zapier). |
Confirm vulnerability | The agent or project manager responds to the hacker with acknowledgement confirming the vulnerability and SLA for the fix, and also shares the details of the program. The agent can snooze the email until the SLA date, so the email is cleared from the inbox. A response from the hacker brings the email back to the top of the inbox. |
Resolve | The email thread resurfaces in the inbox after the snooze period. The project manager notifies the release if the defect is fixed. If the fix is delayed, the reason is provided along with an updated timeline. The hacker is updated after the SLA period. |
Drafting a public notice | The agent or project manager tags the corporate communications lead to draft and issue a public notice/ report. The public notice can be drafted on the same email thread. The corporate communications team can leverage the notes and technical details on the thread to draft the notice and share it for review. |
Communication and negotiation | Often, there is continuous exchange of emails with hackers, and a specific stakeholder might have to directly engage. A shared inbox allows individual stakeholders to respond from the group email address, bugbounty@ The developer might need more details on the vulnerability from the hacker, and can ask for this information directly. The project manager must update the hacker on the SLA. Conflict over the severity of the defect might involve the DPO. Negotiations on the bounty and other terms take place. |
Bounty | Finally, the details of the bounty and the preferred mode of payment can be shared with the accounts payable team. Any further discussions can take place in the original email thread. |
Follow status | All the stakeholders can follow any given bug report thread, and its status and stage throughout the life cycle. They have both visibility and the ability to contribute response drafts. |
Draft templates and tag reference emails | The agent should keep a list of drafted emails handy. These may include attachments and links. Sometimes, hackers with duplicate submissions might ask for drafts of original reports and evidence of vulnerability fixes, so these emails should be pre-drafted and ready to send. |
Communication with the hackers is the most important part of the bug bounty program—even if it is only a response to duplicate, out-of-scope, or no-defect submissions. That said, communication among teams through the bug life cycle is also crucial for the success of the program. Shared inbox facilitates seamless collaborative communication, making it one of the most suitable and cost effective tools to begin your bug bounty program.
Remember, to maintain a healthy relationship with hackers, you should reward them well and pay for well-written reports, including dupes.
There is no such thing as a foolproof system. That idea fails to take into account the creativity of fools. - Frank Abagnale
Sandeep KotlaSandeep is an inbound marketer with Zoho Corporation. Previously, he handled analyst relations and corporate marketing for ManageEngine (a division of Zoho Corp) and its suite of IT management products. He currently spends most of his time re-imagining and writing about how work gets done in large organizations, reading numerous newsletters, and Marie Kondo-ing his inbox.
