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

Security Reporting guideline draft #277

Open
wants to merge 2 commits into
base: master
from

Conversation

@MarcinHoppe
Copy link

MarcinHoppe commented Oct 31, 2019

As a follow up to the discussion in #159 I put together a draft guidelines doc that I would love to have a discussion about.

The guidelines doc is mainly influenced by my experiences working with the Ecosystem Security WG.

Copy link
Member

mhdawson left a comment

LGTM I think this is a good draft. I would agree that moving the Security policy in a GitHub repository up to the top of the list would be good.


### Responsible disclosure

Public disclosure should follow release of a patch that addresses a vulnerability.

This comment has been minimized.

Copy link
@wesleytodd

wesleytodd Nov 1, 2019

Member

Could we add something about working with the maintainer to do the public disclosure? I have seen many times that the report to these tools is not quite right in it's version ranges, or that the description is not quite right, and this causes confusion and work for maintainers.

It would be much better if the maintainers were involved so that they are aware and can collaborate on what their users will see.

This comment has been minimized.

Copy link
@dougwilson

dougwilson Nov 1, 2019

Member

The main issue that occurs with version ranges is instead of asking the author they sometimes just assume it affected all previous versions and/or there is confusion if there were multiple release lines patched

This comment has been minimized.

Copy link
@MarcinHoppe

MarcinHoppe Nov 4, 2019

Author

Wouldn't this be something to put into the security policy itself, rather than this guidelines document?

My reasoning here is that this guidelines document will mostly be read and used by package maintainers, not the security research community.


## Examples

Here are several examples of short and useful security policies:

This comment has been minimized.

Copy link
@Eomm

Eomm Nov 3, 2019

Member

I would improve this section because the use cases are different and we could help to choose the user:

  • Node.js Ecosystem Security WG Template -> the template valid for every nodejs package
  • Express Security Policies and Procedures -> support custom (email) and the common Node.js Ecosystem Security WG Template
  • Node-RED Security Policy -> prefer a custom process via email

In Fastify we aligned to the common Node.js Ecosystem Security WG Template

So we have all the case:

  • if a module doesn't have a security policy (wins the Node.js Ecosystem Security WG Template)
  • if a module supports a custom process + the common one
  • if a module prefer a custom process
  • if a module state the common one

This comment has been minimized.

Copy link
@MarcinHoppe

MarcinHoppe Nov 4, 2019

Author

We definitely could change this section from Examples to How to craft your security policy depending on how prescriptive we want this guidance to be.

@ljharb @mhdawson @wesleytodd @dougwilson @Eomm given that most maintainers are probably not security experts, do you feel we should make this more prescriptive rather than just suggesting options?

This comment has been minimized.

Copy link
@mhdawson

mhdawson Nov 4, 2019

Member

I think the discussion you have with the options, followed by providing our "recommendation" along with a template that could be used would be good. It would provide some background info and then provide our recommended approach that can be easily followed unless the maintainer has specific requirements/reasons to do otherwise.

This comment has been minimized.

Copy link
@wesleytodd

wesleytodd Nov 5, 2019

Member

I would guess that most maintainers have a process they would like to follow despite not always being "security experts" to minimize the impact of supposed "security experts" reporting publicly. So in that light, I agree that options with a recommendation is good.

Also, if the maintainer does not expect to support their package with prompt security updates that is fine, but they should state that in their policy. And we should add a section about that.

docs/drafts/security-guidelines.md Show resolved Hide resolved
docs/drafts/security-guidelines.md Show resolved Hide resolved
@mhdawson

This comment has been minimized.

Copy link
Member

mhdawson commented Dec 2, 2019

@MarcinHoppe have you addressed all of the outstanding comments?

@nodejs/package-maintenance any more comments on this? If not more approvals would help us get it landed.

@ljharb
ljharb approved these changes Dec 2, 2019
@MarcinHoppe

This comment has been minimized.

Copy link
Author

MarcinHoppe commented Dec 2, 2019

@mhdawson I actually have 2 outstanding comments to address. I will make the edits tomorrow or Wednesday the latest and will ask for the last review before making a request to land this.

@styfle
styfle approved these changes Dec 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.