jsulinski

We definitely don't want to discourage you from contributing. It also doesn't necessarily have to be money, you could stake reputation you've previously earned.

The dupes problem is super important, in my opinion, because it's currently an unpleasant experience for both sides. Not getting paid out for valid work that has simply been reported before (but not disclosed) can make doing this kind of research as a freelancer unfeasible, while triaging duplicate reports burns time for dev teams.

We've tried to build out in-scope/out-of-scope functionality that makes it super simple to keep your scopes current (could even update automatically via API). We definitely want to build out additional functionality that makes publicly acknowledging known, 'won't fix', and non-impactful issues super easy, perhaps by pulling most of the information from a duplicate report. Do you think that’d be useful?

The other thing we want to really focus on is the disclosure process, and encouraging companies to do it as often and soon as possible.

I agree with you, they aren't very informative. We're big fans of BugCrowd's work in this area, and intend to adopt their VRT, though we're still considering how to make P1/P2/P3/P4 more clear/descriptive at a glance.

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?

Hah, yeah, this stuff is hard and acquisitions make it even harder.

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?

How does this compare to say, Aerospike, or Honeycomb.io?

I don't fully understand the question.

clair does static analysis

vuls uses a package manager and changelogs

The conversion of package version numbers to vulnerabilities is perilous and incredibly complicated. That's one of the most significant challenges that we want to solve, which is even more pressing considering how badly the CVE ecosystem is breaking down.

That's correct, vuls queries the package manager for installed packages, versions, and changelogs. It then compares the CVEs found in the changelogs to NVD.

There are certainly flaws in this approach; it's one of the reasons we intend to support multiple scanners. We started with vuls because clair wasn't released yet and we wanted to support more than containers.

This is a very well-written explanation.

The only exception is when people have access to the underlying container, willing or not. Then these vulnerable binaries can lead to a vulnerable container.

This is also why the subjectivity in CVE rating is such a significant problem.

Thank you. I'll definitely be reaching out.

Good point. What I meant was comfort moving away from a major distribution.

NixOS is another distro that looks interesting.