A bug bounty program is where you offer some level of defined reward structure to individuals (e.g. “the crowd”) who are able to successfully report unique security issues with reasonable impact against in-scope assets to your organization. These programs may be limited or unlimited in scope, may offer varying types of rewards (swag vs. dollars, etc), and may be open to the public, or selective in terms of the people that are able to participate.

If that seems like a mouthful, don’t worry. We’ll break it down here:

If your goal is to have a more secure organization, and running a bug bounty is the single most effective thing you can do to identify security issues (where identifying is the first step in eventually remediating them, and thereby reducing your risk), then it’s harder to answer why you would not want to have bug bounty program.

Perhaps pricing is a concern - well, maybe that used to be a concern in an era where the market was dominated by Bugcrowd and HackerOne… but because we’re on a mission to democratize access to crowdsourced security and not enrich our wallets, we offer bounty programs at a fraction of the price of other organizations in the space. If cost is a significant concern, we’ll even run your program at-cost if you qualify. Furthermore, as it relates to paying for findings, you only have to pay for findings that are valid and in-scope, so there’s no risk of blowing out your budget on issues that aren’t worth anything to you. If you spend money on findings, it’s because you’re getting value.

So again, the harder question to answer is “why wouldn’t you want to have a bug bounty program in some way shape or form?”

Another common concern (often called “crowdfear”) is having trepidation around inviting people to hack on your assets, we’re glad you asked, and that’s what we’ll answer in the next question down…

In short: yes.

The longer answer starts with the reminder that whether or not you condone it, there are bad actors trying to hack you right now. So, if we keep in mind that bad actors are going to hack us no matter what, then it stands to reason that we should also invite the good actors to help us find the vulnerabilities before the bad actors do. In this way, by using the crowd we’re more leveling the playing field than anything… we’re bringing in the good guys to help hack ourselves first.

Paradoxically, in this way, by inviting good guys to hack us, we’re able to make ourselves more resilient to attacks from the bad guys, which reduces our risk and diminishes the probability of getting hacked. Sounds like a win-win.

It's pretty straightforward: (1) you go through the onboarding flow, which will select the assets, the program type (private vs. public, etc, and so on); (2) based on what happens there, you provide credentials and/or access for participants; (3) we setup a launch date/time; (4) you pre-fund the bounty "pool" (e.g. the reward dollars) and pick your preferred payment structure (annual, quarterly, pay-as-you-go); (5) the program launches when the set date arrives; (6) you receive reports! (7) You review and reward the reports that are valid, in-scope, non-duplicates, and have security impact. And finally, (8) you make program adjustments over time to meet your goals and objectives.

There are more nuances in there, but that's the high-level view on things!

It's true, you could do this on your own - and one could also ostensibly build a house using no power tools. It's absolutely possible, it’s just a whole lot easier if you use a tool that’s made for the job… and that’s what we do. We make it a whole lot easier to ingest the information and to process it - all of which leads to a quicker resolution. Additionally, we have connections to the crowd and data on past performance that we can use to add the right people to your program. There’s a lot we’ve built into the DarkHorse platform that enables organizations to get started more quickly, avoid a lot of the common pitfalls, and to operate more efficiently as a result. If you prefer to run a public or private bounty via an email and spreadsheet, there's nothing inherently wrong with that - we've just built a platform that can help, and tried to make it affordable, so that nobody has a reason to not have a bug bounty, ever again.

And by focusing on our platform-managed approach, combined with our goal to make it accessible to everyone, an additionally corollary to using DarkHorse, is that you'll have more money to spend on bounties, allowing you to offer higher rewards to incentivize more testers and testing, leading to better outcomes. It's a win-win-win for everyone involved!

By way of example, if you had $55k allocated to run a bounty program this year, including bounties, you'd likely have to spend over half of that on Bugcrowd or HackerOne on management fees alone - meaning that at an average rate of ~$1000 per valid finding, you'd only be able to pay ~28 reports a year with the remaining funds (assuming half went to management fees). With DarkHorse, you'd be able to pay for 49! That's a nearly 60% increase... meaning you can spend the same amount of monney, and get 60% more reduction in risk. Granted, things are rarely that linear - so the reality would be closer to (1) having more money for rewards would allow you to offer higher rewards, which would (2) lead to both more AND better findings (though possibly not 60% more).

Additionally, though DarkHorse is new to the scene, in the coming months we'll be unveiling SDLC integrations (Jira, etc) for upstreaming findings, and we also have a number of different product lines as well, all in one place. In this way, DarkHorse can become your single pane of glass for all your offensive security vulnerabilities - pentest, bug bounty, and VDP... one more way to make your life just a little easier.

There’s nothing wrong with using someone else, and if it means you’ll be running a bounty program, then we’re happy you’re doing it, no matter where you do it. Our mission statement (to make crowdsourced and offensive security accessible and affordable to all) precludes the idea of 'competition' in the traditional sense. So long as people have access to services that we think are essential for improving their security posture, we have no quarrel around who they use or how they do it. Full stop.

