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

I think you started a month after I left. We built a lot at MoPub in a short period of time and when we were acquired I had a mile-long backlog. The Twitter security team was great though and built a war-room during integration. We worked some intense hours leading up to the IPO and over the Holidays, and I’m proud of the work we all did. We migrated a sprawling stack that supported what was then the largest mobile ad exchange and billions of sub-second auctions over just a few weeks. Most of the MoPub team transitioned to other projects and teams quickly though and I left not that long after.

Totally agree that it starts at the top. If the C-level doesn’t care, there just won’t be the resources it takes to build good, secure software. We intend to focus on supporting companies who do care, and we think this focus will also impact how companies using Federacy interact with researchers. We want outside researchers to be viewed as allies, not as a burden.

Have any thoughts on how we can best accomplish this?

That is a model that has been shaped from the experience of many programs and has a clear, "yes this is an issue but no you're not getting paid" level which is important for avoiding thousands of time-wasting reports such as non-perfect HTTPS headers, etc.

I'd be interested in hearing how you plan to deal with duplcate reports. This is an area that hackerone does better than bugcrowd. Hackerone is more interested in disclosure and getting reports to a point where they can be disclosed. If a bug is marked duplicate you are given access to the original report which prevents falsely marking duplicates to avoid bounties.

We're also still brainstorming and looking for good ideas on how to handle duplicate reports. At this point, we're tackling it by vetting researchers and helping with the ones who ignore 'Known Issues' and out of scope limitations. Like HackerOne, we're very interested in encouraging companies to disclose their vulnerabilities, because these disclosures are important to their users, the people who may build on top of any service they offer, and the researchers who are being given public credit.

In regard to a company marking a bug a duplicate to avoid bounties, those are definitely not the type of companies we want to work with. I'm not sure that technical solutions to mitigate that sort of behavior is necessary when we can curate those who have access to the platform. We’re going to keep a high quality of researchers and companies -- and it goes both ways.

Our Vulnerability Disclosure Policy Template, which is based primarily on Chris Evan's work @ Dropbox, and is inspired by a bunch of other well-written programs too, puts full control of payments/recognition into the hands of the company. I think our best recourse on this issue is to simply not include bad actors.

Do you have any ideas for other ways we can limit dupes? Or how to really effectively communicate what is out of scope or a known issue?

The only way you are going to disrupt the current market is by hiring on your own salaried pentesting talent to participate.

What we’ve heard in talking about this to a bunch of talented researchers is that they’ve been frustrated with payout rates (too low for amount of work), tone of the interactions between researcher and company, number of opportunities/companies where they can add value (given their skillset - many have said they do the work in large part to learn).

I think there is probably a lot we can do to create/keep balance in the marketplace to address a lot of these if we take things slow.

Would love to hear more of your thoughts on the strategy of building out our team with salaried pentesting talent. Why do you think that is critical to adding a lot of value for startups?