Initial project boilerplate and README

PR-URL: nodejs/security-wg#9
Reviewed-By: Michael Dawson <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: Sam Roberts <[email protected]>
Reviewed-By: Adam Brady <[email protected]>

CONTRIBUTING.md

@@ -0,0 +1,33 @@
+# Contributing to security-wg
+
+## Code of Conduct
+
+The [Node.js Code of Conduct][] applies to this repo.
+
+[Node.js Code of Conduct]: https://github.com/nodejs/node/blob/master/CODE_OF_CONDUCT.md
+
+## Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+* (a) The contribution was created in whole or in part by me and I
+  have the right to submit it under the open source license
+  indicated in the file; or
+
+* (b) The contribution is based upon previous work that, to the best
+  of my knowledge, is covered under an appropriate open source
+  license and I have the right under that license to submit that
+  work with modifications, whether created in whole or in part
+  by me, under the same open source license (unless I am
+  permitted to submit under a different license), as indicated
+  in the file; or
+
+* (c) The contribution was provided directly to me by some other
+  person who certified (a), (b) or (c) and I have not modified
+  it.
+
+* (d) I understand and agree that this project and the contribution
+  are public and that a record of the contribution (including all
+  personal information I submit with it, including my sign-off) is
+  maintained indefinitely and may be redistributed consistent with
+  this project or the open source license(s) involved.

GOVERNANCE.md

@@ -0,0 +1,121 @@
+# Security Working Group
+
+The Node.js Security Working Group project is jointly governed by a Working
+Group (WG) that is responsible for high-level guidance of the project.
+
+The WG has final authority over this project including:
+
+- Technical direction
+- Project governance and process (including this policy)
+- Contribution policy
+- GitHub repository hosting
+- Conduct guidelines
+- Maintaining the list of additional Collaborators
+
+For the current list of WG members, see the project README.md.
+
+## Collaborators
+
+The security GitHub repository is maintained by the WG and additional
+Collaborators who are added by the WG on an ongoing basis.
+
+Individuals making significant and valuable contributions are made Collaborators
+and given commit-access to the project. These individuals are identified by the
+WG and their addition as Collaborators is discussed during the periodic WG
+meeting.
+
+Note: If you make a significant contribution and are not considered for
+commit-access log an issue or contact a WG member directly and it will be
+brought up in the next WG meeting.
+
+Modifications of the contents of the security repository are made on a
+collaborative basis. Anybody with a GitHub account may propose a modification
+via pull request and it will be considered by the project Collaborators. All
+pull requests must be reviewed and accepted by a Collaborator with sufficient
+expertise who is able to take full responsibility for the change. In the case of
+pull requests proposed by an existing Collaborator, an additional Collaborator
+is required for sign-off. Consensus should be sought if additional Collaborators
+participate and there is disagreement around a particular modification. See
+Consensus Seeking Process below for further detail on the consensus model used
+for governance.
+
+Collaborators may opt to elevate significant or controversial modifications, or
+modifications that have not found consensus to the WG for discussion by
+assigning the WG-agenda tag to a pull request or issue. The WG should serve as
+the final arbiter where required.
+
+For the current list of Collaborators, see the project README.md.
+
+## WG Membership
+
+WG seats are not time-limited. There is no fixed size of the WG. However, the
+expected target is between 6 and 12, to ensure adequate coverage of important
+areas of expertise, balanced with the ability to make decisions efficiently.
+
+There is no specific set of requirements or qualifications for WG membership
+beyond these rules.
+
+The WG may add additional members to the WG by unanimous consensus.
+
+A WG member may be removed from the WG by voluntary resignation, or by unanimous
+consensus of all other WG members.
+
+Changes to WG membership should be posted in the agenda, and may be suggested as
+any other agenda item (see "WG Meetings" below).
+
+If an addition or removal is proposed during a meeting, and the full WG is not
+in attendance to participate, then the addition or removal is added to the
+agenda for the subsequent meeting. This is to ensure that all members are given
+the opportunity to participate in all membership decisions. If a WG member is
+unable to attend a meeting where a planned membership decision is being made,
+then their consent is assumed.
+
+No more than 1/3 of the WG members may be affiliated with the same employer. If
+removal or resignation of a WG member, or a change of employment by a WG member,
+creates a situation where more than 1/3 of the WG membership shares an employer,
+then the situation must be immediately remedied by the resignation or removal of
+one or more WG members affiliated with the over-represented employer(s).
+
+## WG Meetings
+
+The WG meets periodically on a Google Hangout On Air. A designated moderator
+approved by the WG runs the meeting. Each meeting should be published to
+YouTube.
+
+Items are added to the WG agenda that are considered contentious or are
+modifications of governance, contribution policy, WG membership, or release
+process.
+
+The intention of the agenda is not to approve or review all patches; that should
+happen continuously on GitHub and be handled by the larger group of
+Collaborators.
+
+Any community member or contributor can ask that something be added to the next
+meeting's agenda by logging a GitHub Issue. Any Collaborator, WG member or the
+moderator can add the item to the agenda by adding the WG-agenda tag to the
+issue.
+
+Prior to each WG meeting the moderator will share the Agenda with members of the
+WG. WG members can add any items they like to the agenda at the beginning of
+each meeting. The moderator and the WG cannot veto or remove items.
+
+The WG may invite persons or representatives from certain projects to
+participate in a non-voting capacity.
+
+The moderator is responsible for summarizing the discussion of each agenda item
+and sends it as a pull request after the meeting.
+
+## Consensus Seeking Process
+
+The WG follows a Consensus Seeking decision-making model.
+
+When an agenda item has appeared to reach a consensus the moderator will ask
+"Does anyone object?" as a final call for dissent from the consensus.
+
+If an agenda item cannot reach a consensus a WG member can call for either a
+closing vote or a vote to table the issue to the next meeting. The call for a
+vote must be seconded by a majority of the WG or else the discussion will
+continue. Simple majority wins.
+
+Note that changes to WG membership require unanimous consensus. See "WG
+Membership" above.

