Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request to Add A Function to Challenge A Developer's Severity Rating #2225

Open
Galapag0s opened this issue May 19, 2022 · 1 comment
Open

Comments

@Galapag0s
Copy link

Currently huntr provides no way for researchers to challenge a developer's severity assessment.

For both the benefit of researchers, and huntr, this option should be made available.

In its current state, there's nothing preventing developers from creating inaccurate severity ratings to downplay potential security reporting. This hurts both researcher payouts and reputation, and the overall accuracy and integrity of huntr's reporting.

@dievus
Copy link

dievus commented Jun 29, 2022

I agree with this. There's a significant difference between a platform that is able to issue CVEs and something like HackerOne where vendors regularly play down severity because of silly reasons. And to be fair, I've had a couple played down on this platform where it's clear the maintainer may simply have no idea what a real-world severity value is, or they are downplaying severity, so it doesn't affect the project.

While trying to remain humble, I do this work professionally and issue CVSS scores regularly in penetration testing reports and elsewhere. The severity of something doesn't change because a vendor or maintainer disagrees, or the individual may not be a security professional at all, but rather a developer. And again, in the end, NIST will issue its own rating, which going through some of the CVEs on the platform, it's clear that the CVSS issued by a maintainer is grossly inaccurate. See as an example:

https://huntr.dev/bounties/5494e258-5c7b-44b4-b443-85cff7ae0ba4/ - developer downgraded significantly from 9.8 to 6.8, penalizing the researcher, and then NIST re-scores it 8.8, which is appropriate in my opinion. (This maintainer has a history of doing this to researchers).

In the end, this platform is uniquely positioned as both a bug bounty platform and a CNA, not the maintainer. As such, there should be some additional deference shown to the researcher in these cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants