diff --git a/meetings/2016-12-02/minutes.md b/meetings/2016-12-02/minutes.md new file mode 100644 index 000000000..2398657b0 --- /dev/null +++ b/meetings/2016-12-02/minutes.md @@ -0,0 +1,125 @@ +# Node.js Security Working Group Meeting Dec 2, 2016 + +* Date: 2016-12-02 +* Notes: + +* GH issue: N/A + +An informal meeting at the Node.js Interactive North America 2016 Collaborators +summit, to discuss the formation of a Security Working Group. + + +## Attendees + +* Bryan English @bengl +* Devon Rifkin @drifkin +* James Snell @jasnell +* Matteo Collina @mcollina +* Michael Alexander @mgalexander +* Michael Dawson @mhdawson +* Myles Borins @thealphanerd +* Rod Vagg @rvagg +* Sam Roberts @sam-roberts +* William Kapke @williamkapke + + +## Discussion + +Discussion was free form, notes follow. + +Role of Security WG: + +* Define what it means to bring NSP into the Foundation. +* Define/refine process for security releases. + * Delegate actual triage of vulnerabilities to private group. +* Single location with info about vulnerabilities in various versions of Node, + similar to CVE data. +* Should security research and auditing be done proactively by Node? + +For example, HTTP has vulnerabilities because it’s loose with the protocol. Role +of security group could be to set policies, such as whether we should make the +HTTP implementation stricter. + +Purpose is *not* to respond to reports of security issues with Node.js, that is +done by the "security team", see https://github.com/nodejs/node#security + +A problem has been that people expect that code is sandboxed in Node as in +browser, but in fact it’s not. Part of work of Security WG could be to clarify +that. + +Work Areas to be discussed in working group meetings, but topics raised +included: + +- Is it worth looking at getting a sec eval of node? + +- What is security? + - Is there definitions that would help us? does CVE/CERT/? have + classifications we can use? + - It would be helpful to have a stance on this so we can more clearly respond + to issues that are reported or claimed as "security issues", and we can + clarify what is a security problem. But err on the side of allowing more, as + sometimes other useful bugs come through. + - Could use existing classification systems, like “Data Disclosure”, “Remote + Code Execution”, etc. + + +Ecosystem: + +- sec-wg could take some responsibility for fixing ecosystem issues +- Need to also help module authors, for example we’ve filed CVE’s for npm + before. +- Best practices on sec problems could use definition and + publication/evanglizing, so npmjs.org packages can follow a well-known and + robust procedure: + - What should an npm module author do if an issue is found in their module? + - How should they deal with it? + - Should there be a CVE? + - How should we (node/the node foundation/sec-wg) communicate with the + author? + - Its possible there should be a community vulnerability response list, that + is available if people want to report a vulnerability in community modules, + but don't know how, and do not want it in a public issue/PR on the modules + github repo. + - We could encourage package authors to include security contact info for + their packages. + +Create security guidelines and best practices for PR reviewers and module +authors? + +Why machine readable security reports/info? To enable an ecosystem on top of +the data, such as `snyk` and `nsp`. + + +Who might contribute to security research for Node? +* Paid professional auditors +* Existing security companies, e.g. Snyk, Lift, etc. +* Universities and students + + +If Node.js wants to support signed modules, would this be managed by the +Security WG? CTC would ask for guidance from Security WG. Person who prepares PR +could collaborate with Security WG at start. Partly depends on earned trust of +Security WG. + +Recommendations to the CTC and others on security-related proposals would +ideally be part of this group’s role. + +OpenSSL is a significant source of issues, and Linux Foundation is working to +address. Would be ideal to involve Linux Foundation Core Infrastructure +Initiative (CII), which is responsible for core Internet components like +OpenSSL. + + +Several teams with different responsibilities: + +* Security Response for Core +* Security Response for Ecosystem +* Security Policy + +Ultimately it’s the CTC’s responsibility for executing/implementing policy, so +Response team for Core should report to CTC. + +Should ecosystem response team be different? Would then be under management of +TSC. + +Work closely with Linux Foundation Core Infrastructure Initiative.