 DOJO, we have initiated a challenge series. The second 

 had been the arena of fierce competition. The first five challenge solves and the five best write-up reports were rewarded with a nifty goodies pack.

 geared towards learning bug exploitation the fun and visual way.

The DOJO is three things in one: a learning tool, training platform and a playground.

The DOJO is the arena where the second challenge took place (see the 

We are glad to announce the #2 DOJO Challenge winners list. Everyone will receive a goodies pack.

 to the other contestants–you will soon be able to give another challenge a try again! Subscribe to our 

 feeds for future challenge announcements.

Read on to find the best write-up as well as the challenge’s author recommendations.

The Challenge here was exploiting a web form and fetching back sensitive information from the SQLite database through an effective one-shot SQL injection on a contact form field. The returned string must contain the system administrator email and password concatenated in a mandatory sequence:
admin:<email>:<password>

We also asked the contestants to produce a qualified write-up report explaining the logic allowing such exploitation. This write-up serves two purposes:

Determine the contestant ability to properly describe a vulnerability and its vectors inside a professionally redacted report. This capacity gives us invaluable hints on your own, unique, talent as a bug hunter.

We publish here the best write-up report for this session with the permission of its author, 

/—– SENSEI SEHNO’s REPORT ———————————————————–/

An SQL injection attack consists of the insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.

SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.

1-/ At first, I see that we are constrained by differents filters.

So the first thing to do is to bypass the filters with this payload :

Now we can show the tables of the database with this command:

The result is interesting but in the code we see that we have LIMIT 5 and we know that we don’t see all tables.

We search for another table with ‘user’ inside:

We found a table ‘users’ with interesting details: email, password, role.

We see different emails but we are also restricted by the LIMIT 5. The table ‘users’ contain the attribute ‘role’. We list the role with this command:

Nice! All that’s missing now is the password :

Remember that the goal is to show the email and password like this:

/—– END of SEHNO’s REPORT ———————————————————–/

 is the Technical Ambassador at Yes We Hack. He also created the DOJO and this challenge.

Instead of chaining requests with UNION, the intended solution was to bypass the comment filter the same way sehno did for the SELECT filter. This allows you to do the exfiltration in a single INSERT.

Around half the players used the /SELECT* version and the other half used the UNION technique. Both are valid in solutions.

I hope you had fun in this first challenge. Stay tuned for the next ones!

DOJO CHALLENGE #2 Winners!

The security of digital innovations is a primary concern for organisations and individuals alike. New ways of testing the safety and quality of digital services emerge and establish themselves, bringing with them new possibilities to shape security. Still, the majority of digital products and services harbour vulnerabilities. It is thus crucial to identify and correct vulnerabilities as fast as possible.

What can we do to protect ourselves? Who should look for vulnerabilities? Should suppliers or users be informed? If so, when and how? These questions have been around ever since we began creating digital products and services. These questions also define a process known as vulnerability disclosure.

The appropriate management of vulnerabilities is vital to reducing digital security risks. The technical community has developed clear guidelines for reporting potentially unknown or harmful security bugs to the proper person or team responsible. Those guidelines are what we call a Vulnerability Disclosure Policy (VDP).

What is a Vulnerability Disclosure Policy (VDP) and why you need one

What is a Vulnerability Disclosure Policy (VDP)? Why do you need a VDP? All the answers in two minutes 👇

The most robust approach to establishing a secure and accessible communication channel with well-intentioned third parties is a stand-alone comprehensive VDP. It is a commitment that your organisation will receive, test, and if need be, fix vulnerabilities notified by security folks external to the business. By publishing a VDP, the organisation establishes rules that these people must respect. If they do, the organisation pledges not to take any legal action against them. This aspect is known as ‘safe harbour’. A VDP is thus a declaration with legal value.

Difference between a VDP and a Bug Bounty program

Often, when discussing what a VDP is, the question about how it differs from a 

 program comes around. These two approaches are complementary yet are not synonyms.

. With a VDP, the organisation provides anyone wishing to report a bug in good faith with a communication channel. Most often, the rewards to ethical hackers are a ‘thank you’, a Hall of Fame mention or a swag.

Bug Bounty program is a proactive approach

. The organisation mobilises the community to search for and identify bugs on strictly defined technical scopes. Under a private program—the majority of cases,—only a fraction of the community participates. Researchers who identify vulnerabilities within a Bug Bounty program receive monetary rewards according to a specific bounty grid.

Why do we insist on this distinction? Well, because it matters. Many Bug Bounty providers publish the VDP and a parallel Bug Bounty program on the same website. The difference between the two approaches is then not clear enough.

Such a set-up may create confusion for both good-faith hackers and the organisation. The mix-up leads to unpleasant situations for everyone involved: Bug Bounty hunters invest time looking for weak points and therefore expect compensation where there is none to expect. This lack of delimitation, in turn, leads to companies ordinarily receiving too many vulnerability reports, causing a lot of work and resource bottlenecks internally.

YesWeHack – the #1 European Bug Bounty & VDP Platform

, we are careful to set clear boundaries. Our approach is to provide the right guidance and tools so that VDP programs prevent mix-ups. Thus, the VDP is published on the company’s own website: it cannot be mixed up with a Bug Bounty program. Hackers can see at a glance that this is a free way to report vulnerabilities.

From an operational point of view, a VDP complements pre-existing security efforts across business lines. It provides tangible input to security operations, incident response, crowdsourced or in-house security auditing and red teams.

It is also right to highlight what VDP does for the vulnerability finders. By promoting and providing a structured and accessible way to report security bugs, such a process enables smooth communication and legal clarity.

So, a properly implemented VDP reduces digital security risks for all parties involved and adds value to your organisation. Industry-standard best practices and solutions are within reach. 

Practical vulnerability disclosure: VDP made easy

 is among the happy few joining the second edition of the 

 program. Tech4Trust is the first Swiss startup acceleration program for digital trust and cybersecurity. Initiated by Switzerland’s prominent public-private partnership 

, the program aims to boost bold and innovative startups that tackle the major challenge of trust in the digital era. An acceleration powerhouse, Tech4Trust connects the participants with relevant potential partners, customers and research institutions.

YesWeHack has been operating in Switzerland since 2018 and has offices in Lausanne (in the canton of Vaud). Many public and private organisations in Switzerland already rely on YesWeHack to secure their assets the agile way through Bug Bounty.

By taking part in the Tech4Trust program, YesWehack will further strengthen its presence in the Swiss ecosystem and the budding Swiss security community.

YesWeHack joins Tech4Trust, Switzerland’s cybersecurity accelerator

 into development and operations processes and tooling. The methodology is relevant to organisations creating their own applications as well as to those acquiring software. Security and risk management professionals need to adapt practices to leverage DevSecOps full benefits. The opportunity to do so matches the challenge—today’s fast-paced digital transformation needs strategies and tools that practitioners can integrate and automate within DevOps.

For frictionless integration of security to happen, tooling is paramount. The ability to integrate and automate various development, security, and operations processes is at the core of a successful DevSecOps implementation. As maturity differs between organisations, appropriate technology is of the essence. Below, we focus on tools our bug bounty platform natively includes thus making it the “sec” part of the DevSecOps toolchain.

DevSecOps: Integrating security from idea to continuous delivery

DevSecOps is integrating security in development and operations. Protecting applications the DevSecOps way best works with a bug bounty.

Security testing for quick and easy remediation

 The traditional security practice of generating and emailing vulnerability reports in document form will not scale in a DevSecOps pipeline.

 Our experience shows that bug bounty provides effortless integration of security reports in the pre-existing DevOps toolkit.

Security testing is a necessary practice as part of an overall security program. The best practice is to implement security testing during development and in both the preproduction and production environments. The security testing in each of these phases varies in complexity and goals, directly involving several roles and teams.

Such a complex interaction and iteration model requires security testing tooling, which produces results that are usable for quick and easy remediation. Also, the report format is homogeneous—a tremendous advantage as it prevents ambiguity, thus streamlining communication across roles. The 

✅ The quality of the findings and that of the suggested remediation is key to adoption by non-security teams.

As a bug bounty program manager, you receive real-time notifications of new submissions. You can then evaluate the report. Our forms enable hunters to provide a fine-tuned description of the vulnerability they are reporting.

✅ Once the vulnerability is accepted as “valid” by the bug bounty program manager, a ticket is created. From there on, each step of the vulnerability management lifecycle is thus logged. For internal and compliance purposes, you have actual proof of identification and remediation for each vulnerability.

✅ Proofs of concept (POCs) are critical in demonstrating the exploitability of vulnerability, thus specifying its anticipated impact on your environment. Often, hunters include a POC in their report. Requesting one is also possible during the vulnerability evaluation phase.

✅ Ease of configuration and effective integration with the existing SDLC toolchain:

When updating a report, select the status “Ask for integration” to transform the report in a backlog ticket in your internal system (JIRA, GitLab, GitHub).

The bug bounty virtuous cycle of security testing avoids providing inaccurate results to development teams. Thus, developers 

 instead of wasting time to determine whether it is real or not.

smooth inclusion of accurate vulnerability reports to the organisation’s toolchain

 creates no friction between application and security teams. Likewise, delays are significantly reduced, thus favouring security adoption by different business lines.

Each vulnerability report comes with a carefully evaluated CVSS score and a priority estimate. These criteria enable smooth 

. Thus, no security skills or capacity gap looms at the horizon.

Whenever a vulnerability is reported, our hunters include technical specifics that a SOC benefits from in further log inspection. Indeed, when encountering a hunter’s reconnaissance and exploration activity, did the SOC team got an alert? Such a virtuous 

 enrich and fine-tune their tools and use cases continuously.

Operational remediation practice aligns with business logic

 web applications) require continuous protection. More often than not, however, business logic does not permit for DevSecOps to patch production in due time.

