diff --git a/meetings/2017-10-12.md b/meetings/2017-10-12.md
new file mode 100644
index 0000000..a9b69a9
--- /dev/null
+++ b/meetings/2017-10-12.md
@@ -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)