Skip to content

Commit

Permalink
doc: add minutes for October 12th, 2017
Browse files Browse the repository at this point in the history
Close: nodejs/security-wg#52
Close: nodejs/security-wg#53
PR-URL: nodejs/security-wg#55
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
  • Loading branch information
mattstern31 committed Oct 23, 2017
1 parent 90d4389 commit bf7f2d6
Showing 1 changed file with 111 additions and 0 deletions.
111 changes: 111 additions & 0 deletions meetings/2017-10-12.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,111 @@
# Security WG meeting 2017-10-12

GitHub issue: https://github.com/nodejs/security-wg/issues/52
Meeting video: https://www.youtube.com/watch?v=iN366--sK0M
Previous meeting: https://github.com/nodejs/security-wg/pull/32


# Present

- Bryan English (@bengl)
- Devon Rifkin (@drifkin)
- Sam Roberts (@sam-github)
- Vladimir de Turckheim (@vdeturckheim)
- Bryce Baril (@brycebaril)
- Michael Alexander (@mgalexander)
- Adam Baldwin (@evilpacket)
- Michael Dawson (@mhdawson)

# Review of last meeting actions

Actions from last meeting that are now complete:

- [x] Michael: will document the security release process
- [x] Michael: will add recurring sec-wg meeting to calendar

# New agenda

## threat model for Node.js (#51)

- Vladimir has done some risk analysis, and can draft something
- Adam has done some informal modeling from an attacker perspective, but not so
familiar with formal models, but willing to help out
- Sam: what is purpose of this?
- ?: V8 team, for example, wants to know what is a vuln
- Sam: hopes that the informal docs will be get better as more of the issue
discussion becomes public
- Deian: has received some informal responses from node.js sec email address
describing what they think is or is not a vulnerability, will ask if he can
post the output here to seed discussion.

## add Daniel Kluss to sec-wg team (#50)

- No objections, approved

## Have node become a CNA, so it can issue its own CVEs (#33)

- Sam: Broad TSC agreement to do this
- Sam: Michael to do the work to apply for being a CNA
- Sam: we can be CNA for node.js core, we can use the CVEs for thirdparty if we wish to, even if not CNA --- or we can use hackerone to get CVEs
- Sam: did NSP get CVEs for the thirdparty vulns?
- Adam: yes, we asked for them for a while, tried to get finders to do it, but
we didn’t get mitre response, it was frustrating. Being a CNA will make it
much better. Hackerone has offered to bulk assign CVEs for the nsp vulns that
don’t have one

## Implement process for management of thirdparty vulnerabilities (#54)

- Todo list in issue updated with comments from WG and volunteers to do some
parts of the work

## Discussion of who are members of the security WG.

- See https://github.com/nodejs/security-wg/issues/53#issuecomment-335926742
- Sam: perhaps port current process to hackerone, then update process once we have agreement on the new tool

## Who will get thirdparty package reports?

- See https://github.com/nodejs/security-wg/issues/53#issuecomment-335926742
- Adam: Qualifications: mostly doing coordination, willing to do some research,
sometimes very technical, and other times pretty cut-n-dry. Also, some
vulnerabilities are only vulns if used in a particular way, which can bog down
into whether the use-case that is vulnerable is “common”.
- Bryce: could promise some resources
- Adam: intel might have some resources, if we contact them, they may provide
a person
- Michael alexander: also willing
- Sam: we will definitely need a list when we start the process, until hackerone
is setup, we can wait a bit for commitments to do this work

## what are the privacy expectations for the triage teams?

- See https://github.com/nodejs/security-wg/issues/53#issuecomment-335926742
- Deian: does that mean if you know about it because you are on sec team you cannot fix it in your own private projects?
- All?: yes
- Dawson: being aware should not allow internal patching, because that is leak from the sec team, and gives team members an advantage over the rest of the team
- Adam: barring an early access list, this means that its completely private
- Bryce: does this apply to closed source products derived from node? Should this be covered?
- Dawson: yes, even without source, its still reverse engineerable
- Bryce: for example, in past they have built on patches to be ready to release
- next steps: Here is privacy policy for the security group, PR it, and get some
kind of (PR based?) process so people can indicate they agree to the process
- Sam: will take a shot at documenting this process

## Pre-release access for co-ordinated release

- See https://github.com/nodejs/security-wg/issues/53#issuecomment-335926742
- Lots of discussion about how to vet, consequences for not respecting the
pre-release confidentiality, etc.
- Sam: I don’t think we can do anything except to kick this back to the TSC, but
we will need to specify what action we would like to happen
- Sam: Open an issue in the TSC repo, and target @MylesBorins as the board
representative

# Actions

- [ ] @vdeturckheim: HackerOne setup (#54)
- [ ] @sam-github: document privacy expectations for triage teams (#56)
- [ ] @sam-github: open an issue in the TSC repo to request board organize
an early access program
- [ ] @mdawson: get node foundation set up as CNA for Node.js
- [ ] @vdeturkheim: draft threat model for Node.js (#51)

0 comments on commit bf7f2d6

Please sign in to comment.