As to why DarkHorse… well, if we’re being honest, it probably comes down to price. HackerOne and Bugcrowd certainly have the leg up on us in terms of being around for a lot longer, and as a result, they’ve got more integrations and other things we don’t (yet) have. For instance, they’ve got APIs, webhooks, and some other things that we’ll get to as we go along. They are also more human-services oriented with their triage teams, multiple layers of customer success, and so on. They’ve got more swag, more employees, way more salespeople, offices, big events, more VC money, and on and on and on.

But all of that costs money - as a function of who we are, we built an automation-first platform. What that means is that we see a lot of that stuff as extraneous, and we’ve automated it out. We’ve simplified, simplified, simplified - so that what’s left is a platform that’s simple and definitely un-fancy… but it’s also a lot-lot-lot cheaper. Shoot, we’re giving away bounties VDPs for free! And even on the paid tiers, we effectively offer our platform for less than a cup of cofee per day.

At DarkHorse, we don’t need a giant sales team, and we aren’t prioritizing providing services. We’re building a platform that will enable you to service things yourself, and if you need help, we’re here.

Sure, there are some features they have that we don’t, but we also have some features that they don’t, including remarkably transparent pricing, the most robust automated onboarding in the industry, the only platform that has built in the ability for streamlined communication between testers and clients, and a platform that automates tasks and actions in ways that nobody else is doing. All of these features are built with you at the center - other platforms need you to need them. We want you to not need us at all, and to let the platform be all that you need.

And by focusing on our platform-managed approach, combined with our goal to make it accessible to everyone, an additionally benefit to using DarkHorse, is that you'll have more money to spend on bounties, allowing you to offer higher rewards to incentivize more testers and testing, leading to better outcomes. It's a win-win-win for everyone involved!

By way of example, if you had $55k allocated to run a bounty program this year, including bounties, you'd likely have to spend over half of that on Bugcrowd or HackerOne on management fees alone - meaning that at an average rate of ~$1000 per valid finding, you'd only be able to pay ~28 reports a year with the remaining funds (assuming half went to management fees). With DarkHorse, you'd be able to pay for 50! That's a nearly 60% increase... meaning you can spend the same amount of money, and get 60% more reduction in risk. Granted, things are rarely that linear - so the reality would be closer to (1) having more money for rewards would allow you to offer higher rewards, which would (2) lead to both more AND better findings (though possibly not 60% more).

Oh! And did we mention that we’re the ONLY platform that provides a methodology checklist to testers on bug bounties? Some platforms have light methodology checklists for pentesting, but what about with bounties? It helps the testers as they’re testing, and provides more transparency to you in terms of what’s been tested. This more than anything helps showcase what DarkHorse is about - we’re not trying to be another HackerOne or Bugcrowd - we may be new to the party, but we’re not in the game of following, we’re leading and blazing our own path, from day one.

Finally, we’re happy to also offer services, but again, that’s not really what we set out to do. So, if you want to run your own program, with some help from an intelligent and affordable platform built by people who have done it hundreds-to-thousands of times by hand, DarkHorse is for you. If you want to pay 10-20x the price (that’s not a typo), we’re happy to set you up with a referral. In the end, the only decision we’d strongly caution against is choosing not to run a bounty program at all.

That said, it's your decision around your perceived ROI for the services and software that you're paying for. Some people may want all the bells and whistles of a Bugcrowd or HackerOne, and again, our goal is not and will not be to compete with them. Our goal is to democratize crowdsourced and offensive security, making it accessible and affordable for everyone. We personally think our solution will meet the needs of a great many, many organizations, and that DarkHorse provides the highest amount of ROI for the lowest cost - allowing you to save cash that can then be re-deployed within your security organization to the areas that need it the most - but again, we're not trying build a giant services org, cater to the high end, or maximize for profit, we're trying to make this accessible for everyone.

We’re glad you asked! The main difference is that a bug bounty offers some (any) type of incentive. As soon as there’s an incentive for people to test, it’s a bug bounty. If it’s people responsibly reporting issues without any expectation of payment or dispensation, then it’s a VDP.

The best way to think about this is that a VDP is passive (like insurance - it’s only triggered when it’s being used), while a bug bounty is active - encouraging people to actively look for risks and report them. It goes without saying, but the active approach will always net more findings and value.

A self-managed program is one where you manage all the aspects of the program by yourself. This could be as extensive as not using a platform at all, or even using a platform, but not getting any support in terms of how the program should be managed. You kind of just have to figure it out for yourself. There is one platform where this is pretty common.

A managed program is one where the services teams at the platform provider add an additional layer of human-based guidance and support throughout the sales, onboarding, triage, support, and day-to-day operations. However, quality and consistency can be lacking, since you have a wide range of individuals touching the account. Additionally, all of these persons and the services they provide are wrapped up into a much higher average cost, even if they provide little-to-no value.

