Progressive price reduction

[B3EF]

👍🏻 reward suggestion

• if you can , then keep same bounty for different family of bugs and reduce 50% for same kind family of multiple reports.
  because the maintainer will be already knowing that his/her repo is vulnerable to this family of bug then it will be their job to fix at other possible end points, if there is same bounty for different family of bugs then the reporter will show some dedication in his/her work as they will try to find different kind of bugs other than reporting the same one at the same repos different path.
• it would be also nice if a sheriff is assigned to check the cvss score , as while going through some bugs reported recently , it feels like point farming is going on with huntr , and it will also encourage the maintainers to use huntr , other than considering as a spam(some maintainers consider this as a spam from my recent experience )
• at last , it would be nice if bounty provided to well known projects are the same, ie consider Projects like October CMS... these projects holds multiple dependent repos, here in these cases only the main one will be famous and have more stars forks and clones, there is chances for the bug to be found has to be in its dependent repo , so it would be nice if all the dependent repos under same maintainer which combines in to a single project will hold same bounty as reward.

[B3EF]

These are just suggestions from my point of view .

[b1nslashsh]

Agreed 💯

[adam-nygate]

Thanks for the feedback & suggestions @B3EF! I thought I'd turn this into a GitHub Discussion so that we can open this up to the community.

Regarding your suggestions:

• We thought about this (reducing the price if disclosures share the same CWE in a small period of time), but the issue is (and having seen this in the community already) is that CWEs/Vulnerability Types can be up to interpretation, meaning maybe the same vulnerability could be mistakenly (or intentionally) misclassified (I.e: Code Injection, Static Code Injection, Command Injection), leading to a poorer quality submission and avoiding this mechanism to try to reduce farming/spam and would work against our future duplication detectors.
• Unfortunately, the Sheriffs no longer exist 😞, we moved away from the Sheriff model a while back because we recognised that we couldn't effectively use sheriffs to validate reports and since have been working closely with maintainers to directly validate reports (as at the end of the day, it's their code and they know whats best for it). Since moving away from the sheriffs we've been able to scale the number of vulnerabilities we process from ~60 per month to >550 per month! With regards to CVSS, we are working on this to make this editable and easier for researchers to use. I think it makes sense that researchers should remain in control of this as it's important that researchers learn how to appropriately judge the severity, leading to higher quality submissions, rather than them outsourcing this work to somebody else (I.e. a sheriff) - I hope this makes sense?
• It's a great point on this (And the OctoberCMS example) and we'll definitely look to fix this kind of bug in the future - just need to find an automatic way to detect such situations, so that we can then adjust the price appropriately. Hopefully in the future, as more maintainers join the platform and offer their own bounties, they'll simply be able to define their own pricing and so won't have the shortfalls of our automated solution.

Regarding our implementation for the progressive price reduction - we are actively looking to improve this and agree that this first iteration is not ideal, we'll likely move to something fairer where instead of it looking in a 30-day rolling window, it may look at a smaller window (like just 7 days or maybe even 1 day), and so if people are finding new bugs a few days apart, they won't be penalised, only those who spam repositories in very short timespan should feel the brunt of this price reduction.

Let me know if you have any more ideas or thoughts on this! :)

[ranjit-git]

Regarding your suggestions:

• We thought about this (reducing the price if disclosures share the same CWE in a small period of time), but the issue is (and having seen this in the community already) is that CWEs/Vulnerability Types can be up to interpretation, meaning maybe the same vulnerability could be mistakenly (or intentionally) misclassified (I.e: Code Injection, Static Code Injection, Command Injection), leading to a poorer quality submission and avoiding this mechanism to try to reduce farming/spam and would work against our future duplication detectors.
• Unfortunately, the Sheriffs no longer exist 😞, we moved away from the Sheriff model a while back because we recognised that we couldn't effectively use sheriffs to validate reports and since have been working closely with maintainers to directly validate reports (as at the end of the day, it's their code and they know whats best for it). Since moving away from the sheriffs we've been able to scale the number of vulnerabilities we process from ~60 per month to >550 per month! With regards to CVSS, we are working on this to make this editable and easier for researchers to use. I think it makes sense that researchers should remain in control of this as it's important that researchers learn how to appropriately judge the severity, leading to higher quality submissions, rather than them outsourcing this work to somebody else (I.e. a sheriff) - I hope this makes sense?
• It's a great point on this (And the OctoberCMS example) and we'll definitely look to fix this kind of bug in the future - just need to find an automatic way to detect such situations, so that we can then adjust the price appropriately. Hopefully in the future, as more maintainers join the platform and offer their own bounties, they'll simply be able to define their own pricing and so won't have the shortfalls of our automated solution.

Regarding our implementation for the progressive price reduction - we are actively looking to improve this and agree that this first iteration is not ideal, we'll likely move to something fairer where instead of it looking in a 30-day rolling window, it may look at a smaller window (like just 7 days or maybe even 1 day), and so if people are finding new bugs a few days apart, they won't be penalised, only those who spam repositories in very short timespan should feel the brunt of this price reduction.

Agreed

[TheCrott]

Agree with shorter penalty window (I prefer 1 day). Bounty reduction I think is a lose-lose for both maintainers and researchers.

If researchers found different bugs on a repo they will submit one bug only and waiting 30 days (with current bounty penalty window) to submit the rest of the bugs. And for maintainers, the projects will lose researchers.

[0xcrypto]

I think before coming to a conclusion, we should define the problem correctly first. As far I have understood, the current model is being changed for one (or more) of the following reasons,

1. People are reporting same vulnerability in same project because maintainer is failing to fix bug in one place but not the other.
2. People are mass reporting same vulnerability in very very small projects which have little to no usability.
3. Huntr Team is trying to involve more maintainers by indirectly asking hackers to look for vulnerabilities in other projects.

[B3EF]

@adam-nygate
as @TheCrott have mentioned progressive price reduction will be a loss-loss game,
so it would be better to keep the same bounty, but it would be better if there is an option for a researcher to combine multiple same kinds of bugs in different paths into a single adversary, with a decent amount of bounty as @0xcrypto mentioned the researchers are reporting the same vulnerability in the same project because the maintainers are not able to fix it or find the existence of the same bug at different paths, so it would be nice if there is an option for a researcher in the adversary page to report the same bug at the different path in a single report with a decent amount of increment in the bounty. so there is no need to be charging a penalty/reduction in the actual bounty pattern.

[adam-nygate]

💯 @B3EF! We had this same idea - we're tracking it at #2045.

Once we rebalance this price reduction and implement the above feature, I think it will be fair again.

Users who find multiple vulns (of same vuln type) in the same repo, will be able to submit one report with multiple paths (permalinks) so they get rewarded more, and only aggressive farming of the repo will lead to the price reduction.

[ranjit-git]

100 @B3EF! We had this same idea - we're tracking it at #2045.

Once we rebalance this price reduction and implement the above feature, I think it will be fair again.

Users who find multiple vulns (of same vuln type) in the same repo, will be able to submit one report with multiple paths (permalinks) so they get rewarded more, and only aggressive farming of the repo will lead to the price reduction.

There may be different xss in different path and reproduction step will be different for same report

[adam-nygate]

There may be different xss in different path and reproduction step will be different for same report

That's fine, the researchers bounty will increase for the amount of paths/permalinks and they can provide as much info in the report for reproduction

[ranjit-git]

You want to multiple bug to same report ,thats good . But most security team want single report for single bug . So, give them to see indivisual bug even when multiple bug is merged to same report .