4 ms·

I don't know if 'extremely valid' is good English but it's how I would characterize your assessment. I totally agree. The challenge, however, is constructing

by jcims 5y ago

I don't know if 'extremely valid' is good English but it's how I would characterize your assessment. I totally agree. The challenge, however, is constructing a sustainable model to incentivize product teams to reciprocate this closer working relationship. I would say all but the smallest of companies running bug bounties also have an internal security function that is already doing reporting on vulnerabilities, time to fix, etc. etc. So whatever internal 'reputation' there might be across product teams is well established (and in my experience the culture around bug fixing across product orgs is consistent from both internally discovered and externally reported bugs) Another thing that happens is that there is typically a backlog on bugfixes, so if a researcher reports a new bug that's Medium priority, it's not going to get prioritized against a backlog of Criticals or Highs. Most of the lack of feedback from devs is simply the fact that there's been no action. Once the bug is front and center, the fixes are extremely simple and done within a few days and rolled out.

stingraycharles 5y ago
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.
deleted 5y ago
[deleted]
OJFord 5y ago
> I don't know if 'extremely valid' is good English but it's how I would characterize your assessment. I totally agree. Completely off-topic comment follows, but I find lingustics interesting, am a native (Br) English speaker, and think it's worthwhile to reassure someone they're foreign language skills are fine. Yes, it's good. (It's extremely valid :wink:). It has a slightly comical flair to it - not sarcastic, just certainly not formal. You could push it further to 'I extremely agree', which is more debatable but as long as they realised you were 'being ironic' nobody would say 'hey that's extremely invalid English' or anything. Only one thing wrong: characterise (oxendict be damned!) and incentivise are spelt (not spelled) with an 's'. :British-trollface:
- neolog 5y ago
  Ehh. "extremely valid" is slightly off. "extremely agree" is comical but definitely not standard US English.
  - OJFord 5y ago
    Well, 'valid' is comparable (more valid, less valid, etc.). I don't think it can be said that it's incorrect grammar. It's just an unusual pairing, and 'extremely' is so much of a 'stronger' word that it's got that humourous edge. Not in formal writing, sure, but it wouldn't make me think the speaker's struggling with English, if anything the opposite - a good command of it and able to twist it in fun ways.

by jcims 5y ago

stingraycharles 5y ago

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.

deleted 5y ago

[deleted]

OJFord 5y ago

> I don't know if 'extremely valid' is good English but it's how I would characterize your assessment. I totally agree. Completely off-topic comment follows, but I find lingustics interesting, am a native (Br) English speaker, and think it's worthwhile to reassure someone they're foreign language skills are fine. Yes, it's good. (It's extremely valid :wink:). It has a slightly comical flair to it - not sarcastic, just certainly not formal. You could push it further to 'I extremely agree', which is more debatable but as long as they realised you were 'being ironic' nobody would say 'hey that's extremely invalid English' or anything. Only one thing wrong: characterise (oxendict be damned!) and incentivise are spelt (not spelled) with an 's'. :British-trollface:

neolog 5y ago
Ehh. "extremely valid" is slightly off. "extremely agree" is comical but definitely not standard US English.
- OJFord 5y ago
  Well, 'valid' is comparable (more valid, less valid, etc.). I don't think it can be said that it's incorrect grammar. It's just an unusual pairing, and 'extremely' is so much of a 'stronger' word that it's got that humourous edge. Not in formal writing, sure, but it wouldn't make me think the speaker's struggling with English, if anything the opposite - a good command of it and able to twist it in fun ways.