A platform-managed program is one that takes all that the best humans know about running a program successfully, and then makes it programmatic. Instead of having to pay for the costs of (and this is not hyperbole) an Account Executive, Sales Engineer, Business Development Representative, Account Manager, Technical Customer Success Manager, Onboarding Engineer, Solutions Architect, Support Engineer, Triage Engineer, and more… and then of course there’s all their bosses, and so on. Instead of having all those costs rolled up into your bill, what if 90% of those roles were automated to provide consistency and scale, while also allowing you to pick and choose where you want and need support along the way? Then pass those savings along to you. That’s platform-management, and that’s what we’re building here at DarkHorse.

I’m sold! When can I start?!?!

You’re not wrong. The unfortunate reality is that it paradoxically costs money to send money. By way of explanation, we have to pay ~2% on all payments to our payment vendor, and then on top of that, there’s another ~2% (on average) for currency conversion (which is the vast majority of payments). Then we also have to cover the costs of AML / sanctions checks + tax document collection – which varies pretty significantly in terms of how much it costs to process (some tax document collection can take hours, and others mere seconds, etc). As an example, if we process a single reward for $100 for an organization on a free plan, at 7%, that’s only $7 to DarkHorse. Between all of the above costs, it’s a near-guarantee that we lose money on a transaction like that – not to mention development and maintenance costs behind the platform as a whole. But that’s ok – again, we’re here to help move the industry forward, not to maximize profit.

At the end of the day, DarkHorse provides as much value as we can, as affordably as is possible, to further our mission of making crowdsourced and offensive security accessible and affordable for all.

That’s a reasonable assumption to make, but (1) our margins are extremely thin-to-non-existent. Getting an extra few dollars for ourselves doesn’t really mesh with our mission – which is to make this accessible and affordable for everyone. And (2) we’re going to advocate for higher payouts not for ourselves – but for the success of yourself. We’re not going to tell you to reward a million dollars when offering ten thousand would do. That said, we’re also not going to recommend five hundred, when ten thousand is what we believe is necessary. We’re not clairvoyants, but we’ll do our level best to give you the best guidance we can. Again, we’re not in the business of hurting people – we’re here to help.

First and foremost: honesty and trust. As documented elsewhere, we'd be more likely to make more money working at McDonald's for the next year than on this platform. If we wanted money, we could have stayed in our high paying jobs, or even just found another high paying role. Our reputation and dignity are too high to defraud customers out of their money - doing so would irreparably damage what we're trying to do... which is to make crowdsourced and offensive security accessible and affordable for everyone.

Secondarily, if you do receive large numbers of spammed reports, let us know, and we'll make sure you aren't charged for them. Again, our goal is to bring people into the world of crowdsourced and offensive security - not to push them away. Do note that some level of noise is inherent in running a bounty program - so, in our view, a random dude sending a useless clickjacking report doesn't count as spam. However, someone sending the same report 100s of times does count as spam. But if you feel it's spam, feel free to reach out, and we'd be happy to review it.

It's covered in a few places, but there are a few reasons:

1. We don't believe it's as economical for organizations as you may have been led to believe. We started building out a triage function for DarkHorse, but quickly realized that it's actually not as advantageous as we initially thought. Take this quick thought exercise:
• 20-30% of reports wind up being valid. This means that out the gate you still have to do at least 20-30% of the total work involved in triage, since you need to validate those reports yourself, etc.
• Anyone who has managed a program also knows that there's a number of reports that need their input pre-triage as well... with questions from the triagers asking if things are in scope, if it's intended, and so forth. We'll call this and additional 10% of reports.
• Finally, there are a small percentage of reports that get mis-triaged, and need your oversight. We'll call this another 5% of reports.
• So, even with triage in place, we're up to touching approximately 35%-45% of all reports, no matter what.
• Then also remember that the other remaining reports are duplicates, out-of-scopes, not-applicaples, and so forth. And then also keep in mind that those types of reports tend to take less than half the effort of evaluating a valid report.
• Adjusted for effort, triage is charging for 100% of the work, but despite that, you are still required to do over 50% of the work in the end. So your real adjusted savings in paying for triage is closer to 50% (or less), in terms of work reduction.
• While your mileage may vary, in our opinion, getting 50% of the value for 100% of the price isn't particularly economically efficient. And for that reason, we don't offer triage by default. Were it our security program, we'd put our funds to use elsewhere, and want to offer our clients the same courtesty.
2. Secondarily, the mission of DarkHorse is to make crowdsourced and offensive security accessible and affordable for everyone. In our view, building a services organization is antithetical to that goal. Running services means having to handle more personnel, and the issues that come with personnel, etc - and before we knew it, we'd be spending all our time managing the services org... instead of staying true to our mission. So this is us staying true to our mission. Nothing against triage - and it's immensely valuable for many, many organizations. It's just not what we're focused on right now.

Sure! Here ya go!