Security-wg: How can we utilize funding for the ecosystem bug bounty program?

[MarcinHoppe]

Coinbase has kindly offered to support the Node.js ecosystem bug bounty program with a cash donation. We hashed out several ad-hoc ideas in an e-mail thread but we feel the issue warrants a wider discussion by the entire team.

/cc @lirantal @vdeturckheim @reedloden

[lirantal]

Continuing from the e-mail thread, we raised the following options for coinbase to support our efforts in the working group:

1. A bounty of $1000 for Node.js ecosystem
2. A bounty of $250 for Node.js ecosystem
3. Bounties for specific report types (i.e: vulnerability types we want to target for, or bulk of reports as we had those too)
4. Supporting local communities such as hosting meetups and helping them
5. Swag is also an option as a reward for bug bounties

For the sake of argument, the budget is around $15,000 and we still need to figure out final amounts as well as coordinate with the foundation on how this will work to make sure we're aligned.

We'd be happy to get more ideas and discuss what are some options.

[mhdawson]

I'd like to get input from the Foundation about any concerns about accepting this kind of donation and how it needs to be managed. Will send of an email to Mike Dolan to ask.

[reedloden]

@mhdawson What's the latest on this?

[mhdawson]

@lirantal can you provide an update. There was a response from Mike Dolan at the foundation but I think you had a follow on conversation. I think the answer was that the Linux foundation already has some projects with donations from coinbase so it's not a "new" concept and we should have some existing prior art.

[roccomuso]

It's good to see support from this huge crypto companies.

[reedloden]

If you decide options 1-3 (or something else related to the bug bounty program itself), just note that I am happy to work with Coinbase to get the funds transferred into the appropriate HackerOne program (nodejs or nodejs-ecosystem). Easier than transferring to Linux / Node.js Foundation and then transferring to HackerOne.

[lirantal]

Still discussing with Mike from the foundation over e-mail, hopefully will have more to share soon.

[shivasurya]

[My suggestion] It would be nice if providing a bounty for top downloaded package/legit production npm packages in Node.js ecosystem ( High + Medium severity ) and other npm packages can receive swag and thank you message in hackerone.

[lirantal]

@reedloden would it be possible somehow to make the bounties applicable only to certain criteria? as in modules that are > 1000 weekly downloads and such? If it's something manual that the triage team can decide upon then that's easy for us to just check this number and approve the bounty.

[lirantal]

@reedloden another point is that I'm actually not sure if it would be a good idea to also contribute that budget to the Node.js core program because we already have the IBB support for it (it's under a specific criteria but still). WDYT?

[reedloden]

@reedloden would it be possible somehow to make the bounties applicable only to certain criteria? as in modules that are > 1000 weekly downloads and such? If it's something manual that the triage team can decide upon then that's easy for us to just check this number and approve the bounty.

It would totally be your call. Bounty awards are not automatic, so you (or technically, people with the "Reward" permission would decide if a specific report qualifies. Main thing is just to spell out the bounty criteria in the program policy so that there aren't disagreements later. Always good to set proper expectations in advance.

@reedloden another point is that I'm actually not sure if it would be a good idea to also contribute that budget to the Node.js core program because we already have the IBB support for it (it's under a specific criteria but still). WDYT?

I don't think it would be useful to put it towards Node.js core due to IBB already covering that, but the IBB isn't going to turn down additional funding (we're always looking for more supporters). However, I personally believe it makes sense to put it towards the Node.js ecosystem project (which doesn't have IBB funding at all). Feel you could do some creative stuff there with it, as has been previously discussed.

[lirantal]

1. Good news about the manual bounty. We will definitely put up criteria in place!
2. Agree. These are my thoughts as well.

@mhdawson @MarcinHoppe are you ok with that?
I think it will be interesting to actually try out the swag thing. I've been wanting to do it since last year already but we had some delays with the official Node.js channels. Perhaps we can speed this up if we get external funding.

[shivasurya]

@lirantal Couple of doubts,

1. The criteria plan for bug-bounty can be an open discussion?
2. is the shipping can be done internationally for swag?

[lirantal]

Without a doubt yes and yes! :)

[MarcinHoppe]

@lirantal I am 👍 on both aspects. We can start to put together the reward rules.

[reedloden]

What's the latest on this? I just want to make sure Coinbase isn't waiting on any decisions to be made.

[lirantal]

I would say let's finalize first how we want to split the budget and then get that going with Coinbase, then we can figure out the details about criteria and such.

What do you feel about a split such as:

1. $12000 - Node.js ecosystem bounties
2. $3000 - Recognition through swag for the security wg community and security researchers (still need so see of course that this makes sense with Coinbase too)

[mhdawson]

That split seems good to me. I think we need to define the qualification parameters pretty well and I think one criterion is that we should get agreement from the maintainers of a particular module that they want bounties to apply to their module.

[MarcinHoppe]

I absolutely agree on getting package maintainer consent. Incentivizing researchers with payouts might lead to many more reports for packages in scope and maintainers need to be able and willing to fix the resulting bugs quickly enough. It requires a commitment from them, IMO.

I wonder if we could start with payouts for core packages identified by the Package Maintenance WG? That would make a lot of sense to me intuitively but I would love to hear other opinions.

[dgonzalez]

Agreed!

[sam-github]

Is there existing practise on this? I've often seen org pay bounties for vulns on their own software, so for us to pay for vulns against thirdparty isn't like that.