LICENCE.md

@@ -1,11 +1,22 @@
 The MIT License (MIT)
 =====================
 
-Copyright (c) 2016 Node.js Foundation
+Copyright (c) 2017 Node.js Foundation
 -------------------------------------
 
-Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+Permission is hereby granted, free of charge, to any person obtaining a copy of
+this software and associated documentation files (the "Software"), to deal in
+the Software without restriction, including without limitation the rights to
+use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
+the Software, and to permit persons to whom the Software is furnished to do so,
+subject to the following conditions:
 
-The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
 
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
+FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
+COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
+IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE

README.md

@@ -1,15 +1,53 @@
-# Node.js Security Working Group
+# Security Working Group
 
-## Purpose
+***Note: this group is in the process of seeking Charter by the TSC
+(https://github.com/nodejs/TSC/issues/175)***
 
-_... help fill this in!_
+## Mandate
+
+The Security Working Group's purpose is to achieve the highest level of security
+for Node.js and community modules.
+
+Its responsibilities are:
+
+* Define and maintain security policies and procedures for:
+  - the core Node.js project
+  - other projects maintained by the Node.js Foundation technical group
+- Work with the node security project to bring community vulnerability data into
+  the foundation as a shared asset.
+- Set up processes and procedures and follow these to ensure the vulnerability
+  data is updated in an efficient and timely manner. For example, ensuring there
+  are well documented processes for reporting vulnerabilities in community
+  modules.
+- Work to set a high standard for the Node.js project. Possibly efforts could
+  include penetration testing, security reviews etc, review guidelines, coding
+  standards etc.
+- Review and recommend processes for handling of security reports (but not the
+  actual handling of security reports, which are reviewed by a group of people
+  directly delegated to by the CTC).
+- Define and maintain policies and procedures for the coordination of security
+  concerns within the external Node.js open source ecosystem.
+- Offer help to npm package maintainers to fix high-impact security
+- Maintain and make available data on disclosed security vulnerabilities in:
+  - the core Node.js project
+  - other projects maintained by the Node.js Foundation technical group
+  - the external Node.js open source ecosystem
+- Promote improvement of security practices within the Node.js ecosystem
+- Recommend security improvements for the core Node.js project
+- Facilitate and promote the expansion of a healthy security service and product
+  provider ecosystem vulnerabilities.
 
 ## Private Node.js core security group
 
-The Node.js Security Working Group is _not_ responsible for managing incoming security reports to the [email protected] address, nor is it privy to or responsible for preparing embargoed security patches and releases.
+The Node.js Security Working Group is _not_ responsible for managing incoming
+security reports to the [email protected] address, nor is it privy to or
+responsible for preparing embargoed security patches and releases.
 
-The Node.js CTC maintains primary responsibility for the management of private security activities for Node.js core but relies on the Node.js Security Working Group to recommend and help maintain policies and procedures for that management.
+The Node.js CTC maintains primary responsibility for the management of private
+security activities for Node.js core but relies on the Node.js Security Working
+Group to recommend and help maintain policies and procedures for that
+management.
 
-## Members
+## Current Project Team Members
 
-_... could this be you?_
+*TBD*