Our experience shows that bug-bounty-powered vulnerability identification in runtime scenarios best works with virtual patching.

Vulnerability-free design and development-phase security testing are critical yet insufficient. Thankfully, runtime mitigation using WAF, WAAP or RASP exists: enter the so-called virtual patching. This remediation approach temporarily or permanently mitigates specific loopholes.

In a nutshell, a virtual patch is a rule or a set of rules, deployed in the WAF, WAAP or RASP mentioned above, that diminishes a specific vulnerability in software without changing the underlying codebase. Typically, virtual patching comes in handy when in need of an urgent fix. At the same time, a long-term remediation solution is developed. Thus, this type of fix implements a security policy enforcement layer and allows Ops to keep a system running until a complete fix passes tests and approval.

Vulnerability reduction is our bread and butter. So, the 

 bug bounty platform comes with native features to ensure that weaknesses get a fix and that it does not break the system:

✅ After a vulnerability report is evaluated, you can get a virtual patch with the click of a button. Our partner 

✅ Whenever the fix is available, the bug bounty program manager can integrate it and provide it for security testing to the hunter having initially identified the vulnerability. Naturally, those changes are reflected in the backlog.

✅ Whatever the type of patch you deploy, all actions are logged. That sort of ‘changelog’ may be incredibly precious in environments with strong compliance pressure. Kiss goodbye them tedious Excel sheets!

