Launch HN: Federacy (YC S18) – bug bounties for startups

Hey all, we're James and William, founders of Federacy (YC S18). We're building a bug bounty platform for startups. (https://www.federacy.com)

I was an early engineer at MoPub, responsible for security and infrastructure. By the time we were acquired by Twitter, we were 20+ engineers, but growing so fast that building software and systems securely was almost an impossible task. I found that there were never enough hands; I couldn’t peel engineers from revenue-driving features and it was really difficult to find contract or full-time security engineers.

William and I started Federacy to make it easier for startups to secure themselves. We think the key is to pair startups with extremely talented, outside security researchers to test their applications for vulnerabilities, review code, and help implement best practices—essentially serving as an outsourced CISO.

We saw that the best security minds we knew either weren't interested in a full-time role for a single company, weren’t able to work in the United States, or already had day jobs at the largest Internet companies. We thought that if we provided an efficient, no-bullshit way for them to do work that they enjoy, make a real difference in how startups secure themselves, and make money while honing their skills, we could unlock a huge amount of talent that wasn’t accessible previously.

We have a lot of respect for what HackerOne and BugCrowd have built, but they are focused on serving mostly enterprise companies with large engineering and security teams, who can afford their services. Their revenue comes largely from triaging the high volume of low-quality and automated/spam bug reports that come through their platforms. These services can be in the six figure range. It may be a good business, but that isn’t where our passion lies.

Startups can’t afford these services and the burden of triaging low-quality bug reports can completely overwhelm even the best dev teams, leaving them worse off than they started.

We think there is a better way:

• We hand-pair startups with a small team of pre-vetted researchers who are subject matter experts in your stack.

• Researchers test your infrastructure for vulnerabilities in an initial scan, and work closely with you to resolve issues and implement best practices.

• Your program can be private, where only you and the researchers you approve will have access to your program. You don’t have to provide source code and all initial testing is done with only the information and access your normal users have.

• We create your program for you and have you up and running in 5 minutes (or you can self-serve, if you prefer).

• We only charge for results (when a researcher finds a vulnerability).

We just started building a couple months ago and are looking for early feedback. Here’s an invite link we made for HN:

https://www.federacy.com/signup?invitation_id=3b4d06c5-ac02-...

We’ll be around all day to chat and are very happy to answer any questions as well as discuss how we built our product, security-related topics (systems automation, vulnerability reporting, coping with imposter syndrome, etc.), what it's like building a startup with family (we’re twin brothers), or anything in between.

Some specific questions we have:

If you’re familiar with other bug bounty platforms, are there any issues we can tackle early on that made the experience frustrating for you?

Would you consider contracting an outsourced CISO or a pentest with a security researcher that has reported vulnerabilities to you through your bug bounty program?

We've used HackerOne at a startup I work at (10-20 employees). We had to turn it off because we were getting bombarded every couple days with the same issues, that were just run by crackers/hackers running basic pen test scripts. They all seemed to have the same toolkit, and would just run the same tests and report the same bugs. Most of which were either invalid, or just not a priority and, so, a waste of our time to read. The write-up of the bug was also poor, with poor English, and this causes wasted time..

Before signing up for another bug bounty program I'd want to know that:

1) The testers were not mostly just amateur crackers running the same toolkit on 100 sites per day, and the same toolkit that 10 testers ran yesterday.

2) The amount of dupe reports was basically 0.. If we get a bug reported and we ignore it, and make zero response, we still do not want to get the same report 10 times over the next 2 months.

3) The write-ups should have proper English, good grammar, and be very clear.

4) If a user reports 10 bugs, and we only want to pay for 1, that should be totally fine. The other 9 are either dupes that we have ignored before, or new reports that are just not a priority or worth looking at.

5) We basically never want to get into a negotiation with the hackers over if a payout should be $2000 because 10 bugs were reported when we know of all the bugs and, basically, don't value them.

Your experience is exactly why we're building Federacy.

Bug bounties can be an incredibly efficient way to work with outside security researchers to find vulnerabilities, test for best practices, etc., but done poorly, can cause more damage then they help. We want to make them work for startups as well as they do for companies like Dropbox, Shopify, and Google. We have our work cut out for us -- but if we're successful, we think it could materially improve how startups secure themselves.

All the dev teams we've been part of share the same challenges. We're always overburdened with work on revenue-producing features, so being flooded with more work that ultimately doesn't add much value in securing our software is the last thing we want.

Right now our solution for spam, dupes, and low-quality reports is to be extremely selective with the security researchers we allow on the platform.

We're launching in private beta so James and I can hand-pair researchers, help companies write their VRP, and review every vulnerability report.

Other ideas we’re working on:

- Very clear “Known Issues” / “Not Issue/Out of Scope” sections

- De-duping based on comparing report attributes

- Utilizing machine learning to improve de-duping based on description of vulnerability

- Collaboration. Encouraging companies to look at their approved outside researchers as a part of their team and building tools to facilitate this

Do you think any of these would help? Are there other ideas we should be focusing on that might solve these problems more efficiently?

We've tossed around ideas like this -- including something similar to how Numerai uses staking for their data science competitions. The security researcher would stake a small amount based on their confidence that the report is an impactful vulnerability.

I think it's an interesting idea, but could be complicated to get right. We’re also wary of creating barriers that are too prohibitive for some of the really great and hard-working researchers in the world.

I think an easy solution may be to build good vetting tools and a thorough process: a short application, technical interview, and/or trial periods for new researchers. Right now though, we’re personally reviewing every researcher. :)

A big part of this, too, is providing the environment where researchers can learn and emphasize their existing contributions. I think there’s a lot we can do there, while still allowing researchers to provide a lot of value.

What do you think?

That'd be interesting--a small, maybe even just $1-10, deposit that gets refunded if the bug is legitimate.

I don't think punishing dupes is a good idea though, because a researcher has no idea (and should have no idea) whether their bug has been found before, so dupes should probably still result in a refund.

However, as a kid who has no credit card, but has found some pretty spicy bugs (and gotten rewarded for them), it would make it impossible for me to report them.