In #6, it was suggested that email alone is not sufficient for reporting vulnerabilities, we need a more trackable system of interaction.

@mikeal suggests some work is ongoing to make this happen. This issue is to open this discussion.

@nodejs/tsc @nodejs/security @nodejs/security-wg:

There are many businesses who depend on Node.js core that would benefit from the ability to have responsible early disclosure of security vulnerabilities prior to the actual release. We have had many requests for this in the past.

The key challenge we have right now is that while we give all users a heads up that a security update is coming, the fact that we announce the details of the vulnerability the same day as the release fix means that we are effectively zero-daying our own users, putting them in a race against malicious parties.

Obviously, however, there are risks in disclosing the details of a vulnerability early.

What I would like to propose is the formation of an Early Disclosure Program as follows:

Individuals or Companies would apply to receive advanced notification of a vulnerability prior to the fix release. Application would consist of signing a formal and enforceable non-disclosure agreement with the Node.js Foundation. It would also include the name and contact information of an individual who would receive the disclosure details, along with a statement explaining why they wish to have early access. All applications would be subject to approval by the TSC. There would be no financial transaction and participation in the program would not require Node.js Foundation membership (corporate or individual). The TSC may turn down any application for any reason.

The Early Disclosure timeline would be 24-48 hours before the actual release, if possible. If extreme cases where a security vulnerability must be patched quicker than that (which, I don't believe has ever happened and I wouldn't anticipate happening), then notification would be As Soon As Possible before the actual release.

The Early Disclosure should only contain enough information to (a) convey the nature of the vulnerability, (b) allow the recipient to determine if they are vulnerable, and (c) plan any mitigating steps they may need to take in preparation for the actual release.

A public record of who is receiving Early Disclosures would be maintained (without the specific individual contact details, of course).

Now that we are actually assessing and triaging security issues in the ecosystem, we should probably start to think about a methodology to consider the severity of issues.

Possible directions:

