Hacker News new | ask | show | jobs
by eterm 2881 days ago
As a "researcher" I don't find your vulnerability levels too informative. I'd suggest you use or adapt the bugcrowd taxonomy: https://bugcrowd.com/vulnerability-rating-taxonomy

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.

1 comments

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?

The baseline VRT P5's a bunch of things most startups really want to know about, like exposed admin consoles and broken password reset flows.