👍 Should the test pass, you can push next in the DevSecOps pipeline.

By leveraging virtual patching solutions, 

implementing an effective temporary solution

 that prevents attacks on a known vulnerability is possible and easily accessible.

 haunt every member of the DevSecOps team. When legacy uses a web interface, a popular database back end or a component whose source code is unavailable or difficult to modify, we all know a disaster is in the making. Virtual patching is especially useful here as it is an optimal and cost-effective way of addressing vulnerabilities.

Deployments of outsourced or off-the-shelf software

 (especially where original source code is unavailable or the supplier is too long to patch) are similar to legacy. Virtual patching comes in handy here too, addressing any security gaps with little effort.

Through the YesWeHack bug bounty platform, a patch that you have requested—virtual as well as originating from the development team—also gets 

to ensure it prevents the exploitability of the vulnerability.

Since patch requests, tests and acceptance are 

, you need no extra effort to maintain visibility over the security level of the application portfolio.

Powering DevSecOps with bug bounty: more treats in store

DevSecOps implies a profound change in the software industry’s culture. Achieving a harmonious interaction between seemingly contrarian positions is no simple feat. Even though design- and development-stage vulnerability inspection grow in adoption, these approaches exclude runtime security needs, where technical mechanisms external to code are at work. Currently, the bulk of the software security industry relies on occasional inspections such as the yearly penetration testing or compliance assessments. Thus, annual occurrences and end-of-cycle inspection are of little help: they create waste, delay learning, slow down overall delivery and fail to reflect realistic threats.