• perform CIA evaluation of the vuln
• take the popularity of the module in account ? (I'm not a big fan of this)
• other things?

cc @lirantal

Time

UTC Thu 04-Jan-2018 20:00 (08:00 PM):

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Security%20WorkGroup+Meeting+2018-01-04&iso=20180104T20
• or http://www.wolframalpha.com/input/?i=08PM+UTC%2C+Jan+04%2C+2018+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1GxwiNP2f7bTpVfeQ9sBD_WrN5drWNs_a4USrmimiiC0/edit

Agenda

Extracted from security-wg-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/security-wg

• add Liran Tal as group member. #80
• Third party triage team membership #73
• [RFC] Early disclosure program #68
• Kick off meeting Core triage team #67
• Implement process for management of thirdparty vulnerabilities #54
• Bug Bounty Program #49
• Third party triage team report #88

Invited

• Security wg team: @nodejs/security-wg

Observers

Notes

The agenda comes from issues labelled with security-wg-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://hangouts.google.com/hangouts/_/ytl/-CtRVtZ0Gg2iNDSKWmX47Rc8-Jgq6bRhHHmjJVz77jE=?eid=100598160817214911030
• For those who just want to watch: https://www.youtube.com/watch?v=PGQio_Zhhiw
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

As a module author, I would like to recommend my users to leverage https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md for receiving security vulnerabilities.

Should we include a list of recommendation for things to be added in the README of those modules?

When

Thursday, Aug 12th, 2017, 20:00 UTC: other timezones

Where

• Call URL, for participants: https://hangouts.google.com/hangouts/_/jyz5dlubsnh4vjajxajcwmgoeae
• Youtube stream, for viewers: https://www.youtube.com/watch?v=iN366--sK0M
• Minutes document: https://docs.google.com/document/d/1-E8tuIdvkS5x1SNYf8TtLRPG0Zi5O7puMrFILyoC8uY/edit?usp=sharing

Agenda

• threat model for Node.js (#51)
• add Daniel Kluss (#50)
• Have node become a CNA, so it can issue its own CVEs (#33)
• Review WG notes, and develop plans/action items/TODO lists to do the things we want. #53
• ... (anyone is free to edit in more to the agenda, or comment below)

When

Thursday, July 13th, 2017, 20:00 UTC: other timezones

Where

• Call URL, for participants: https://hangouts.google.com/hangouts/_/ytl/vnq9kDR4Pj3uzitlsqSqGrlPU6ZvS4_FKeK6zZOGgJQ=?eid=100598160817214911030
• Youtube stream, for viewers: http://youtu.be/WSI3r-8Gos0
• Minutes document: https://docs.google.com/document/d/1G8RoWl8o3P2NOrosekE5HgFoRh2_bQMfebSsVFg5FZ0/edit

Agenda

• Review open issues to determine if there are any actionables. Close issue if not, call for volunteers if there are: https://github.com/nodejs/security-wg/issues
• ... (anyone is free to edit in more to the agenda, or comment below)

When

Thursday, Nov 2th, 2017, 19:00 UTC: other timezones

Where

• Call URL, for participants: https://hangouts.google.com/hangouts/_/ytl/DQtsIlP8JPmlwaAg-1DdITdxdVaM-OmUuyNmhYW4M-M=?eid=100598160817214911030
• Youtube stream, for viewers: ttp://youtu.be/UWKC1GTPAFo
• Minutes document: https://docs.google.com/document/d/1YoL4ISHc_c3klSUg5y428i7vsAibs3JsPTG8NeUn_7I/edit?usp=sharing

Agenda

• review last WG
• 3rd party vulnerability management on HackerOne
• proposing early disclosure program
• cve management program
• bug bounty program
• acknowledge privacy of info in private repos.
• membership to security teams
• (... add TODO items in comments on the issue, or by direct editing this issue)

I don't have the power to make one.

Can someone who does please do so?

@nodejs/security the github at-completion lists this alias with no description, it should probably have one that describes its purpose.

Is it for members of the working group? Or to notify people of possible security issues? I would think not the latter, because that's private, and best handled by email.

👋 Hi everyone, I've been keeping an eye on this repo, but I'd like to formally request to join the working group. As for who I am, I'm the VP of Engineering at NodeSource, and I've been using Node for, like decades now ;)

Thanks for your consideration!

Time

UTC Thu 30-Nov-2017 20:00 (08:00 PM):

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Security%20WorkGroup+Meeting+2017-11-30&iso=20171130T20
• or http://www.wolframalpha.com/input/?i=8pm+UTC%2C+Nov+30%2C+2017+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1kyTPI3dqJXZi8_qu3cuKnAHKtnSm1hZCT11sTtDMD3s/edit

Agenda

Extracted from security-wg-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/security-wg

• [RFC] Early disclosure program #68
• Kick off meeting Core triage team #67
• Proposing an Early Disclosure Program #58
• Implement process for management of thirdparty vulnerabilities #54
• Bug Bounty Program #49

Invited

• Security wg team: @nodejs/security-wg

Observers

Notes

The agenda comes from issues labelled with security-wg-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://hangouts.google.com/hangouts/_/ytl/sgbE79vNVLym7b3yURjVsn200TNxUEjXgmw6y7g73-8=?eid=100598160817214911030
• For those who just want to watch: https://www.youtube.com/watch?v=pFSTHsgunW8
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

There may already be a thing that does this and I'm missing it, but is there a tool that helps with generating and sending the security alerts in the google group, and then generates the post for the nodejs.org? If not, I am happy to try and with this.

cc @mhdawson

As titled.

We link from the 3rd-party document.

Membership meaning:

• github permissions on this repo (for closing issues, merging, etc.)
• presence in meetings

Or are the two different?

When we start curating npm package vulnerabilities, we should also consider adding all known vulnerabilities in node itself. Right now they are mentioned in the release announcements/changelogs, but it would be valuable to have node itself listed in the DB, see #26

This would enable thirdparty tools to report not only any know vulns in the package dependencies, but also in the current (or any) version of node.

Microsoft has a "fuzzing as a service" (https://www.microsoft.com/en-us/security-risk-detection/). I've chased down resources to offer it for free to open source projects, similar to Google's efforts. As Google and MS use different fuzzing mutators there is utility in using both (internally we have found that eventually you exhaust the findings from one fuzzing algorithm, but that switching algorithms will uncover new findings; conceivably someone could invent a fuzzing algorithm that does superset the output of many existing algorithms, but nobody has fully done that yet)

Fuzzing provides the most utility when applied to unmanaged (i.e. c/c++) parsers, though can find potential DoS and fault scenarios in managed parsers as well. As I'm not anywhere as familiar with all of the pieces of the Node.js code base as I would like, can folks point me to parts of the codebase that would be good targets for fuzzing, and I'll get it set up.

We (MS) are still working on streamlining the process on our side, but we hope to get things configured such that we automatically pick up new commits to the codebase and run until we hit some threshold (given that we hope to do this for a ton of open source parsers, that threshold will probably be around 1m iterations without a fault per fuzzing algorithm, on the most recent commit; 1m iterations without a fault isn't a guaranty that the 1,000,001th iteration won't find a fault, but it does suggest that there are diminishing returns for additional passes where CPU cycles could be better spent hitting other code. )

This group has been pretty inactive. Is there anything that could be discussed at the collaborator summit today and/or tomorrow?

I was a little slow to get this going, but having chatted with Semmle yesterday they are happy to give a demo of their product, walk through how it works and how their queries to find issues are created (with much more in depth workshop on creating queries at some point in the future if Node.js decides to use it), and start the discussion of how Node might use Semmle if we decide to do so (i.e. what licensing looks like for our usage, so that I can then negotiate with them to acquire it for Node)

So two questions:

1. What date would work well for folks to set up a hangout to demo the tool
2. Who outside of the security WG should we also invite (Semmle has far more utility than just finding security bugs - it basically creates a queriably data representation of a code base and provides a query language to ask complex [or simple - but grep can also ask simple] questions about that code. Security lends itself well to that, but so does performance, reliability, etc.)? I'd think it would be of interest to senior developers/architects/quality folks on top of us security minded people.

There were three informal meetings of security-wg memembers and interested parties at Node Interactive, October, 2017. This issue is to collect notes on what was discussed. I'll add mine as the first comment, anyone else with notes is free to add theirs, and we can close the issue during the next formal WG meeting.

Are we going to have anything during the un-conference portion of Node Interactive next week?

One of the proposed responsibilities of this group is "owning and publishing the base dataset of disclosures." I think the ideal way to publish this data would be to make it available via a public, documented HTTP API.

The prime use case for such an API would be for tools and services to programmatically check for vulnerabilities alongside their main task; I suspect that's in fact how nsp works today. For example, npm might check for vulnerabilities on npm outdated.

Other uses would be to send notifications (e.g. via webhook) when new vulnerabilities are added, and to serve as a backend API for a human-readable website for searching and listing vulnerabilities.

I think we should host this API service on our "own" infrastructure as managed by the @nodejs/build team - "own" in quotes because most of it is backed by public cloud resources and not a private datacenter. In fact, I'm not sure what other options we have; any additional cloud resources needed by this service would likely be added to the Build group's responsibility too.

The conversation in #16 on how to store vulnerability data is loosely coupled to this conversation on a public API, in that we should be able to easily abstract the storage implementation from the API service.

In summary, this issue is to gather thoughts on:

1. Providing a public Vulnerabilities HTTP API.
2. How to build and host such an API service.

I would be interested in starting a Bug Bounty Program

@sam-github suggested that people who are listed in https://github.com/nodejs/security-wg/blob/master/processes/security_team_members.md

should acknowledge the restrictions in:

Node.js security team members are expected to keep all information that they have privileged access to by being on the team completely private to the team. This includes agreeing to not notify anyone outside the team of issues that have not yet been disclosed publicly, including the existence of issues, expectations of upcoming releases, and patching of any issues other than in the process of their work as a member of the security team.

by PR'ing themselves into the list. This makes sense.

As a bootstrap for those already part of the lists, please acknowledge as a comment in this issue.

@ChALkeR - Сковорода Никита Андреевич
@Fishrock123 - Jeremiah Senkpiel
@MylesBorins - Myles Borins
@Trott - Rich Trott
@addaleax - Anna Henningsen
@bnoordhuis - Ben Noordhuis
@cjihrig - Colin Ihrig
@dougwilson - Douglas Wilson
@ejratl - Emily Ratliff
@evanlucas - Evan Lucas
@evilpacket - Adam Baldwin
@grnd - Danny Grander
@indutny - Fedor Indutny
@jasnell - James M Snell
@jbergstroem - Johan Bergström
@joaocgreis - João Reis
@joshgav - Josh Gavant
@mhdawson - Michael Dawson
@mscdex - Brian White
@ofrobots - Ali Ijaz Sheikh
@rvagg - Rod Vagg
@saghul - Saúl Ibarra Corretgé
@sam-github - Sam Roberts
@shigeki - Shigeki Ohtsu
@targos - Michaël Zasso
@thefourtheye - Sakthipriyan Vairamani
@trevnorris - Trevor Norris

[EDITED by @Trott: formatting of text to be acknowledged for legibility--no content change, just format)

From my initial notes, please edit to add what I'm missing (we'll discuss in WG meeting):

• (@sam-github) Setup storage for vulnerabilities and seed with nsp data. We are using JSON files committed into github repo
• (@vdeturckheim) Set up HackerOne teams and workflow
• document the process, so people know what the process is we are using the tool for
• (@lirantal) Implement script to pull vulns from HackerOne into github ready JSON. see PR #234
• (@lirantal) Implement script to pull new vulns from Node Security Project (ones received after the intial dump) into github ready JSON - temporary measure until the nodefoundation becomes the primary reporting endpoint, at which point we can stop scraping
• PR change to email address alias to direct vulnerability reports to HackerOne
• PR change to https://nodejs.org/en/security/ to direct thirdparty package vulnerabilities be reported to Node Foundation, not Node Security Project

As discussed in our last meeting it is time to kick off the triage team.

The job is described in the soon-to-be-merged process document.

Please state your interest in this issue. I plan to open a vote in another issue to have this team validated by the WG early next week (but anyone is still welcome to state interest after this date of courses).

As of OCT 12th meeting, pinging @brycebaril and @mgalexander.

Also, @cjihrig, @sam-github and I are already member of the HackerOne team. Let's consider it as an will to be a member of this team unless stated otherwise.

(edit): this is on: https://nodejs.org/en/security/#reporting-a-bug-in-a-third-party-module

(edit): Also @reedloden from HackerOne is currenlty a member of the organization. He offered to stay a bit until we are certain we handle the platform well. I think this is a good opportunity for us!

There hasn't been a lot of activity here since March - is there anything we should meet about, or delegate to get done? We were looking at a more robust security issue reporting/tracking service, and since then HackerOne has made their platform free for open source projects. What else needs attention?

First cut at documenting the security announcement process. I think we have agreement that our processes documented publicly even in cases like the security announcement process were some of the work must be completed in private. The security wg is probably the place to discuss these and possibly the place to document them. Once we are in general agreement on where the doc should go I'll move the text into a PR on the appropriate repo.

• On issue for security vulnerability in private security repo, propose candidate text based on past announcements.

• Once reviewed, agree on timing for announcement and line up releasers to make sure they are available to do the release on that date.

• Post to https://groups.google.com/forum/#!forum/nodejs-sec. Note that you will need to have
  been given access by one of the existing managers (Ben Noordhuis, Rod Vagg, Trevor
  Norris, Michael Dawson). You will have to manually edit to add formatting and links
  properly.

• Mirror post in vulnerabilities section of Nodejs.org blog section.
  Submit PR and leave 1 hour for review. After one hour even if no reviews, land anyway so that we
  don't have too big a gap between post to nodejs-sec and blog. Text was already reviewed in security
  repo so.

• In original PR for security issue, post candidate text for updates that will go out with releases that
  will indicates releases are available and include full vulnerability details.

• Once releases are made, post response to original message in
  https://groups.google.com/forum/#!forum/nodejs-sec indicating releases are available and with the
  full vulnerability details.

• Update the blog post in https://github.com/nodejs/nodejs.org/tree/master/locale/en/blog/vulnerability
  with the information that releases are available and the full vulnerability details.
  Keep the original blog content at the bottom of the blog. This is an example:
  https://github.com/nodejs/nodejs.org/blob/master/locale/en/blog/vulnerability/june-2016-security-releases.md. Make sure to update the date in the slug so that it will move to the top of the blog list.

• Tweet out a link to the nodejs-sec announcement

• Email foundation contact to tweet out nodejs-sec announcement from foundation twitter account ?

https://nodejs.org/en/blog/announcements/nodejs-security-project/

As announced above, goals are:

The Node.js Foundation will take over the following responsibilities from ^Lift:

1. Maintaining an entry point for ecosystem vulnerability disclosure;
2. Maintaining a private communication channel for vulnerabilities to be vetted;
3. Vetting participants in the private security disclosure group;
4. Facilitating ongoing research and testing of security data;
5. Owning and publishing the base dataset of disclosures, and
6. Defining a standard for the data, which tool vendors can build on top of, and security and vendors can add data and value to as well.

To be clear, the Node Security Project itself is not being donated to the foundation, just the dataset, which the foundation will maintain.

The process for this is not yet determined, I'm opening this issue to discuss it.

For today's meeting, I'd like to talk a bit about the first weeks of the ecosystem vulnerabilities management program.

When

Thursday, Mar 2nd, 2017, 20:00 UTC: other timezones

Where

• Call URL, for participants: https://hangouts.google.com/hangouts/_/ytl/dSGd5Z7V5m5wGfmv8t0U4ZAXQmnaI3mgzPwR7WcKQc8=?eid=100598160817214911030&hl=en_US&authuser=0
• Youtube stream, for viewers: https://youtu.be/E9ToYdEkRHc
• Minutes document: https://docs.google.com/document/d/1LUqbW9ctfL1ZigYbDToEHg2vc4v-Utohd2GQ3nPOoYM/edit?usp=sharing

Agenda

• TBD

Here are the choices:

Top Level Project:
https://github.com/nodejs/TSC/blob/master/Project-Lifecycle.md

Top-Level Working Group:
https://github.com/nodejs/TSC/blob/master/WORKING_GROUPS.md

Core Working Group:
https://github.com/nodejs/node/blob/master/WORKING_GROUPS.md

It seems to me that this is probably a rare Top Level Project... but it is skipping the incubation phase I guess.

If everyone agrees, then this project should work towards completing the steps detailed in Project-Lifecycle.md.

Currently, @sam-github has been doing some nice work in #9 towards making it a Working Group- so I thought we should make sure the effort is in the right direction.

@nodejs/tsc

When

Thursday, Jan 5th, 2017, 20:00 UTC: other timezones

Where

• Call URL, for participants: https://hangouts.google.com/call/rejatsrwsfb6vkecs3pumhjjn4e
• Youtube stream, for viewers: https://www.youtube.com/watch?v=qeK267DvFM0
• Minutes document: https://docs.google.com/document/d/1cEaFh0L25hTxNrqW08w_n8gajlRzhePGeYfo714VcTY/edit?usp=sharing

Agenda

Extracted from wg-agenda issues and pull requests from this repo, and comments on this issue:

• start talks about https://github.com/dimich-g/webpackage which @groundwater, @jasnell, and @bmeck have started looking a possible avenue for code signing in the future (from #13 (comment))

Now that the Foundation can act as CNA and that the ecosystem triage process is running, it might be a good time to start back discussing about issuing CVEs for the ecosystem.

Would that require some set up on our side?

Security researchers have requested that we make an attempt at documenting this.

Hey All,

@mikesamuel, a security researcher from Google, has put together a "Security Roadmap" which outlines some best practices that companies + individuals can use when developing and deploying Node.js applications. It is 50+ pages and has had quite a bit of care put into it.

I'm opening this issue to discuss the roadmap in depth with that team before we do any sort of comms push around this, looping in the foundation marketing team and some of our resources over at google to get this in front of people. Before doing any public push we would like the @nodejs/tsc and @nodejs/security-wg to take a look and make sure there isn't anything major problems with this being shared en masse.

FWIW, security roadmap is an industry standard term (I originally was like... we don't do roadmaps 😉)

A security roadmap is a powerful tool for aligning security processes with business requirements and goals, and improving the general efficacy of the security program

When

Thursday, Dec 22nd, 20:00 UTC: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Security+WG+meeting&iso=20161222T20&p1=%3A&ah=1

Where

• Hangouts on Air, for participants: https://hangouts.google.com/call/rxgxj4m4ufeyxls4yvfp2o4pvee
• Youtube stream, for viewers: https://youtu.be/fewvQg-DaVk
• Minutes document: google doc

Agenda

Extracted from wg-agenda (once #12 is fixed) issues and pull requests from this repo, and comments on this issue:

• What to do with the Node Security Project donation?
• What is the working group? A TLP, CWG, TWG? #11

When

Thursday, Aug 10th, 2017, 20:00 UTC: other timezones

Where

• Call URL, for participants: TBD
• Youtube stream, for viewers: TBD
• Minutes document: https://docs.google.com/document/d/11aAP8mSFWSFm-aW_mue8MQVRyTGG6j-NQb3jazPizUo/edit

Agenda

• Demo of HackerOne: cv. #17 (comment)
• ... (anyone is free to edit in more to the agenda, or comment below)

There would normally be a WG meeting this Thursday, Oct 5th, but its in the middle of NINA, and many participants may be unavailable, and some may only be available for a Working Group session (https://github.com/nodejs/summit/blob/master/2017-10/agenda.md#2017-10-06-day-one) in the afternoon.

I propose we bump the meeting by a week to October the 12th.

cf. #44

Add your name here or tag people that you think might be interested in joining a public working group focused on Node.js core and ecosystem security matters.

At Node.js Interactive today, @evilpacket announced that the @nodesecurity project will be moving in to the Node.js Foundation. This Working Group should be able to inform how that integration will happen and may end up maintaining that project. The evolution of this group and its relationship with the @nodesecurity project is not defined and will be up to those involved to guide.

See #1 for a proposed purpose and scope of work for this group.

See #2 for the proposed relationship between activities here and the private management of security vulnerability reporting, patching and releasing of Node.js core.

/cc @nodejs/security

Anyone have availability to meet up for lunch or dinner tomorrow? We're looking at a get together to talk WG business at the collab summit, but since we are collaborating together I think an event to get to know each other outside of simply talking business also makes sense.

And on that note, for people who do want to meet up, any cuisines you have strong opinions on, either good or bad? I'll eat most anything, though particularly love the breadth of east Asian cuisines (Sushi, Thai, Vietnamese, Dim Sum, etc.). I'd be happy to make reservations tomorrow morning when I have a sense for how many folks we are talking about, availability (lunch, dinner) and food preferences.

I thought it would be good to write a blog post on what is currently happening within this working group and projects that you might need help on. It can be a reflection on what you've achieved in 2017 and main goals/projects you are focusing on as we kick off 2018. What does this group think? And if you like this idea, who would like to be interviewed for this blog post? I would also have you review it before we post on the Node.js Foundation and Node.js Collection Medium page. I would imagine it would be similar in format to this TSC post with a forward by someone in this group and then an explanation on what you worked on in 2017, what you are doing now and where you need help: https://medium.com/the-node-js-collection/the-current-state-of-implementation-and-planning-for-esmodules-a4ecb2aac07a

As discussed in last WG meeting, we need to set up a meeting to handover the HackerOne Organization to the core triage team:

@bnoordhuis
@indutny
@rvagg
@jasnell
@shigeki
@MylesBorins

Are you available on Wednesday 15 NOV 2017 at 19:00 UTC (other timezones) ?

Alternative dates might be Monday 20 NOV or Tuesday 21 NOV at the same time.

As raised by @Trott in #2 (comment), "Node.js Security Working Group" might not be the best name as it may lure people to think that they should report issues via the issue tracker here.

So, one of the first jobs of the group forming here is to decide on the name, both the full name and the repository name.

@joshbw can look at this, he has access internally to do this on a one-off, and can contact the semmle team

Full agenda of summit: openjs-foundation/summit#35

Will try and figure out location. Feel free to jot down some ideas for discussion here.

As discussed in last WG meeting and based on @jasnell issue regarding an early disclosure program for vulnerabilities in Node.js core. We would like to collect opinions from potential users of such initiative:

In other term, if you or an organization you are involved with would want to have access of such an early disclosure program, please explain here what you would need such program to be.

For instance, a cloud provider might want to have access to patched binaries of Node.js before their public disclosure in order to provide protection to their clients as soon as possible.

Please let us know how we can build something relevant for you.

Also, please feel free to advertise this issue to anyone who might be interested in providing feedback on this topic.

In nodejs/node#15564 (comment) @hashseed proposed that a threat model would be defined as framework for evaluating the severity of future vulnerabilities.

What are your opinions on that topic?

I had a discussion @dadinolfi from Mitre about the options for managing CVE's for Node.js.

There are 2 options that we have:

• Act as a CNA
• Use the web form to request CVE's as a one off.

Some open source projects already acting as a CNA

• OpenSSL
• Apache (covers all of apache)
• Drupal
• DWF (give CVEs for open source)

There are pros/cons as outlined in the sections which follows.

From my read of he rules and my discussion with @dadinolfi I think the extra work in being a CNA will be relatively small and have the community being able to control the CVE's assigned for Node.js would be good so I'd lean towards the option of Acting as a CNA.

Acting as CNA

When we act as a CNA, we get a block of CVE's at the start of the year and then assign these ourselves. When publicly disclose the vulnerability we use the web form (and other methods like json in the future) to provide info to Mitre which get published in the CVE. This information is relatively minimal

If any other entity wants a CVE for Node.js they will be referred to us and we decide based on the CNA rules if we believe a CVE should be assigned and if appropriate provide one to the requesting entity.

The full rules for acting as a CNA are here: http://cve.mitre.org/cve/cna/CNA_Rules_v1.1.pdf

• Pros

  • We can quickly assign CVE's
  • We have full control over the CVE's assigned for Node.js

• Cons

  • Some additional reporting requirements
  • We need to make sure those in the community implementing the process follow the rules

• misc

  • We need to be responsive to requests for CVE's
  • We need to provide Mitre with at least a couple of primary contacts that will respond to their enquiries
  • We need to plan to request our block of CVE's once a year.

CVE only public once public, don't publish number until public, release when embargo is lifted.

Web form

• Pros:

  • No pre-planning
  • Minimum work

• Cons

  • Longer cycle time to get CVE assigned and details published
  • Third parties could request/get assigned CVE's on Node.js that we may not agree with.