can we improve the security reporting process for node about security-wg HOT 21 CLOSED

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

from security-wg.

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

from security-wg.

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 [email protected] 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

from security-wg.

@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?

from security-wg.

+1 for bugzilla.

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

from security-wg.

@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.

from security-wg.

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

from security-wg.

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/

from security-wg.

@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.

from security-wg.

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

from security-wg.

who operates the current secure@ email address?

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

from security-wg.

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

from security-wg.

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.

from security-wg.

Talked with HackerOne last week - they are happy to have a discussion with everyone involved in the current process to see if their platform is a good fit but having had a quick tour of it from the view of a security manager it looks like it will. Node.js basically meets all of the criteria to use their platform for free (short of having a Security.md file pointing reporters at HackerOne, but that's a two minute fix once we have the platform ready to accept reports). Who is interested in chatting with their community manager and seeing HackerOne in action?

from security-wg.

from security-wg.

We use HackerOne at work - it fits really well (for us) . I would be happy to drive this if we're looking for someone.

from security-wg.

Who is interested in chatting with their community manager and seeing HackerOne in action?

I'm interested in that, do you think having them join the wg call is a good way to do this?

Do you have any idea whether they have API endpoints? Are we going to be able to write a small script to extract the reports into JSON and PR into https://github.com/nodejs/security-wg/tree/master/vuln/npm (or the node folder, as appropriate)?

from security-wg.

@sam-github yup, HackerOne has a full API. Check out https://api.hackerone.com for all the documentation, including clients for Ruby, Python, and Go (sadly, no Node.js version yet, but perhaps you could make one!).

from security-wg.

Also, HackerOne is a CNA and can assign CVEs for Node.js as needed. We already do this for Ruby and several other open source projects.

from security-wg.

@nodejs/security, this working group received a demo of HackerOne at today's meeting. Some of you should have received invitations to try HackerOne. The topic of using it for Node core vulnerabilities came up. Would you be open to looking into it?

from security-wg.

I'm going to close this in favour of nodejs/TSC#344, too many places of discussion is confusing.

from security-wg.