Bug Bounty Program about security-wg HOT 50 CLOSED

We discussed this in today's TSC meeting and there were no objections. We opened an issue on the TSC tracker and in 48 hours, if there are no objects, the TSC will have approved this project

nodejs/TSC#506

from security-wg.

As per @vdeturckheim's request, I have launched https://hackerone.com/nodejs publicly (with bounties provided by the IBB).

from security-wg.

I'm 💯 for a bounty program on node core.

Seems like something that would have to be brought up at the board level to allocate funds, but I don't know how that process works.

I also think that having a threat model established would be some pre-cursor work to be done to make it clear what is in scope.

from security-wg.

We wouldn't be able to commit to this without the Foundation providing funds.

from security-wg.

I think having a threat model would be great. @evilpacket is that something you have experience with ?

from security-wg.

@mhdawson yes and no. I've never had to formally document a threat model (documentation what's that? :) but I do it informally for every security assessment I've done. So I'm not really sure what the best methodology we should use, some different approaches mentioned here

STRIDE stands out in my mind but maybe because I'm old and something else is the new better hotness?

from security-wg.

Sadly there hasn't been a ton of new hotness - STRIDE has a number of flaws (for example, no aspect of the methodology will call out a lack of updating mechanism, and its almost completely worthless for abuse case modeling) but there hasn't been a ton of alternatives that have seen much use or demonstrated clear advantages over STRIDE. For Node I think STRIDE's (or really just Data Flow Diagrams) big utility will be identifying all of the attack surface and security relevant dependencies (obviously V8/Chakra, but are we using LibTIFF, LibPNG, or ImageMagic under the covers? If so, that has implications).

With runtimes specifically one thing that the existing threat modeling approaches do a poor job of is capturing which API have security relevancy, and whether their design of the API lends to making security easier or harder for developers using the runtime. As an example for this, traditionally .Net just exposed every crypto API directly, with no wrapper. If someone wanted to symmetrically encrypt data they would need to pick the correct algorithm, key strength, cipher mode, and generate their IV randomly. This is hard enough that every example on Stack Overflow has at least one problem with it. The new .Net Crypto API has two functions - encrypt & decrypt. The only dev choice is what mechanism they use to store the keys it uses under the covers, and where the key encrypting keys that protect these stored keys comes from (DPAPI or x509 cert). Decisions around the API design has a huge impact on the security of apps running in a runtime, and there really isn't a good methodology to both identify what API should be considered (for example, almost every memory API in C/C++ have security relevance), and how to evaluate the security usability of the API.

from security-wg.

I probably should have made that comment in the TM thread - on the topic of bug bounties, an alternative to foundation funding is to ask for a grant from the Core Infrastructure Initiative to fund it. They have several million dollars available to fund security initiatives within major open source projects, and receive relatively few grant applications for that money

from security-wg.

I represent the Internet Bug Bounty. We're interested in adding Node.js core, npm, yarn (unless Facebook covers it under their White Hat program), and possibly other core/common Node-related projects to our scope for bounties. What that expanded scope looks like is TBD, but would be interested in exploring that further.

We already have Ruby, Rails, and RubyGems as part of the IBB, so adding Node.js would be a great next step towards covering more Internet-wide areas.

Who would be good to talk to about getting this going? We basically want to get buy-in from any project we add in scope, as adding a bug bounty program generally does increase the number of reported issues (and teams need to understand that and be ok with it).

from security-wg.

I think discussing it at the next security-wg meeting would be a good start. After that, we can decide if taking it to the TSC is a good next step.

from security-wg.

When is the next security-wg meeting? I can never seem to figure out when they will be held. :)

from security-wg.

It looks like the next one is scheduled for November 2nd. @sam-github can you confirm?

from security-wg.

Yes, that is correct.

from security-wg.

from security-wg.

About a week before the call, an issue will be created in this repo announcing the time and agenda.

Then in the half hour before the call, the issue will be populated with a google hangout link you can join, and it will be posted as a comment, too, so those subscribed to the thread will get an email.

from security-wg.

I think @MylesBorins would need to request this from the Board. We should look at how effective bounty programs are to help make the case, if there's a strong case. I know there's some hesitance for doing these sorts of programs(bounties or paying individual contributors directly via the Foundation) but that doesn't mean it won't get approved or it isn't a good idea.

from security-wg.

@hackygolucky HackerOne put together a Bug Bounty Field Manual that shows the effectiveness of bug bounty programs. It's pretty detailed and should hopefully answer your questions, but I'm happy to answer any specific ones you have about how bug bounty programs work or what makes them very useful as part of an overall secure SDLC standpoint.

from security-wg.

@sam-github, I don't see an issue posted yet. Is the meeting tomorrow still on?

from security-wg.

I plan to have a go at drafting a proposal in the next week or so as work permits. Discussed in the last couple of wg meetings, but note here as well for awareness of those not attending/reading the minutes.

from security-wg.

What's the movement on this? Do we have something we can bring to the TSC?

from security-wg.

@MylesBorins apologies for a long delay in answer. There is a proposal / note out in PR #92 to try to organize the effort of getting this done. The abstract part of agreeing a bug bounty would be helpful is broadly done among the small group that meets frequently and knows about / will refine this. The broader work of putting a simple process in place still needs more attention.

@reedloden I thought that field manual mentioned above and the resources it linked to was great. I would love to get your comments in particular when available.

Please comment here if general discussion needed or on the PR #92 if responding to particular questions or suggestions or line items.

from security-wg.

At today's meeting, the WG decided to ask the TSC's permission to opt in to the IBB.

@reedloden can you expand on #49 (comment) so that TSC members can see exactly what we'd be signing up for?

from security-wg.

Sure!

