 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 three things in one: a learning tool, training platform and a playground.

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:

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.

 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.

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

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.

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.

All right, now that the program’s up and running, how do you ensure it runs smoothly? 

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:

: how comfortable are you with the current flow of reports?

: how relevant and useful were the last reports received?

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

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.

What are the best practices to avoid losing attractiveness to researchers?

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:

 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 (

 is it really a duplicate?). Being fair does not mean being overly generous; it just means being fair.

 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.


 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. 

 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. 


 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. 

How do you manage the relationship between clients and researchers? 

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!

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

, providing a complete environment to learning ethical hacking. YesWeHackEDU is the educational portal of our Bug Bounty platform and a unique training ecosystem on cybersecurity best practices. A global Bug Bounty leader, we have leveraged our expertise in coordinated vulnerability disclosure and our ecosystem of clients and researchers to create the world’s first educational Bug Bounty platform. 

 thus allows users to practice vulnerability hunting and management in real-world scenarios, as they would do in production environments.

The COVID19 pandemic kept students away from the classroom; hence 

 decided to provide free YesWeHackEDU licenses to all schools and universities. Doing so enabled teachers to resume instilling cybersecurity skills despite the pandemic and through an innovative platform.

Providing two-month free licenses for YesWeHackEDU

 resulted in more than 3,000 student accounts enrolled in 180-plus schools and universities around the world. We have been learning a lot from the ways those budding talents perused the platform. So, we sat down with representatives from universities—here’s to fresh insights on how one learns ethical hacking with YesWeHackEDU.

 is the Head of the IT curriculum in charge of the cybersecurity section at 

 is the Head of Cybersecurity and Network in charge of the cybersecurity section at 

 is a Lecturer at School of Computing at Singapore Polytechnic.

What motivated you to include the YesWeHackEDU platform in the curriculum you lead?

 I was already familiar with Bug Bounty, and I heard about YesWeHackEDU from a colleague. The two-month free licenses offer was really timely; we needed to make a pedagogical change during that period. With the pandemic, we needed to change the way of teaching to keep the students involved and focused. Of course, I knew what I was getting into. YesWeHack has an excellent reputation, so I knew the platform would be up to standard.

last September, and it was a great success. Our students greatly enjoyed the teaching and the challenges on the bug hunting exercise. Following this, our teaching team decided to evaluate the YesWeHackEDU platform to see how it can be integrated into our curriculum and take into consideration the learning experience of the students. We capitalized on the “COVID offer” to make our first steps with the platform.

 Among different topics in the curriculum, our students also learn web programming. So, they need to be aware of the potential problems in those applications. Learning about web application vulnerabilities is thus part of the cybersecurity curriculum.

How did you introduce YesWeHackEDU in your school? What was the students’ reaction?

 Getting started was very easy thanks to the provided documentation. I invited students from all grades. I also told them that those able to find bugs and who would give a proper report would get one to two points on their lowest grade (depending on the quality of the work submitted).

 We kicked off by providing the first scenario to 80 graduate students. They had to submit their reports to me, and I was in charge of qualifying them. The students who took over the platform immediately embraced its format. They were highly motivated and committed to the platform without any problem. Indeed, the platform and the scenarios are what they would be facing in an actual business environment.

 The freshmen rushed to the platform; they thought it was awesome even though it was a little bit complicated for them. The vulnerabilities are very well thought out for beginners, even with the instructions, they were challenging. The students spent a lot of time poking around though, trying to develop their logical sense and so on, which is very good.

; they were like: “oh no, more extra work…”. Still, a few students, especially those in apprenticeship, spent time on hunting on YesWeHackEDU and had excellent results. A student interning at Airbus used to do this on an internal company platform. He found all vulnerabilities in one weekend and told me he had a wonderful time.

The juniors were best equipped for this exercise. Still, they could not participate as at the time we were launching YesWeHackEDU, they were in the process of completing their OCSP.

In your opinion, what are YesWeHackEDU’s main strengths?

 YesWeHackEDU offers an ambitious and exciting program. It allows students to face real-world cases from actual cybersecurity scenarios. Allowing our students to deal with the issues that companies face is the main strength of YesWeHackEDU.

An example of a vulnerable website homepage on a dedicated training environment.

YesWeHackEDU makes it easy to confront them with a wide range of actual scenarios and enrich their cybersecurity culture. The more real-world cases they face, the faster they acquire a certain level of expertise in solving the problems they encounter. In short, we instil them with the right instincts to detect and address vulnerabilities.

 The students’ YesWeHackEDU instance is on the Internet, so it spares us the trouble of having to set it up locally, which is the case for other platforms. On the content side, the platform covers specific web vulnerabilities. Thus, we can expose the students to different types of bugs in contemporary web applications.

 For beginners, it is very well done. You have all the documentation you need. There are several paths: some obvious and some less so. From the teacher’s point of view, the platform is great, too. There are Bug Bounty report templates so you can see what you can expect and also some suggested solutions for the instructors.

Additionally, you can interact with the students as you would with hunters on an actual Bug Bounty program. In that aspect, the tool is very well designed. I asked some of the students to rewrite their reports and make them more accurate. I expected them to produce qualitative reports, to a level which a company would expect, with a POC, like in a real-world context. For the students who played along, it clearly illustrated how a professional Bug Bounty platform works.

An example of a vulnerability reporting timeline on a training environment.

What is also really great about YesWeHackEDU is that there are individual instances per student. Thus, one will not break everything for others. Focusing on the development of expertise instead of managing hiccups with the tool is a huge advantage.

And finally, the real advantage is that it is all turnkey: the platform is easy to handle, and – importantly – it’s not overpriced. It’s created by Bug Bounty experts and obviously, infrastructure specialists too. The product is top-notch.

What does YesWeHackEDU bring to your teaching methods?

YesWeHackEDU challenges students with real-life scenarios. Something that doesn’t exist elsewhere. The platform allows us to consolidate our programs with access to a flexible and modular tool specialized in Bug Bounty education and more broadly in cybersecurity.

The program allows us to start with a very guided and supervised approach. Then, it is effortless to leave the students to their own devices once they are capable and thus encourage them to train on their own. Our pedagogical vision is to encourage learning through experimentation. YesWeHackEDU enables that approach throughout the entire Bug Bounty value chain.

If we used YesWeHackEDU from the beginning of the school year, we could imagine that the experienced graduate students would take over the role of program managers and the juniors and seniors would act as ethical hackers. Not only does this type of approach create healthy competition among students. It also allows students to learn how to disclose vulnerabilities and how to manage Bug Bounty programs as they might do in their professional lives. Our students have very technical backgrounds. Teaching them how to manage and organize Bug Bounty programs undeniably gives them the managerial edge they will need in the future.

The YesWeHack Blog

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

DevSecOps: Integrating security from idea to continuous delivery

Boosting E-Commerce Security: PrestaShop's Success with YesWeHack's Public Bug Bounty Program

Presenting The Pwning-Machine, a versatile and easy to setup Bug bounty environment.

DevSecOps: Integrating security from idea to continuous delivery

Don't wait for threats to strike

Produits

Chercheurs

Ressources

A propos

Suivez-nous