doc: add minutes for August 8th, 2017

meetings/2017-08-10.md

@@ -0,0 +1,98 @@
+# Security WG meeting 2017-08-10
+
+- GitHub issue: https://github.com/nodejs/security-wg/issues/32
+- Meeting video: N/A
+- Previous meeting: https://github.com/nodejs/security-wg/pull/28
+
+
+# Present
+
+- Josh Brown-White (@joshbw)
+- Colin Ihrig (@cjihrig)
+- Reed Loden (@reedloden)
+- Deian Stefan (@deian)
+- Michiel Prins (@michiel3)
+- Bryan English (@bengl)
+- Devon Rifkin (@drifkin)
+- Sam Roberts (@sam-github)
+
+# Review of last meeting
+
+Actions from https://github.com/nodejs/security-wg/blob/ac6623f305002b973011d58f4e2485a0f1e2a0b5/meetings/2017-07-13.md#actions
+
+- [ ] Michael: will document the security release process
+- [ ] Michael: will add recurring sec-wg meeting to calendar
+- [x] Sam: will schedule the next WG meeting (https://github.com/nodejs/security-wg/issues/32)
+- [x] Sam: will look at https://github.com/rubysec/ruby-advisory-db to see how they store vulnerabilities for gems and ruby (see end of file)
+- [x] Sam: will PR a description of what Node.js considers a security issue (https://github.com/nodejs/security-wg/issues/18) See https://github.com/nodejs/node/pull/14485
+- [x] JoshBW: will evaluate HackerOne and BugCrowd (https://github.com/nodejs/security-wg/issues/16, https://github.com/nodejs/security-wg/issues/17)
+- [x] JoshBW: will investigate what it takes to get a semmle.com license for Node.js as an open source project (https://github.com/nodejs/security-wg/issues/29)
+
+# Agenda
+
+## HackerOne Demo
+
+Reed gave a demo of HackerOne’s dashboard.  He sent out a bunch of demo
+accounts.  If you didn’t get an email and would like a demo account please ping
+@reedloden (reed @ hackerone.com)
+
+Can’t set an “auto-disclosure” after X days of filings in the settings (though
+you can after a bug was resolved), but probably possible with the API.
+Normally disclosure requires an intentional act within the report UI.
+
+Full API (https://api.hackerone.com).  Probably not a Node.js library for it
+yet (Ruby, Python, Go, etc. are present)
+
+Can issue CVEs for both node and npmjs.org packages if we choose to go down
+that route.
+
+Two possible use-cases:
+1. Node vulnerabilities
+2. Npmjs.org package vulnerabilities
+
+For npmjs.org packages, HackerOne looks to have a great feature set, CVE
+issuance and the rich permission model among them.
+
+
+I’d like to see some investigation of the API to ensure we can pull issues out
+as JSON for storage in github.com, but otherwise I think we should try it out.
+
+For node vulnerabilities, we’ll have to pitch HackerOne to the core members of
+the Node Security Response Team, Ben and Fyodor at least. The thing they might
+find most compelling for use with node core relates to permissions, since the
+Response team size has been described as too large recently. Use of HackerOne
+will allow:
+- Web or email submission of vulnerabilities, with the submitter being allowed
+  to view and discuss the submission directly using the web UI.
+- The conversation history to be made public when a vulnerability is
+  publicized: ATM all conversations about vulnerabilities are private for ever,
+  unnecessarily.
+- A triage team of 3 or 4 people who can see every submission, and either
+  reject it as not a vulnerability, or assign it to the correct people to work on
+  it further (those people would get access to only the one specific pre-release
+  vulnerabilty). This would allow, for example, HTTP experts who are not on the
+  Response team to be brought into the discussion of an HTTP issue. It would also
+  allow the setup of a team to further triage npmjs.org package vulnerability
+  reports, so the response team can re-assign non-node core vulnerabilities.
+
+## rubysec organization
+
+- Github: https://github.com/rubysec/ruby-advisory-db
+- Stores vuln per file, covers both gems (`gems/`) and ruby runtimes (`rubies`)
+- Every vuln has a CVE or a OSVDB, but the OSF (open security foundation) has
+  closed shop, and all the OSVDB links are now dead
+- Vuln files are named after the CVE/OSVDB ID, so they must request one for every
+  submitted vuln. @reedloden of HackerOne manages this process, allocating them
+  for ruby. It involves filling in a form of basic information, and he offered
+  to do this for Node.js as well.
+- Vuln schema: https://github.com/rubysec/ruby-advisory-db#schema
+- Vulns can be submitted via PR, or a form (https://rubysec.com/advisories/new),
+  but there isn’t any information on what the disclosure policy is. The form
+  suggests to me that they expect to see only reports for issues that are already
+  publically known and reported to the gem authors (and possibly already fixed).
+- A tool is included to check for vulnerabilities:
+  https://github.com/rubysec/bundler-audit
+- Has a website: https://rubysec.com/, from which you can get Atom updates of
+  vulns, browse the DB using a web UI, report vulnerabilities, and it also points
+  to the bundler audit utility.
+- No information on policies or procedures that I found.