Explore Bug Bounty Program Structure
Learning Objectives
After completing this unit, you’ll be able to:
- Examine the typical work phases of bug bounty programs.
- Explain the areas of research outlined in a bug bounty program.
- List the common personnel roles in a bug bounty program.
Now that we have a better understanding of a bug bounty program and its goals, let’s delve into more details on its structure and components.
Program Work Phases
While details may vary, the basic elements of a bug bounty program are fairly consistent. Three work phases exist in every bug bounty program (or BBP for short): intake, triage, and remediation. Some organizations add a fourth: disclosure. Let’s take a closer look at each phase.
Intake
Intake is the bug reporting process that captures all required information on a vulnerability. The process generally involves a preferred contact method to allow external security researchers to get in touch with the organization that owns the bug, such as a designated email address or web intake form. The BBP should clearly outline expectations for reporting requirements, including areas that are not considered a vulnerability and not in scope.
Triage
In software security, “triage” has come to mean a standardized process to assess if a submission is a reproducible security flaw. When security bugs are reported, the first part of triage involves assessing the type of risk posed, its severity, and impact to the business.
One industry system often used is the Common Vulnerability Scoring System (CVSS), which represents assessments with a numeric scoring system. The CVSS isn’t a measurement of risk but is instead a consistent way to represent the severity of a vulnerability with a numeric score. It is up to an organization’s security team to determine the severity of a bug and then prioritize the necessary fix.
Salesforce, for example, uses CVSS plus a number of other factors to determine the severity level of a vulnerability. These severity levels assist with prioritization of the vulnerability so that remediation can begin.
Remediation
The third phase of work is remediation. The engineering owner is responsible for remedying the risk posed (or harm caused) by the vulnerability. However, the task force supporting remediation can include security and product teams, legal, or other department representatives, depending on the nature of the issue. The team identifies a solution, fixes the vulnerability, and oversees deployment to production.
The time to remediate a vulnerability depends on the severity of the issue and the impact to the business. It could take hours up to a few weeks, depending on the complexity and risk associated with the issue. An engineering team is responsible for meeting remediation service level agreements (SLAs), and there may be additional teams who handle potential exceptions where necessary.
Disclosure
While most organizations engage in, at minimum, the first three phases, some go beyond these three and engage in disclosure. Disclosure is the description and communication of the vulnerability and the steps the team took to remediate the bug. Typically this messaging is reviewed, edited, and approved by management and legal prior to its release.
Disclosure can be a great way to transparently share the discovered issue and what the organization did to mitigate the risk. It can benefit other companies by helping them understand the vulnerability and how to mitigate similar issues they may face. Disclosure can also serve as an education tool for researchers, teaching them about unique methodologies and steps to find software security bugs.
There are two types of disclosure in the industry: private and public.
Private disclosure commonly means an organization notifies only the customers impacted by the vulnerability and remediation.
Public disclosure is when an organization notifies impacted customers and the public at large. Even with public disclosure, though, organizations do not disclose all the details surrounding the vulnerability since this can aid or encourage exploitation by malicious actors.
Ultimately, it’s a balancing act. The decision to engage in private disclosure, public disclosure, or disclosure in any capacity rests on the organization and its comfort level with sharing such sensitive information outside the organization.
We’ve examined the work processes in a bug bounty program: intake, triage, and remediation, and discussed the optional fourth phase: disclosure. If you’re building a new program for an organization, the next step is to establish clear guidelines for external security research.
Research Considerations
For any successful program, it’s important to have established rules and parameters. Setting up these guidelines involves decisions about the scope of research to be done and who may do it. Clear answers to the following questions help create a successful BBP structure.
Research Participation
Will the program be open to the general public, or will there be limits on who can participate?
If anyone can participate, the bug bounty program is referred to as public.
If the program admits only invited individuals, it is considered private. A private bug bounty program allows an organization to control the volume of research reports and also the quality of researcher interactions. Enhancing the researcher experience can lead to higher-quality research and reports.
Research Scope
Is the entire organization and infrastructure available for testing, or will certain products be the focus? Security teams set guidelines for what areas may be tested and clearly define these boundaries. They define the scope of research: what is considered in-scope for testing versus out of scope, or off limits, to researchers. Here are a few examples.
Enterprise testing means that all publicly accessible servers, devices, or domains are in-scope for research and testing. Organizations may opt to test services such as a virtual private network (VPN), network devices, or technologies that enable customer communication.
Product testing is used when organizations direct the bug bounty research to specific software applications or packages, particularly if that is a primary business focus.
Duration of Testing
An organization typically chooses to run a continuous bug bounty program to incentivize researchers and grow awareness.
Time-restrained challenges, on the other hand, set time limitations for vulnerability researchers. This can help an organization understand the areas of interest to researchers based on the number of reports submitted. Organizations can then fine-tune their BBP, for example, adding incentives to ensure less popular products are still thoroughly analyzed by researchers.
Job Roles
Organizations may add personnel to create a BBP or assign responsibilities to existing roles. Either way, it’s important that the following job descriptions are clear and assigned.
Bug bounty program lead has ultimate responsibility for the program. This role oversees processes; updates work instructions and operational playbooks; monitors and reports on key performance indicators (KPIs); coordinates with stakeholder departments, including legal, public relations, and engineering; requests program funding; and manages the budget.
This stakeholder is also tasked with day-to-day operations, plans live events, manages external deliverables, increases internal awareness, and keeps individual stakeholders on track to meet deadlines.
Triage analysts confirm that incoming vulnerability reports have the appropriate information to characterize severity and identify remediation options. They act as technical resources to verify the real impacts of the vulnerability within the organization.
Organizations often begin a bug bounty program with a small staff and add personnel as the program grows. BBPs have a valuable impact throughout the organization because they affect other key departments such as product, engineering, legal, and public relations.
Ultimately, a BBP can act like a high-beam light source, focusing added attention on specific areas for a targeted period or on an ongoing basis. Organizations gain insight from partnering with researchers with a diverse array of hacking skill sets, build trust among stakeholders, and stay on top of ever-evolving software security research.
Now that we’ve got a good understanding of how bug bounty programs work, let’s focus on the specific elements and keys to success in the Salesforce Bug Bounty Program.