Repository navigation
Who should be in @nodejs/security? Who should have access to the private repo? #358
Description
As titled, here are some basic questions that we need to clarify:
- are all @nodejs/tsc members automatic members of the security team?
- how do we rotate out members of @nodejs/security that are no longer active? should they serve terms, similar to what the TSC might get?
- how do we avoid discriminating against one security company with another? It seems they would all want to be part of this.
Activity
jasnell commentedon Sep 18, 2017
Let's take a slightly different approach with this. Here are the current members of the @nodejs/security team. Let's audit the list and call for a "recertification" ...
I would apply a few immediate criteria to filter this:
Anyone on this list who is not also currently a committer to either nodejs/node or nodejs/http-parser (which correspond to the two *-private security repos we manage) should be removed automatically.
Anyone on this list who has not responded to or participated in security related discussions within the past year should be removed automatically.
Then, we can then take a look at who else is left.
dougwilson commentedon Sep 18, 2017
SGTM
sam-github commentedon Sep 18, 2017
My two bits:
I myself pass criteria 1,2, though I haven't actually fixed any sec vuln. Hm, unless we count the zlib update to address the very, very low CVEs issued against it.
I have found it quite useful to have access to the issue history, particularly when preparing nodejs/security-wg#35, and also it generally helps understand what's going on inside the black box of security. This wouldn't have been necessary if we had a issue tracker that allowed issues to be made public after the security release was made. I mention this, because its an example of our tooling creating a situation where non-security sensitive work (like retroactive review of all the vulns) requiring a person to be a sec group member.
I think part of the "who should be a member" problem could be addressed by better tooling, like Hacker One, see #344, because it would allow a smaller group of people to be assigned the responsibility of assuring reports are addressed - where addressed might mean communicating "not a sec vuln, post to the issue tracker" and making the issue public for the historical record, or could be pulling in ANY small set of nodejs collaborators (not just ones on the security team) who have the specific relevant expertise (and time at that moment) to fix the vuln. It makes the set of people who can work on vulns more dynamic, and more targetted, and increases security because only the handful of people who do first-line triage and the one or two people actually fixing will even have to know there is a vuln being fixed. It would allow most of the list members to step back of the sec team, particularly people who are there because if (for example) a V8 upgrade is required to fix a vuln, there needs to be a couple people permanently on the list with the time and expertise to do the fix.
Fishrock123 commentedon Sep 18, 2017
I've mostly been trying to move issues along here and there, as I'm not really useful in figuring out outcomes at a technical level I don't need to be on it but it may be useful for more organizational reasons.
joaocgreis commentedon Sep 18, 2017
I am on the team mainly for two reasons:
I'd be happy to be pulled in only for those types of issues, or to remain in the team while there's no process for temporary members.
Trott commentedon Sep 27, 2017
This and also how we determine membership on the security@ reporting address need to get some resolution. Labeling
tsc-agenda. @nodejs/tsc PTALRefs: nodejs/CTC#149
Refs: #354
Refs: nodejs/email#67
Trott commentedon Sep 27, 2017
pinging for input: @nodejs/security @nodejs/security-wg @bengl
Trott commentedon Sep 27, 2017
Framing for TSC conversation:
bengl commentedon Sep 27, 2017
I think for simplicity's sake, as a first step, the security@ email alias and the @nodejs/security team ought to be the exact same set of people. Once a mechanism/process for inclusion in that group is decided upon, I don't see a real need for having two separate groups.
As a second step, the security@ alias ought to be a pass-through to HackerOne or a similar tool, as @sam-github mentioned.
In terms of inclusion in the group: @jasnell's suggestion seems like a good start.
Trott commentedon Sep 29, 2017
I not sure I agree with that, but I can see how it would seem to make sense. The way I see it, the mailing list is for people to use to report vulnerabilities to the project. I imagine it's kind of important for efficiency that there not be 20 people to talk to about who might respond, but rather just three or five. Typically, things that come in on the mailing address are opened in the private security repo so everyone can see it anyway. (I have no idea what percentage of things don't end up in the repo because I'm not on the email.)
Yes, a good start. Someone will have to do the work of auditing he describes. Any volunteers?
jasnell commentedon Sep 29, 2017
codepilot commentedon Oct 6, 2017
I am interested in helping
lance commentedon Oct 10, 2017
As discussed in the collaborator's summit security working group last week, I think it is also important to outline a policy and process for downstream repackagers of Node.js to have some insight into these vulnerabilities so that we are not faced with zero-day exploits during the time between the moment a patched Node is released and when we(they) are able to deliver a patched, repackaged version.
During the wg discussions I think it was resolved that policies and process for access to embargoed information would be handled by the Foundation Board. I'd like to keep this topic on the radar.
Trott commentedon Oct 10, 2017
People that would be removed as part of @jasnell's step 1:
Auditing the second part is the hard part. Here's the list of folks that would need to be audited:
evilpacket commentedon Oct 10, 2017
I'd love to stay involved if possible. I'm a lurker and read and don't pile on with a me too if my opinion has already been communicated. I talked with @mhdawson about this at the security-wg dinner and got feedback that I should be probably speaking up to add weight depending on the conversation. I'm willing to do better to stay involved. :)
rvagg commentedon Oct 10, 2017
Can someone clarify this? How does it make sense to have the Board involved in this?
lance commentedon Oct 10, 2017
@rvagg As I recall the discussion (I didn't take copious notes) there are concerns about a few issues.
Since many of these issues involve legally binding arrangements with corporate entities, it probably makes sense that policies, if not procedures, be determined and/or directly guided by the Foundation Board.
I am not speaking for @nodejs/security, only for what was discussed in the security-wg sessions after Node Interactive last week. But as someone who is working on just such a downstream repackaging of Node.js, the issue is important to me.
sam-github commentedon Oct 10, 2017
@rvagg I've got notes, haven't had time to post them to the sec-wg repo, this was in it.
summary, probably not obvious from context: there is a desire by some redistributors of node, such as cloud providers, to get early access to sec releases so that on the day that nodejs.org releases, they can also release a fix, rather than do their 3-day delivery process while their clients have effetively zero-days.
Discussions about who would decide what organizations are have the need to know early, and how they would be vetted for reliability, seems to be a useful thing for the board to do. They might have access to how other projects do similar advanced notice.
Anyhow, this will be raised as a proposal soon, when someone (like myself) gets a bit out from under their node interactive backlog.
MylesBorins commentedon Oct 11, 2017
If I recall from when I was in the conversation it was less of having the board decide and more of asking the board for advice... specifically as to how this may have been handled in other projects as well as to find out if we need to discuss this with the legal team.
jasnell commentedon Oct 11, 2017
As @sam-github indicates, the situation is this:
There are two parts of this discussion. The first part is: who within the core team will be members of the security team and thus have early access to security reports, access to the nodejs-private repo, and access to pre-release details of security vulnerabilities.
The second part is: we've had companies express an interest in having access to pre-release details of security vulnerabilities so that they can prepare in advance of a secure release. That is the part that requires Foundation support for a number of reasons, not the least of which is dealing with the need for enforceable non-disclosure agreements necessary for a proper embargo.
mhdawson commentedon Oct 11, 2017
In terms of the audit, I think we want to balance between limiting to a small group to making sure it is not to hard for people to jump in and help out.
If only a small number of people can see the issues there and the list is growing it may be hard for other people to see than and jump in to help. We already have a good level of trust in TSC members so I'm suggest it be members of the TSC minus those that specifically ask to be removed. I say the TSC as I see some responsibility there for the general problem of making sure we are responsive to security issues.
Beyond the TSC I think it can be limited to people who are active in helping move the issues forward on a regular basis. With the move to hacker one we should be able to pull additional people in more easily on specific issues so unless people are going to be active regularly, special expertise without helping in the day to day work would likely not be a good reason anymore.
sam-github commentedon Oct 12, 2017
I documented current membership in nodejs/security-wg#55, and attempted to describe the privacy expectations. I'm sure the wording could use improvement, please help.
As discussed at NINA, I suggest once the policy is agreed on, that team members agree to the policy by PRing something into a markdown file somewhere. The PR is for discussion, I don't think the security membership and policy should be buried in a process document deep in the security-wg git repo.
I think it should be in the main node.js README, along with the privacy policy (to assure users of node.js who will have access to security reports, and what the policy is wrt. how their info will be disclosed), probably just above Release team keys: https://github.com/nodejs/node/blob/668f4cff22acd69e8505cd8c83415ee5021fe6d6/README.md#release-team
jasnell commentedon Feb 17, 2018
The discussion here has stalled. Is there a next step or can we close this?
Trott commentedon Feb 17, 2018
This was handled by the security WG. https://github.com/nodejs/security-wg/blob/master/processes/security_team_membership_policy.md