Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can we improve the security reporting process for node #17

Closed
sam-github opened this issue Jan 5, 2017 · 21 comments
Closed

can we improve the security reporting process for node #17

sam-github opened this issue Jan 5, 2017 · 21 comments

Comments

@sam-github
Copy link
Contributor

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
Copy link
Contributor Author

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

@sam-github
Copy link
Contributor Author

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
Copy link
Contributor Author

@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
Copy link
Member

deian commented Feb 21, 2017

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
Copy link
Member

+1 for bugzilla.

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

@deian
Copy link
Member

deian commented Feb 21, 2017

@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
Copy link
Member

@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
Copy link

joshbw commented Mar 3, 2017

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
Copy link
Contributor Author

@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
Copy link

joshbw commented Jun 29, 2017

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
Copy link
Member

who operates the current secure@ email address?

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

@Trott
Copy link
Member

Trott commented Jun 29, 2017

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
Copy link

joshbw commented Jul 6, 2017

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.

@joshbw
Copy link

joshbw commented Aug 1, 2017

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?

@evilpacket
Copy link
Contributor

evilpacket commented Aug 1, 2017 via email

@SomeoneWeird
Copy link
Member

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

@sam-github
Copy link
Contributor Author

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

@reedloden
Copy link
Contributor

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

@reedloden
Copy link
Contributor

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.

@cjihrig
Copy link
Contributor

cjihrig commented Aug 11, 2017

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

@sam-github
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants