Should bounty companies pay for bugs in third party software?


I’d like to discuss a subject that I’m sure at least @kymberlee has a stance on; whether companies that hosts bug bounties should pay for bugs third party software or not. I have heard arguments from both sides of this table, including:

  • (for): If our company makes a change based on the report then we
    should reward it, regardless if we created the bug or not.
  • (against):
    It’s impossible to run a web application without any third party
    code, and it’s not feasible to run a bounty for someone else’s code.
    If another Heartbleed is dropped and someone reports it before I can
    get it patched, why should I pay them?

The reason I bring this up now is because I discovered a bug in a third party library yesterday that affects a lot of sites (including some that runs a bounty). What’s your opinion on this, and if you were in my shoes would you report it to each bounty program or to the third party?

Hey @avlidienbrunn I’ll respond after my webinar is done Monday morning… You bet I’ve got an opinion on this, and it is both from the defender side and the researcher perspective! :smile:


You asked “What’s your opinion on this, and if you were in my shoes would you report it to each bounty program or to the third party?”

Yes. I would do both, assuming that did not violate any disclosure agreements (for example, if the library developer has a bounty, you probably can’t disclose to them for reward and also disclose to other bounty programs that consume that library for additional rewards.)

When I worked in defense and received vulnerability reports, if a researcher had identified an exploitable vulnerability in my application I wanted to fix that ASAP - even if it meant:

  • my dev team wrote their own point fix while…
  • I helped the researcher get a CVE from MITRE and…
  • we worked with the developer responsible for the library to get the issue fixed in an updated public release

Ideally my dev team would have upstreamed their fix to the library developer - part of the responsibility of implementing open source code in your applications is that you are expected to contribute back to the code base.

So if I had a bounty, and 0-day in third party libraries was not explicitly excluded in the bounty brief, that would be a rewardable report in my eyes (and if I don’t want to be rewarding for it, I better pay for this one and then update my brief to list these things as out of scope!). Of course I would have needed more from the researcher than “there is an 0-day in a third party library you use”, because the vulnerability isn’t necessarily exploitable to the same extent in my implementation of that library depending on the application architecture, sandboxing and mitigations, etc. I would have wanted demonstration of exploitability in my application to pay a reward. If my internal security researchers have to do all the POC work to determine exploitability and severity before we can triage the urgency for dev’ing a point fix, you’re not really earning a P1 reward here.

This is all me speaking in the historical and theoretical as a single program owner and how I would have responded to that sort of report in the past, but none of that helps you right now. In my current role, I would be happy to work with you across Bugcrowd customers on any third party library vulnerability reports you have to submit as well as with the library developer and CVE authority to get the library updated. But each individual customer would have the ultimate say on whether they were willing to issue a bounty reward for the disclosure.

I don’t want to shut down the conversation if others want to weigh in, but if you want to move forward with disclosure feel free to shoot me a mail and we’ll synch up on next steps.


1 Like