At YesWeHack, our bread and butter are reducing the number of existing vulnerabilities as a way to mitigate risk sustainably. It so comes as no surprise that our work and the tools we develop aim to smoothen the often-challenging interface between Security and Development. Today, a significant part of organisations is at the planning stage of putting “waterfall” behind in favour of an agile approach that integrates security throughout the entire product lifecycle.

Don’t miss a feature: follow our changelog!

As showcased above, bug bounty goes beyond vulnerability identification alone and natively embarks the whole vulnerability management lifecycle toolchain. A growing number of our clients are embedding those tools in their CI/CD; so, we have decided to dedicate an article to how we help them embed security therein. 

Bug Bounty: the business enabler of any DevSecOps toolchain

: triggering an XSS payload restricted to a very short array of usable characters, notably forbidding the use of parenthesis, numbers and dots.

Wait, what? You don’t know the DOJO yet?

 geared towards learning bug exploitation the fun and visual way. You can even create your own challenges there!

The DOJO is the arena where the 4th challenge took place (see the 

We are glad to announce the #5 DOJO Challenge winners list.

Eboda ( in just 2 hours including lunch 😉

 feeds to be notified of the upcoming challenges.

Read on to find the best write-up as well as the challenge author’s recommendations.

You had two possible input to inject malicious code: $age is limited to 2 characters, while $name is heavily filtered with a regex limiting usage payload to Alpha + $ + ` + { or } + / characters only. No parenthesis or dot allowed, somewhat disorienting for Js ;/

We also asked you to produce a qualified write-up report explaining the logic allowing such exploitation. This write-up serves two purposes:

 Report was particularly efficient in detailing the exploitation logic, we thus decided to reproduce it in here

For clarity we publish a single report, making a choice was hard.

Cross-site scripting (XSS) is a vulnerability that allows an attacker to run JavaScript in a victim browser context. The attacker can thus leverage it to take action on behalf of the victim. Most of the time, an XSS allows to steal a session and to take over an account.

As per the description of the challenge, the goal is to trigger an XSS in the DOJO Playground using two parameters: $age and $name.

This new challenge has a more restrictive filter in $name filter. Only a very limit number of characters are accepted:

a single character in the range between a (index 97) and z (index 122) (case-insensitive)

matches a single character in the list $``{}/

We can not use the . (dot) and parentheses () that are needed to call a function or access an object property.

, but I am stuck with the lack of some characters 🙁

After to take a break, I see the light… Maybe I can use 

. Now I can call the alert, but can not access to window.name.

Now I need to find a way to exec alert(window.name).

Let’s look to the Tagged templates again. Tags allow you to parse template literals with a function. The first argument of a tag function contains an array of string values. The remaining arguments are related to the expressions.

I need to find a way to handle the first parameter array!

… We can try to pass the array as the first parameter and the implementation in the last parameter. I also tried to use the eval, but it always returns an array (the same that we pass by parameter) and do not exec the code.

Normally, we create a new instance of Function with the new keyword, but we can not use the character (space). The alternative is to create the function and call it:

But we can not use the parenthesis character. The alternative is to call the function as tag template:

The solution that I found was to use base64 and use the function atob to decode it before pass it to the Function. First I encode the payload alert(window.name) but the result contained numbers, so I tried to encode only alert(name) that it only contained letters YWxlcnQobmFtZSk. We can use only name because of the window is the global scope.

If you want to learn more about template literal in javascript, you can read this well detailed article on MDN: 

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

DOJO CHALLENGE #5 Winners!

In a post-COVID-19 world, where entire chunks of our lives have moved online, cybersecurity is more critical than ever. One of the impacts of the coronavirus pandemic is to make cybersecurity spending unpredictable. While the business environment has changed because of COVID-19, many of the challenges that companies face remain. The pandemic has also upended and hastened the pre-existent digital transformation. Such uncertainties and complexity also cause 

, a general discouragement amongst CISOs and information security leaders who see their challenges pile up and their strength depleted.

Recent discussions with cybersecurity leaders suggest they fear significant budget and staff cuts. Such anticipated grim picture makes it harder to face the top two challenges for business today, namely the complexity of technological environments and a lack of skilled cybersecurity professionals. How to fulfil these two priorities with leaner resources?

Those recent discussions also surface an interesting view: 

 answers more questions than we suspect, way beyond the quotidian operational ones. So, we devise a structured list of recommendations to pinpoint actions to help achieve the two cybersecurity priorities.

Below, we set out the engagement approaches and process changes that CISOs have found useful in defining priorities and ways to fulfil them with leaner budgets.

More threats, less money? Not all is lost

 companies anywhere from 7.2 per cent to 15.2 per cent of their IT budgets on cybersecurity in any given year. These figures reflect specific changes in cyber spend—IT costs have shifted from CapEx (

expenses on day-to-day operations, the “run”). In such contexts, cutting IT–thus, security–spend gets truly challenging.

Whether those figures tell the whole story is a different question though. Defining the cybersecurity budget as a part of the IT budget is not a universal rule. A significant portion of security spending occurs within business lines. Those need specific digital tools; risk management and data security are thus baked into the purchasing process business lines follow.

Cybersecurity budgets are thus a more vivid landscape than the mere proportion of an organisation’s IT expenditure. The operating models of post-COVID-19 security spending focus on prioritising a business-centric, process-driven and transparent allocation of resources. Such an alignment is natural: at the end of the day, CISOs only dispose of finite resources, so they need to decide what project gets priority depending on the business’s pressing needs.

Accordingly, security technology and service providers also shift priorities to support current needs: business continuity, remote work and planning for the transition to the next normal. Rationalising and optimising cybersecurity expenditure, thus demands transparency and efficiency. New models such as pay-per-usage (

 Splunk) or pay-per-vulnerability (bug bounty) are in the spotlight and offer a direct and measurable ROI.

Those come with no hidden costs: running bug bounty programs means that clients pay for information worthwhile according to their priorities. The approach also succeeds because CISOs do not handle a myriad of full-blown projects; 

 a penetration test comes with planning strings attached: kick-offs, milestones, presentation meeting, etc.

Since we launched our Bug Bounty program, we’ve upped our security game: we found new vulnerabilities. We were able to fix them, and the level of security on these applications is now a cut above. Ultimately, that’s what a CISO should be aiming for: not just compliance, but enhanced security.

The CISO of a major European financial institution

Achieving (management) appreciation of cybersecurity success

Bug bounty thus rationalises the security audit spending and focuses it on what matters–aligning costs to core business risk management. Our discussions with cybersecurity leaders also highlight that leveraging crowdsourced security reduces ‘CISO fatigue’. The latter mainly results from a corrosive environment of misalignment between cybersecurity spending and the enterprise’s strategic objectives, friction with business partners and skill deficiency.

Our discussions with CISOs and cybersecurity leaders surface that crowdsourced security diversifies the available talent pool and leverages these additional roles. Bringing in new, complementary skills through collaboration between ethical hackers and relevant colleagues helps to create ‘unicorn teams’. Thus, a combination of individuals forms a sustainable team, one that can fulfil cybersecurity priorities on budget.

A more effective team is visible to management—showcasing performance gets more accessible, too. A long-lived, pain-staking topic when defending a security budget is how well the money is spent. Resource allocation decisions, both past and present, are much easier to uphold when evidence and transparency support them: that many vulnerabilities were identified, these many were fixed. Such a candid yet confident approach strengthens interactions with management and offers concrete opportunities for stakeholder input.

Reduce digital risk efficiently by enabling security dexterity

As businesses expand their digital assets, cybersecurity faces intensified competition for time and expertise. Similarly, scrutiny into cyber resource allocation decisions heightens. In response, CISOs must explore more business-centric, process-driven and transparent approaches. Those security leaders prioritise resources for their enterprise’s most urgent needs.

To meet this challenge, CISOs must modernise their portfolio prioritisation processes and focus on enabling security dexterity. In a context where security budgets can be challenged, it is vital to show value to business lines by offering practical solutions. The current troublesome context is precisely the opportunity to think out of the box. Now is the time for cybersecurity leaders to show an ability to innovate as a way to stand up to the broader COVID-19-accelerated digital transformation.

Such an outlook seems easier said than done. The good news is: it is achievable. The better news: it is achievable thanks to bug bounty. As far as expertise goes, the latter brings about the realistic exploration of a technology by a vast crowd of ethical hackers, each with their unique point of view.

Besides, through its security-as-a-service approach, bug bounty also optimises vendor management. Forget about the range of penetration testing providers, each with their processes and deliverables, making CISOs and security managers dedicate a significant amount of time coordinating and consolidating the heterogeneous outputs. Bug bounty streamlines vulnerability management and decreases operational costs by reducing the number of vendors CISOs deal with.

 rationalise the security audit spending and focus it on what matters–aligning costs to core business risk management.

Crowdsourced security makes cyber spend more transparent and enables (management) measurement of the CISO effort.

Bug bounty powers tomorrow’s leader’s digital dexterity by creating a ‘unicorn team’ that fulfils the cybersecurity priorities on budget.

Cybersecurity spending: fulfil priorities with leaner resources

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 Customer Success team is there to reassure and guide them, to ensure their bug bounty program will succeed and fulfil their goals and expectations.

 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, 

and the best practices to adopt when it comes to crowdsourced security.

Hi Selim, could you please explain to us quickly your role within YesWehack?

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.

Can you explain the main steps before the launch of a Bug Bounty program?

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.

. 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.

. 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.

Clearly defined processes and workflows ✔️

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

What to do, what to avoid while writing a program? 

. 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, 

 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:

: what can be done and whatnot while testing the scopes;

: 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.

The YesWeHack Blog

DOJO CHALLENGE #2 Winners!

Practical vulnerability disclosure: VDP made easy

YesWeHack joins Tech4Trust, Switzerland’s cybersecurity accelerator

DOJO CHALLENGE #2 Winners!

Bug Bounty: the business enabler of any DevSecOps toolchain

DOJO CHALLENGE #5 Winners!

Cybersecurity spending: fulfil priorities with leaner resources

Bug Bounty: the business enabler of any DevSecOps toolchain

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

Learn ethical hacking: Insights from YesWeHackEDU users

Coordinated Vulnerability Disclosure policy for a safer cyberspace

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

Don't wait for threats to strike

Produits

Chercheurs

Ressources

A propos

Suivez-nous