How we help our clients step-by-step in their Bug Bounty journey

– Suppose you were to ask us how YesWeHack differs from other platforms. In that case, we’d answer without hesitation that we stand out for the quality of our support and customer service.
Indeed, it’s part of our values from the beginning.
We understand that for many security managers, it can be challenging to launch and run a Bug Bounty program. It’s often a bet they’ve made with their executive committee, and most of them have never worked on the subject.

Hence, at YesWeHack, we assist our customers from the very beginning, whatever the type of Bug Bounty program (private, public). The Customer Success team is there to reassure and guide them, to ensure their bug bounty program will succeed and fulfil their goals and expectations.

Also, we make sure that our Bug Bounty programs are of high quality to satisfy our hackers too. Of course, our relationship with customers is very important. Still, we must not forget that we’d be nothing without our community of ethical hackers. We have to take care of them as well by offering them quality programs, and therefore by guiding our customers towards what a quality program is.

As a way to explain how we help and support our clients step-by-step in their Bug Bounty journey, we sat down with our Head of Customer Success, Selim Jaafar. We discuss his role at YesWehack and the best practices to adopt when it comes to crowdsourced security.

Hey!

I’m Head of Customer Success at YesWeHack. My role is basically to ensure the success of our clients Bug Bounty journey, which of course involves some technical, functional, organisational and human aspects. My team and I bring our expertise and experience to our customers–they often need advice and support when it comes to implementing and deploying their Bug Bounty programs.

Organisations typically have little experience and feedback on the practice of Bug Bounty. By contrast, we benefit from the experience and feedback of hundreds of organisations, with varying programs, goals, approaches and budgets. It’s then easy to identify and anticipate potential pitfalls, as well as to share best practices and help clients project themselves in the Bug Bounty world. We are also close to the hunters’ community. So, we can answer various questions about their ethics, way of working or on how to interact and collaborate with them within a Bug Bounty framework.

Also, launching a Bug Bounty through the YesWeHack platform allows you to take advantage of a rich set of features, integrations with third-party systems, indicators and other tools at your disposal. Helping clients get to grips with the platform, to get the most out of it and make the process all the more efficient, is naturally an essential part of my job. As such, it is necessary to question ourselves and to collect the feedback and wishes of our customers, always to improve and better meet their needs.

Furthermore, I supervise our internal triage team for customers who subscribe to this additional service. As customers’ first contact point, I can brief the triage team with customers instructions to set up appropriated workflows and build the most efficient and comprehensive triage service possible.

Simply put, my role is to allow customers, with a given budget and limited resources, to get the most out of their Bug Bounty experience, while avoiding some missteps. Achieving this requires constant support: onboard customers on the platform and familiarise them with the model, then to launch their first program, make it evolve, animate it and deploy the Bug Bounty on a larger scale, step by step, on the long run.

🎯 Ultimately, my goal would be to help clients enable Bug Bounty adoption within their organisation.

– List the scope(s) that should be tested in the first place. Suppose it’s your first Bug Bounty Program. In that case, there is a balance to find: large enough to be interesting and produce concrete results, but small enough to remain manageable. Some will prefer to test their “crown jewels” apps first when others are testing some less sensitive scopes. There is no such thing as a wrong choice here; it depends on your security objectives and resources and what you are trying to prove or improve through these first iterations.

– Define and prepare testing conditions. Black-box or Grey-box? On a production environment or a dedicated environment? How could hunters get access to my scopes? That kind of topics often comes with challenges that you’d better identify at the early stages of your project.

🎯Pro tip: the more latitude you’ll give to hunters, the more committed they will be, the more exhaustive and interesting will be the results.

– Delimit budget and set priorities. The higher the budget, the better the results will be, of course. Still, you could deliver value with a minimal budget, as long as you set your priorities and focus on what matters most, either in terms of scope or type of vulnerabilities.

– Identify stakeholders, distribute roles and define responsibilities. Bug Bounty programs often involve a broad set of actors and stakeholders—mostly Devs, Secs and Ops. Make sure to identify all those with a direct role on the program and grant them the appropriate access within the platform, and thus, technically enforce roles and responsibilities for better reports management. On the other hand, it’s never too soon to inform other interested parties of the upcoming Bug Bounty program and live testings.

