Cross-project-council: Responsible security disclosures

Created on 19 Sep 2019  Â·  18Comments  Â·  Source: openjs-foundation/cross-project-council

Is there a standard way for OpenJSF projects to accept responsible security disclosures or is the expectation that projects set up their own solution?

Node.js has its own policy, for example. I don't know about other projects.

I feel like it would be nice if this was something the foundation handled for projects (even if the project would be the one responsible for dealing with the disclosure itself).

cross-project-council-agenda

Most helpful comment

We've definitely discussed trying to replicate some of the work that has
been done in core... especially around managing CNA and CVE stuff.

With githubs new announcement though perhaps we should look at working with
them... as the management of the CNA is a non-trivial amount of work.

On Wed, Sep 18, 2019 at 6:50 PM Wes Todd notifications@github.com wrote:

Related: nodejs/package-maintenance#159
https://github.com/nodejs/package-maintenance/issues/159

Our Node WG has been having some discussions around this. If the
foundation was going to have something it should align with what the
Maintenance WG and Security WG recommend.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/openjs-foundation/cross-project-council/issues/326?email_source=notifications&email_token=AADZYVY57TQLI3PW5G4Z463QKKWBVA5CNFSM4IYEPJW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7BVVNQ#issuecomment-532896438,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADZYV3A5SIGWKN6UF32XR3QKKWBVANCNFSM4IYEPJWQ
.

All 18 comments

Related: https://github.com/nodejs/package-maintenance/issues/159

Our Node WG has been having some discussions around this. If the foundation was going to have something it should align with what the Maintenance WG and Security WG recommend.

We've definitely discussed trying to replicate some of the work that has
been done in core... especially around managing CNA and CVE stuff.

With githubs new announcement though perhaps we should look at working with
them... as the management of the CNA is a non-trivial amount of work.

On Wed, Sep 18, 2019 at 6:50 PM Wes Todd notifications@github.com wrote:

Related: nodejs/package-maintenance#159
https://github.com/nodejs/package-maintenance/issues/159

Our Node WG has been having some discussions around this. If the
foundation was going to have something it should align with what the
Maintenance WG and Security WG recommend.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/openjs-foundation/cross-project-council/issues/326?email_source=notifications&email_token=AADZYVY57TQLI3PW5G4Z463QKKWBVA5CNFSM4IYEPJW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7BVVNQ#issuecomment-532896438,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADZYV3A5SIGWKN6UF32XR3QKKWBVANCNFSM4IYEPJWQ
.

The Node.js security working group also does work in this area, and HackerOne who we work with handle the CVEs for the ecosytem reports. I've pinged that team through https://github.com/nodejs/security-wg/issues/578

There have been discussions as to wether part of the Node.js security-wg which focuses on ecosystem triage should move up to the OpenJS level. This is probably a good time to continue that discussion. @sam-github

https://github.com/nodejs/security-wg/pull/579 relates to this slightly, in that if the responsibilities of the nodejs/security-wg become more clearly and singularly focussed on the Ecosystem outside Node.js, they might be a candidate to move up a level.

Also, note that even though many, perhaps most, of the vulns in the DB are reported against "Node.js" packages, a number of those packages can also run in the browser, and there are at least a handful (or were, last time I surveyed them a couple years ago) that are npm package that run ONLY in the browser, so the WG is already in some sense collecting and triaging non-Node.js vulnerabilities.

I brought this up some weeks ago when triaging a report of a vulnerability in a React component: clearly only intended to work in the browser but still distributed via the npm.

I would definitely be up for discussion about taking our work in the Node.js ecosystem triage team to the OpenJS foundation level.

PR in package main repo which is related: https://github.com/nodejs/package-maintenance/pull/277

@MarcinHoppe has created draft security guidelines for the Node.js Package Maintenance team that you can see here: https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/security-guidelines.md

@MarcinHoppe has also started to capture current security practices for OpenJS projects here: https://gist.github.com/MarcinHoppe/b13a870770522c31a8386ada48b2e40f

@tobie has started the conversation within the AMP project here: https://github.com/ampproject/wg-security-privacy/issues/2

Followed up with Marcin today and noting that the next step is:

Minimal requirements that we'd expect Foundation projects to meet in terms of security reporting and a simple policy/implementation of that could be used by projects to meet that.

I am back on track on this one and will have a revised version ready for the next round of reviews before the end of this week.

Thanks all for your patience about it.

I added a new file with requirements, I'd love some feedback about it on the PR: https://github.com/openjs-foundation/cross-project-council/pull/489#issuecomment-635903804.

Thanks. Looped-in AMP‘s security team.

PR to move guidelines to stage 2 - https://github.com/openjs-foundation/cross-project-council/pull/566. Thanks @MarcinHoppe

Last step is to move to stage 3, @MarcinHoppe do you want to open the PR to move to stage 3.

@mhdawson I opened ~#602~ #633 to move the proposal to stage 3.

Thanks for merging #633. Are we good to close this issue?

Hell ya! Thanks for your work!

Was this page helpful?
0 / 5 - 0 ratings