3 ms·

I think there are two separate issues, though: * properly qualifying a bug bounty submission * actually fixing the thing From what I understood from your ori

I think there are two separate issues, though: * properly qualifying a bug bounty submission * actually fixing the thing From what I understood from your original comment, was that sometimes things get qualified as “wontfix” because of internal struggles. I understand that these struggles exist, as with any large org with conflicting priorities, especially when the issues are not 0day severity. I think, however, from an outsider’s perspective, acknowledging it’s a valid bug, but also saying “this will not get fixed any time soon” is infinitely better than just marking it as wontfix. As such, I’d argue that the minimum effort the product teams would have to put into the bug bounty program is properly qualifying the submissions. If that, for some reason, is too much to ask, I submit it’s a higher level, leadership problem that they want to have a bug bounty program without the necessary resources to qualify the bugs.

jcims 5y ago
Your points are totally valid and I agree with them in principle, I just see them as existing on a spectrum. One pretty interesting example is GitLab's bounty program because you can see both sides, both the reported issues and how they are tracked on the engineering side: https://hackerone.com/gitlab/hacktivity?type=team https://hackerone.com/gitlab/hacktivity?type=team https://gitlab.com/gitlab-org/gitlab/-/issues?label_name=HackerOne https://gitlab.com/gitlab-org/gitlab/-/issues?label_name=Hac... There's very good organizational alignment here from what I can see, and overall the program seems to be quite adaptive and well supported (e.g. the comment about eliminating the 50% bounty here https://hackerone.com/reports/1154542#activity-11394543 https://hackerone.com/reports/1154542#activity-11394543, 'unduping' a report here https://hackerone.com/reports/402658 https://hackerone.com/reports/402658 ). It's about as best-case as you can get for a bug bounty...relatively small, single-product company that exposed to the sunshine effect of a public issue tracker. That said, if you peruse every one of those issues you're going to find instances where they drop the ball, take too long, make mistakes, etc. etc. So I would just say that if you ask anyone that has run a bug bounty, they will likely say they were surprised how difficult it was. You'll also generally find that they are advocates for the researcher community and want to run the best program they can. Everything else is largely a function of the dark art of business prioritization and the quality of the experience will be a function of how well they and their team is able to navigate it.
- stingraycharles 5y ago
  That sounds reasonable, and I’m more than willing to believe that. In the end, reality is more messy than a bunch of well-intended processes, and you’ll have a whole bunch of bugs in limbo, which can keep whole teams occupied without making any real progress towards the end goal that should be achieved. Thanks a lot for your insights, they were very valuable.

jcims 5y ago

Your points are totally valid and I agree with them in principle, I just see them as existing on a spectrum. One pretty interesting example is GitLab's bounty program because you can see both sides, both the reported issues and how they are tracked on the engineering side: https://hackerone.com/gitlab/hacktivity?type=team https://hackerone.com/gitlab/hacktivity?type=team https://gitlab.com/gitlab-org/gitlab/-/issues?label_name=HackerOne https://gitlab.com/gitlab-org/gitlab/-/issues?label_name=Hac... There's very good organizational alignment here from what I can see, and overall the program seems to be quite adaptive and well supported (e.g. the comment about eliminating the 50% bounty here https://hackerone.com/reports/1154542#activity-11394543 https://hackerone.com/reports/1154542#activity-11394543, 'unduping' a report here https://hackerone.com/reports/402658 https://hackerone.com/reports/402658 ). It's about as best-case as you can get for a bug bounty...relatively small, single-product company that exposed to the sunshine effect of a public issue tracker. That said, if you peruse every one of those issues you're going to find instances where they drop the ball, take too long, make mistakes, etc. etc. So I would just say that if you ask anyone that has run a bug bounty, they will likely say they were surprised how difficult it was. You'll also generally find that they are advocates for the researcher community and want to run the best program they can. Everything else is largely a function of the dark art of business prioritization and the quality of the experience will be a function of how well they and their team is able to navigate it.

stingraycharles 5y ago
That sounds reasonable, and I’m more than willing to believe that. In the end, reality is more messy than a bunch of well-intended processes, and you’ll have a whole bunch of bugs in limbo, which can keep whole teams occupied without making any real progress towards the end goal that should be achieved. Thanks a lot for your insights, they were very valuable.