– Draft your Program. It is in the definition of your program that your means, your objectives and your constraints will crystallise, through the scopes, rewards and rules that you will set up.

– Go live!

Program Definition ✔️

Role distribution ✔️

Hunters list ✔️

Testing environment ✔️

Clearly defined processes and workflows ✔️

It’s time to go live, congrats! o/

🎯 Pro tip: Avoid Fridays when launching a new program, if you want to enjoy your week-end 😉

Ambiguity is your worst enemy. Pay attention to how you define the scope, the qualifying vulnerabilities and eligibility rules of your program. When doing so, don’t leave too much room for interpretation (on both sides, i.e. hunters and program managers) as it could be frustrating, misleading or counter-productive if not well-bounded.

Once your objectives are clearly identified, program drafting should be a transposition of those, in terms of:

• Scope: what should be tested;
• Rules: what can be done and whatnot while testing the scopes;
• Rewards: what could one expect when submitting a valid in-scope report.

On top of this, you may add some details about how the app works and how hunters should proceed to get onboard on the program (accounts creation, testing environment, etc.). Anything that could help hunters get correctly to work for you to get the expected results, no less.

Do not overlook the details. That is why we systematically review all program creations and updates to ensure that the description meets the client’s objectives and expectations. Just as we regularly enrich our program creation form and templates to guide clients through these decisive steps.

Well, most of the job is on the hunters’ side–identify vulns,–and on the clients’ side–fix those. But as I was saying above, we do offer personalised support to our clients, and it comes with regular status meetings, to check up on:

• Internal teams workload: how comfortable are you with the current flow of reports?
• Results vs Objectives: how relevant and useful were the last reports received?
• Opportunities for step-up or improvement: do you want to go one step further? Do you want to put more focus on one aspect?

Depending on the client’s feedback and expectations, I can make some suggestions and recommendations, on where to lead the program:

• invite more hunters;
• introduce new scopes;
• switch from black-box to grey-box;
• increase the reward grid;
• “wait and see”.

At all times, I have to ensure that the program remains under control (on budget, workload, fix backlog, etc.) while delivering value and meaningful results.

Rather than listing what could go wrong or what to avoid, I’d emphasise on what to do to get the odds on your side:

• Be fair: try to adopt the hunters’ point of view and keep in mind the time, skills and efforts they put in while working with you. Make a good-faith effort to understand and apply best practices when it comes to handling hunters’ reports (e.g. is it really a duplicate?). Being fair does not mean being overly generous; it just means being fair.
• Be transparent: it applies to many situations and topics. Bug Bounty is a collaborative approach—the more information you share with hunters, the more involved they will be. For instance, when lowering the impact of a vulnerability, you might have some very good reasons to do so, that the hunter will only understand if you explain those, even briefly.
  
• Be interactive: once again, that’s inherent to the collaborative model: direct interactions will often help you get to the bottom of it. If not sure about your understanding of a vulnerability’s impact, or its technical implications, feel free to ask. Knowledge sharing is part of the hunters’ DNA. 
• Be creative: in your rules, your tone or by setting up new challenges within the program itself; there are many ways to differentiate or to experiment through a Bug Bounty. 
  
• Be thankful: it’s a common thing to think that bug hunters are only interested in bounties. Let’s be honest, it’s a great motivation and a legitimate expectation, considering the work and efforts. But on the long run, hunters will tend to focus on programs where they feel appreciated and useful. It’s a matter of human interactions after all. 

And more importantly, be cool, Bug Bounty is mostly fun!

Most of the time, I leave it up to clients and researchers to manage their interactions 😊

However, it is important to make sure that both parts of this ecosystem (organisations and hunters) learn to understand each other. Both sides have their own mindsets or points of view when it comes to how a program should be managed, how a report should be triaged or rewarded, etc. And it’s not a problem at all. From there come great diversity and insightful debates, equally instructive for both sides, as long as everyone keeps an open mind.

It’s inspiring for me, and for us as a Bug Bounty platform, to bring together those different universes and create synergies. We don’t take sides, and we won’t do so ever. Bug Bounty is a rich and vibrant ecosystem that platforms, organisations and hunters must share and improve together!