We have collected and summarized some of the top questions we received from our recent webinar, “Bug Bounty Programs Debugged: a 360 view”.
For more on this topic watch the full webinar here.
1) Are Bug Bounty programs an essential part of validating product security beyond independent 3rd-party assessments?
Yes, many companies in the technology sector already consider bug bounty an essential part of their secure development practices. However, it is important to emphasize that this is not a replacement for penetration testing or other upfront activities that are part of a traditional secure development lifecycle initiative.
2) What are your thoughts on internal Bug Bounty programs?
Paying for vulnerabilities can create perverse incentives and risks. For example, in a worst case scenario, developers and quality assurance may collude with other parts of the organization to find and create defects and split the cash reward.
An alternative approach is to implement “Capture the Flag” contests using applications developed by the organization. This type of contest will offer prizes to winners for uncovering vulnerabilities – they can then present and explain their findings to all participants.
3) How can organizations manage Bug Bounty programs next to traditional vulnerability management, penetration testing, and red team practices?
Bug Bounty programs should provide feedback to these practices, and the techniques and tools utilized by the researchers should be adopted by organizations. It is crucial to learn from and understand how the internal team missed any vulnerabilities uncovered by external testers. These findings should be used to understand how further development could prevent or completely eradicate the class of vulnerability that was reported.
4) Are Bug Bounty programs for everyone?
Every organization should have a way for the public to securely report vulnerabilities. However, not all organizations should welcome external testers without considering the risks and how to constrain the environment. Some examples include:
- Organizations providing critical infrastructure
- Organizations whose assets can be more valuable than the actual bug reward (bitcoin foundation),
- Organizations where the cost of development workforce is relatively low compared with the reward of a bounty.
5) How should organizations deal with a security researcher’s unethical behavior i.e. going outside the scope of the program?
It is important to understand why a researcher has taken that step. In some instances, you may want to make an exception to encourage and allow for diversity in your environment. Having people who are willing to be a bit daring and report some things that a black hat could do in practice, can be very beneficial to the success of the program.
However, on other occasions, an organization may need to call out unethical behavior. In fact, there have been instances where a CISO has flagged unethical behavior in public and banned the researcher from their community.
Depending on the situation – a warning is usually a good way to start. Give the yellow card. If the problem persists, move forward with banning the researcher.
6) Should researcher be allowed to go public with a finding?
Some organizations do put restrictions on researchers going public with their findings; this is especially true for public Bug Bounty programs. However, this does not mean researchers cannot publish their work. Many will anonymize the company and discuss their findings in more general terms in articles and blogs.
7) Some researchers are not generating any findings. Should I kick them out of my program?
No. In fact, researchers who are working and not reporting findings are not necessarily a bad thing. It is the researchers who generate noise that you should consider removing from your program, as these are the ones that will be increasing the cost of your program.
8) How do Stroz Friedberg services complement Bug Bounty programs?
Here are a few ways that Stroz Friedberg’s services complement Bug Bounty programs:
Assessing vulnerability reports: The Common Vulnerability Scoring System (CVSS) is not always accurate. Our specialists employ scientific principles and methodologies to assess and prioritize the criticality of security vulnerabilities, providing an organisation with a robust strategy to respond to threats.
Response and coordination: Our team can help contain incidents wherever they occur in the world, and can be deployed and on the ground at an organization within 24 hours when needed.
Recommending mitigations: Researchers or hackers may be able to hunt for and identify vulnerabilities but they are not good at providing solutions to mitigate them. Security vulnerabilities often require focused attention and specialized skills. Our team can work with organisations to develop, implement or oversee remediation plans.