But then, security scanners/anti-virus vendors pay for vulns on anything they can scan, right? So, I'm not sure if ecosystem authors would have reason to complain if we facilitated bounties for ecosystem modules. No one is forced to fix vulns... and no one is forced to use a module if it has vulns the author won't fix.

[sam-github]

And if someone is offering bounties for node or ecosystem vulns, I think that's generous, I'm all in favour.

[MarcinHoppe]

Commercial companies running their own disclosure programs or bug bounties add an interesting twist here but I am not aware of any prior art here. IIRC we've only had one vendor recently offer a payout for a vulnerability reported in their package.

[nschonni]

So, I'm not sure if ecosystem authors would have reason to complain if we facilitated bounties for ecosystem modules.

This creates a burden on the maintainers. Maybe this should be integrated into https://github.com/nodejs/package-maintenance as an opt-in rather than an opt-out

[sam-github]

@nschonni Could you elaborate on what burden it puts on them? Knowlege isn't a burden, IMO.

No one is forced to fix vulns... and no one is forced to use a module if it has vulns the author won't fix.

[nschonni]

Triaging issues is the burden, that's what the other group is trying to help reduce. The package-maintainer effort is trying to organize what projects are looking for help and might be interested in participating. As soon as these issues are opened, you also get the pile on of "why haven't you fixed this" that adds to the maintainer burden.
I'm not saying that knowledge isn't a good thing, but incentivizing fuzzing on projects that are not able to respond isn't helpful, hence the opt-in rather than opt-out

[mhdawson]

@nschonni as I mentioned above I'm 100% in agreement. This needs to be "opt-in". From above:

and I think one criterion is that we should get agreement from the maintainers of a particular module that they want bounties to apply to their module.

[mhdawson]

I think coordination with the package maintenance effort makes sense, but I don't think that needs to be a blocker.

I think we need to maintain a list of modules that have opted in in this repo and make it clear that the bounties only apply to those. We can then co-ordinate with the package maintenance team to promote and possibly make one of the recommended baseline practices how you address vulnerability reporting and support of bug bounties.

[sam-github]

Who are we trying to serve? package maintainers, or package users? Obviously, the package-maintenance effort is trying to make less work for package authors, which is great.

But credit card info traders and bitcoin theifs don't ask package maintainers before seeing if their packages have vulnerabilities.

I, as a package user, am sympathetic if a package author feels burdened by vulnerabilities being reported against their packages.

However, I as a user, want to know if packages I'm depending on have vulnerabilities that could be used to compromise my app. The burden to a node.js package user when their company's website is compromised, their customer info is sold to the black market, and they are dragged into the CEOs office dwarfs the package maintainer's burden.

[sam-github]

Maybe coinbase, who is offering up the bounty, has an opinion on this, @lirantal ?

[mhdawson]

@sam-github I still believe we should focus on the efforts (at least to start) on packages where the maintainers believe they have time to address the problems found.

In the package-maintenance effort we are trying to figure out how to balance the needs of consumers and maintainers and what makes sense given that often modules are consumed for free. Part of the solution might be lining up consumers who are able to help fix reported vulnerabilities. It might also make sense to focus on some smaller number of modules that we think are important for the ecosystem and work with the maintainers to get their feedback on the best approach.

[sam-github]

OK, I'm not going to push this, and I'll try to get involve in the package maintenance effort. I very much want to know what module authors in my dep tree don't feel they have the capacity to accept vuln reports (much less fix them). It would definitely guide my usage.

[MarcinHoppe]

I think this:

I _very_ much want to know what module authors in my dep tree don't feel they have the capacity to accept vuln reports (much less fix them). It would definitely guide my usage.

is a tremendously useful comment. So far package users did not have this kind of information available to them.

The original reason I suggested we tie bug bounty payouts to the package maintenance effort was my hope that this would help us target popular package that a significant chunk of community depends on (Express is a perfect example) and this way incentivize researchers to focus on those packages. Today we receive quite a few reports for packages that are barely used.

@sam-github comment provides another point that I think reinforces my feeling this is the way to go.

[sam-github]

After talking to @mhdawson, and seeing the above, I think we'd all agree on @MarcinHoppe 's point:

Today we receive quite a few reports for packages that are barely used.

We want to incentivize research into widely depended on packages, and I'm going to hope that widely depended on packages would happily opt-in to getting vuln reports.

[mhdawson]

One thought that @sam-github and I discussed was creating a baseline practice under the package maintenance effort covering how to handle vulnerability reports, recommending opting into the bug bounty program and including an indicator the package.json that the modules participate in the bug bounty program. This would make it easy to identify modules that have opted in (both by end consumers and the security wg to cross check against widely depended on packages)

[MarcinHoppe]

I like it a lot. Potentially this information could even include information where vulnerability reports should be submitted (a'la security.txt files). This could be useful information to surface in npm.

/cc @evilpacket

[lirantal]

With regards to incentivising the work on popular packages - that can just go as part of our categorization of which packages are due for bounty, or be factored into the amount payed out.

[lirantal]

In summary:

• I believe we can facilitate the discussion around criteria for bounties on https://github.com/nodejs/security-wg/issues/503
• This topic I believe has been summarized and agreed upon in https://github.com/nodejs/security-wg/issues/475#issuecomment-464317759 so we can close the issue