The IBB is slightly different than most bug bounties in that it really is a bounty covering issues that have already been publicly disclosed and fixed.

In the case of the IBB, we would just take reports from researchers who have already worked with you in the normal disclosure process you have to get their report fixed and disclosed, and then we would offer a bounty afterwards based on the severity of the issue. Bounties would be paid out based on a mapping of a $$$ value to the severity rating structure used by Node.js, with the IBB Panel deciding what that mapping will be.

No direct action / involvement by Node.js is needed here. We just require opt-in from the projects, as we want to make sure that this may cause the number of incoming vulnerabilities to increase due to the extra incentive. See our charter for our opt-in process for new scope.

See the IBB's Python submission page for a good idea on how this would work/look.

Now, if/when Node.js core moves over to using HackerOne for managing incoming vulnerabilities, we'd just merge the separate IBB program and work with you all to do payouts the same way, based on the pre-determined bounty table. If Node.js Foundation wants to start paying out bounties for other types of vulnerabilities, then we can work with you to figure out how that arrangement would work. However, just didn't want that to block just getting Node.js added to IBB scope.

Let me know if you have any questions. Happy to join the next TSC call if it would help.

from security-wg.

@nodejs/tsc we'd like to get this on your radar. Can you please weigh in here (so we don't need to put it on a meeting agenda 😄 ).

from security-wg.

No objections if that is what the security WG recommends.

But if we need to involve the board to get the fund, I think we still need to put it on the agenda of the meeting with Mark?

from security-wg.

from security-wg.

from security-wg.

@MylesBorins I think @reedloden would probably be the best person to speak with.

from security-wg.

@MylesBorins happy to chat! Feel free to reach out to me directly.

from security-wg.

@reedloden I cannot seem to find your email address anywhere obvious. Can you email me please. ${firstname}{lastname}@google.com

the board meeting is on Monday.

from security-wg.

@MylesBorins Just sent you an e-mail from my work address. I'm ${firstname}@hackerone.com.

from security-wg.

As per https://youtu.be/A8fNAmjdanI?t=14m32s, seems like this has been approved.

Is there anything else that needs to happen before I get the IBB parts started? @MylesBorins

from security-wg.

I could be wrong, but I think there is some confusion. I think we only need to involve the board if we need funds. I don't think we need that to get started as my understanding that we don't have to contribute funds. It's only if we want to provide additional funding to add additional incentives.

The ping to the TSC was for awareness and provide the opportunity for objections before it is implemented. @reedloden can you confirm that no funding is required to start? I'd also be interested in what the bounty $ would be in this case (on par with the python example or different numbers because we have not kicked in additional funding).

I'm generally +1, my only concern is if we are already getting enough reports that we would be worried about overloading those doing the triage. @bnoordhuis,@rvagg, @nodejs/security whats your take on that?

from security-wg.

@mhdawson Confirmed that no funding is required to start. We'd start off with the same numbers listed on https://hackerone.com/ruby, https://hackerone.com/ibb-python, and https://hackerone.com/ibb-php and iterate from there.

from security-wg.

@nodejs/TSC if a few more members could chime in here with support, neutral or objections as appropriate I think we'd feel more comfortable with moving forward.

from security-wg.

@nodejs/TSC if a few more members could chime in here with support, neutral or objections as appropriate I think we'd feel more comfortable with moving forward.

No objections or concerns from me if security-wg is on board with it.

from security-wg.

my only concern is if we are already getting enough reports that we would be worried about overloading those doing the triage

I'm not against but I don't want to adjudicate or relay whether a report merits a bounty. Bug bounty programs tend to attract certain kinds of personalities that just won't stop arguing.

from security-wg.

@bnoordhuis You don't have to. You (Node.js) just need to decide if a submitted report (to your own process) meets your security vulnerability criteria. We just map bounties directly to those severities. So, if it wouldn't be something you would consider a vulnerability, then no bounty is possible. Basically, there's no change for you expected/needed.

from security-wg.

Wonderful news @MylesBorins!
If there's anything the WG can help with on-boarding to H1 or tools around it we'd be happy to help.

from security-wg.

There were no objections in nodejs/TSC#506 (comment) so I think we can go ahead. @lirantal I think the last thing we might want to do before closing this issue is to add some documentation either in this repo, the node report (or wherever we think is the best place) to mention our participation and provide some pointers who are interested in taking advantage of the bounties.

from security-wg.

@mhdawson I'll update the processes and README of our repo (security wg) but I think it will also be a good idea to PR the main node website to accommodate for this information in a more visible manner.
WDYT?

from security-wg.

If you can find a good place I agree. Possibly near where we have the email for reporting vulnerabilities.

from security-wg.

@mhdawson does this need to be discussed at today's meeting? If not, could you remove the security-wg-agenda label (it's been there since November 2017).

from security-wg.

I think an update from @lirantal along with seeing if there is anything else that is a blocker, and then we'll remove the label so it does not show up on future agendas.

from security-wg.

@mhdawson we're on hold with publicizing this until more progress is made on Node core on-boarding to H1, right?

from security-wg.

@lirantal we do not have consensus to move forward with the h1 platform for handling security reports

I don't think it makes sense to block launching the program on that

@nodejs/security having h1 as the platform will make it substantially easier for us to manage the bug bounty program

from security-wg.

@lirantal we do not have consensus to move forward with the h1 platform for handling security reports

Is that discussed in another issue somewhere?

@nodejs/security having h1 as the platform will make it substantially easier for us to manage the bug bounty program

+1 on h1

from security-wg.

from security-wg.

@vdeturckheim Let me know how I can help! Would love to know of a list of any possible blockers in order to help drive this forward.

from security-wg.

I'm going to close this, as the bug bounty program has launched. Congrats and thank you to everyone that got this going.

from security-wg.