Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

process: describe sec team membership and policy #56

Closed
wants to merge 5 commits into from
Closed

process: describe sec team membership and policy #56

Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
81e71ad
process: describe sec team membership and policy
sam-github Oct 12, 2017
f8a01d5
fixup! process: describe sec team membership and policy
sam-github Oct 23, 2017
34fd329
fixup! fixup! process: describe sec team membership and policy
sam-github Oct 23, 2017
791dfaf
fixup! fixup! fixup! process: describe sec team membership and policy
sam-github Oct 23, 2017
814cc85
fixup! fixup! fixup! fixup! process: describe sec team membership and…
sam-github Oct 24, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
92 changes: 92 additions & 0 deletions processes/security_team_members.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
# Node.js Security Team

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am assuming this is intended specifically to describe the security team for Node.js core rather than the third party modules process, correct? If so, it would be good to state that up front.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is will eventually describe all the Node.js Security Teams, as the same privacy policy will apply to all of them.

The third party module process and teams are not yet listed, because they don't exist (yet).

Node.js security team members are expected to keep all information that they have
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/Node.js security team/Node.js Core Security Team

privileged access to by being on the team completely private to the team. This
includes notifying anyone outside the team of issues that have not yet been
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This includes not notifying ... ?

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.

Membership on the security teams can be requested via an issue in the TSC repo,
and must be approved by current team members.

Members of the security teams should indicate that they accept the privacy
policies by PRing their acceptance to this file.

## Team that triages security reports against node core

- @bnoordhuis - **Ben Noordhuis**
- @indutny - **Fedor Indutny**
- @rvagg - **Rod Vagg**
- @jasnell - **James M Snell**
- @shigeki - **Shigeki Ohtsu**
- @MylesBorins - **Myles Borins**

List is from ["security" alias](https://github.com/nodejs/email/blob/master/iojs.org/aliases.json).

## Team with access to security issues
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So thinking about this particular list... I think we should manage this differently. Within the nodejs-private GitHub organization, only the Triage team above should have general access to everything. When a new security vulnerability is reported, a new private fork repo within nodejs-private is created by a member of the triage team, and a new GitHub team specific to that one repo is created by the Triage team member. That specific team can pull in any other collaborator/contributor is necessary to address that one problem so long as they agree to the confidentiality requirement. Once the issue is resolved and the fix lands in nodejs/node master, the individual fix repo in nodejs-private is archived and the GitHub team is dissolved.

This accomplishes several things:

  1. We have targeted and specific control over who has access to the specific security vulnerability details
  2. Each security issue will have it's own issues/PR tracker
  3. We don't have to maintain a list like the one below

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the generalities of what you describe above, but the current list is a statement of fact, not of how it could be. Adoption of new tooling, proposed in nodejs/TSC#344 and not generating much interest, would cause a change in the process. For example, some of what you describe above is specific to the tooling used, once @vdeturckheim has made more progress on #57 , it may be easy to demonstrate the process, and propose it to be used for node core - at which point these specific teams may cease to exist, but the privacy policy will continue to be relevant.


- @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**

List is from [nodejs/teams/security](https://github.com/orgs/nodejs/teams/security/members).

## Team with access to private security patches

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So there need to be explicitly defined groups here:

We have:

  1. The Triage Team -- the small group that looks at initial reports and determines who the fix team should be.
  2. The Fix Team -- the small group of Collaborators with access to the private repo for fixing a specific issue
  3. The Review Team -- the slight larger group of trusted Collaborators who review and validate a fix immediately before release.

The group below should essentially be the Review Team. They may not be the ones actually working on the fix, and may not get the full details of the vulnerability right away, but they are expected to review and sign off on the fix before it goes out the door. Personally, I think the Review Team should be limited strictly to TSC members. If non-TSC members are required to help resolve an issue, they should be brought in on the Fix Team.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In WG meetings, we felt that proposals to change the current process for core would best be raised after #54 is done, so changes to the core process can be proposed in the context of the tooling to be used. Just a suggestion, of course the TSC can change the sec process and team arrangement at any time. If you would like to kick off that discussion immediately I suggest opening a separate issue or PR.

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

List is from
[orgs/nodejs-private/people](https://github.com/orgs/nodejs-private/people),
who have access to
[nodejs-private/node-private](https://github.com/nodejs-private/node-private).

Every member of the team with access to security issues should have access to
the private security patches as well.