can we improve the security reporting process for node

sam-github commented 7 years ago

In https://github.com/nodejs/security-wg/issues/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 commented 7 years ago

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

sam-github commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

+1 for bugzilla.

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

deian commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

who operates the current secure@ email address?

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

Trott commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

While I've never used their product from a vendor perspective - I can say that from the reporting side of things (reporting bugs into hackerone) it's a nice experience for bug reporters. I'm a huge +1 for using a platform like this to improve the reporting and disclosure process.

On Mon, Jul 31, 2017 at 5:03 PM, Josh Brown-White notifications@github.com wrote:

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?

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/nodejs/security-wg/issues/17#issuecomment-319230050, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHEOS08erznsei7Sx4GWcanvpzRpO6lks5sTms8gaJpZM4LcFS5 .

SomeoneWeird commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

I'm going to close this in favour of https://github.com/nodejs/TSC/issues/344, too many places of discussion is confusing.

nodejs / security-wg

can we improve the security reporting process for node #17