can we improve the security reporting process for node

[sam-github]

In #6, it was suggested that email alone is not sufficient for reporting vulnerabilities, we need a more trackable system of interaction.

@mikeal suggests some work is ongoing to make this happen. This issue is to open this discussion.

[sam-github]

Once #15, the meeting notes merges, I will pull the comments on this out of the meeting notes to seed the conversation.

[sam-github]

From https://github.com/nodejs/security-wg/blob/master/meetings/2016-12-22.md

• Deian: Fraser and I have disclosed some vulns to core, and want a description
  of what is a sec vuln, and not just a bug. Describing this may be difficult,
  but without a threat model, its hard to communicate. Communication with public
  is important, needs to be a clear mailing list, or email. It was hard to know
  if communication was with official committee, or just an individual on the
  committee.
• Mikeal: not sure if we will find a model
• Matteo: concerned about possibility that a package author may have disappeared
  or not be willing to fix a vuln. This is a major concern. How do we deal with
  those cases.
• Deian: sees core and ecosystem as different areas, while related in terms of
  process and goals, are different enough they may be distinct. Ecosystem in
  particular, because foundation doesn’t control code
• James: to be clear, we are not planning to actively begin researching
  vulnerabilities?
• Mikeal: if someone comes forward and wants to do research (like fuzzing with
  google tools) we should be open to it. May need to supply patches to
  ecosystem. Foundation would support the group if they want to do more active
  research
• Sam: we should discuss a what’s next
• Sam: I’ll open an issue for next meeting
• James: before next, would like clarity on work areas
• Sam: would like sample of nsp data so we can begin discussion of what to do
  with it
• James: does Baldwin want to be involved?
• Mikeal, Sam: yes
• Sam: nsp data import is one issue, another is the reporting and response
  channel for vulnerabilities from ecosystem
• Deian: reporting to security@nodejs.org was a black hole… maybe a bugzilla
  would be better?
• Mikeal: maybe a help-desk like thing, so you have a private communication
  channel, and yet something better than email
• Devon: such a thing would also offer historical information
• Sam: summary is we need a github issue tracker alternative that can contain
  vuln reports, for private communication with reporter, and to allow timed
  publishing/announcement, and after vuln mitigation is announced, can be made
  completely public for historical record
• William: maybe we can build some kind of facade over our private repo, to
  selectively publish them
• Johan: use same thing as we do in the secrets repo, use gpg encryption, and
  only share keys with some people
• Sam: I’m concerned we are building another issue tracker
• Mikeal: thinks it would just be a bot that publishes a private to public
  mirror
• Deian: doesn’t think that works, he can’t participate during early stage
• Mikeal: thinks we have automation that can allow a non-privileged user to
  interact via email with issues in an otherwise private github issue tracker
• Sam: we’ll move conversation to github

[sam-github]

@mikeal @williamkapke You two are involved in some kind of github tooling exercise you thought would help build an issue tracker where only the vulnerability reporter and the node security response team would be able to see the vulnerability report and conversation at first, and it could be made public later?

@deian can you point to any project that you think is doing this better, so we can see what tools they use?

[deian]

The chromium and mozilla folks are doing a great job IMO. I would honestly recommend looking a bugzilla before rebuilding things, but that's just my 2c

[SomeoneWeird]

+1 for bugzilla.

side note; The Chromium bug tracker is interesting, as vulns are never revealed to the public either.

[deian]

@SomeoneWeird some are after the 90 day embargo. (Some remain hidden for who knows how long.) The thing I like about their process (that bugzilla I think also has) is that I get to see their changes an comments about things I report. It's not a black hole.

[SomeoneWeird]

@deian Ah ok, it must have changed over the last year or two, they never used to release them, glad they do now though

[joshbw]

I threw out HackerOne as an option to investigate in the meeting yesterday (though as I said, my experience is only using the platform to report issues). Looks like they now offer a free platform for open source projects: https://threatpost.com/hackerone-offers-open-source-projects-free-access-to-platform/124070/

[sam-github]

@joshbw Do you have time to evaluate HackerOne and come back and tell us whether its a good tool for Node? Maybe a quick demo, or some notes on why it would fit our needs, or not? For both nsp data managment, and/or node itself.

[joshbw]

I'll be on vacation through mid-next week, but will tackle it then if nobody else has cycles. Initially it seems like we either currently meet, or could easily meet all of the requirements to get free usage under their open source program: https://www.hackerone.com/blog/HackerOne-Professional-Free-For-Open-Source-Projects

who operates the current secure@ email address? While I am happy to investigate, I don't want to recommend a new solution without input from the folks dealing with the current one

[bnoordhuis]

who operates the current secure@ email address?

A subset of @nodejs/security: at this time yours truly, @indutny, @rvagg and @shigeki, I think.

[Trott]

who operates the current secure@ email address?

A subset of @nodejs/security: at this time yours truly, @indutny, @rvagg and @shigeki, I think.

And @jasnell too. You can see the recipients of security@ at https://github.com/nodejs/email/blob/0239b99434da3f67c717b1ac1ad8957abb6cf96e/iojs.org/aliases.json#L41-L47

[joshbw]

Thanks. Will any of you be able to attend the meeting next Thursday that Sam is setting up? I'd really like to hear your wishlist for a security tracking system, as well as things you would definitely like to avoid, so that I can do a first pass on something like HackerOne/BugCrowd/a hosted Bugzilla/etc. and make informed suggestions your way.