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

Write and publish responsible disclosure policy #2830

Closed
kevinburkeshyp opened this issue Apr 10, 2015 · 16 comments

Comments

9 participants
@kevinburkeshyp
Copy link

commented Apr 10, 2015

  • If I find a critical vulnerability in Sails how should I communicate it to the core team?
  • What guarantees are given about time to a patch?
  • Will reporters be credited for their work in finding a vulnerability?
  • How are critical security vulnerabilities disclosed to the community?
  • Are vulnerabilities given a CVE number?
  • Once you write a page like this, how can I be expected to find it?

Here is an example of what a page like this should look like: http://docs.python-requests.org/en/latest/community/vulnerabilities/

@particlebanana

This comment has been minimized.

Copy link
Contributor

commented Apr 10, 2015

As mentioned in the Waterline issue this would be great.

@kevinburkeshyp

This comment has been minimized.

Copy link
Author

commented Apr 13, 2015

Understood, and it's fine if the policy is so long in the future as "we promise to push a fix within 60 days", just communicating expectations is a good thing for people reporting issues.

@kevinburkeshyp

This comment has been minimized.

Copy link
Author

commented Apr 14, 2015

Not necessarily asking you to guarantee some kind of SLA.

I'm just asking for, like, if someone comes to you with "here is a query string that will crash the Node process for every sails user" or "I found a SQL injection attack that allows a full database dump for anyone that's using waterline", if that person doesn't hear back from you, they are going to get antsy, worry that someone else will find it/exploit it, possibly decide to go public before a patch has been prepared, etc.

I know open source is a volunteer thing, but, I don't think "we will respond to your security disclosure within 14|30|60|N days" is an unreasonable burden.

@CWyrtzen

This comment has been minimized.

Copy link

commented Aug 5, 2015

Did the comments and PR cover the issue? Can we close this up? It will always be searchable and can be reopened for discussion at any time, of course?

@tjwebb tjwebb closed this Sep 10, 2015

@balderdashy balderdashy locked and limited conversation to collaborators Sep 10, 2015

@mikermcneil mikermcneil reopened this Sep 16, 2015

@balderdashy balderdashy unlocked this conversation Sep 16, 2015

@mikermcneil

This comment has been minimized.

Copy link
Member

commented Sep 16, 2015

@joepie91 @kevinburkeshyp sorry I wasn't a part of this discussion. My apologies for comments being deleted-- it won't happen again. These are absolutely valid concerns, and I'd like to have discourse about it. I've unlocked and reopened this issue.

@irlnathan started on official documentation for the vulnerability reporting process, but we haven't put it online yet. I'll check on the status of that and make sure we get that up soon.

@mikermcneil

This comment has been minimized.

Copy link
Member

commented Sep 16, 2015

@kevinburkeshyp Ok the security issue reporting doc is now moved from https://github.com/balderdashy/vulnerability-disclosure/blob/master/vuDisclosure.md to the official Sails docs repo here. We'll get it live on http://sailsjs.org some time today.

@joepie91

This comment has been minimized.

Copy link

commented Sep 16, 2015

@mikermcneil Thank you for picking it back up, very happy to see that :)

What kind of disclosure/patch timeframe do you feel would be achievable, generally speaking?

@mikermcneil

This comment has been minimized.

Copy link
Member

commented Sep 16, 2015

@joepie91 so it will depend on the severity of the issue-- e.g. if there was an issue where Sails can crash in a development environment with non-standard Grunt tasks, then it would be difficult for any of our core team to guarantee we can jump in and help. On the other hand, if it's a real security vulnerability (a la the Express/Connect body parser issue back in the day), it will be a drop-everything-and-fix kind of situation, and we'll get a fix out as soon as possible. If a fix isn't possible in a relatively short window of time (I'd say 1-2 weeks), we'll add clear comments to the documentation. Like any open-source project, we can't legally guarantee anything (the MIT license has the "as-is" clause for a reason), but I can tell you that I stake my professional reputation on it.

@mikermcneil

This comment has been minimized.

Copy link
Member

commented Sep 16, 2015

@joepie91 same thing applies for any of our dependencies (e.g. Express 3). If it impacts production usage of Sails itself, we're still ultimately responsible for dealing with it (we've all got a bunch of Sails apps running in production ourselves). And even if StrongLoop/IBM has stopped officially supporting Express 3, if we're using it in the latest stable version of Sails, we'll take care of any serious security/vulnerability issues that touch documented usage of Sails features.

@joepie91

This comment has been minimized.

Copy link

commented Sep 16, 2015

I see. Given the liability concern, perhaps it'd be a possibility to state something along the lines of:

Our target patching timeframe for (non-DoS) security issues is 14 days - however, we cannot guarantee that this is possible in all cases.

That should still set a concrete expectation for the majority of users, but would provide an 'out' when it's really not possible, and wouldn't create legal liabilities (although you may want to run that by a lawyer, of course - IANAL).

Such a statement, combined with a verifiable track record, would provide a pretty good (public) assurance as to how security issues are handled, I think.

@mikermcneil

This comment has been minimized.

Copy link
Member

commented Sep 16, 2015

@joepie91 I think so too. I just pushed some additional language based on our conversation (providing examples and non-examples). @rachaelshaw just moved it into a new folder for doc compilation (updating the link above)

@mikermcneil

This comment has been minimized.

Copy link
Member

commented Sep 16, 2015

@joepie91 Also borrowed your language re: patching timeframe- hope that's alright :)

@joepie91

This comment has been minimized.

Copy link

commented Sep 16, 2015

Sure, borrow away, you can generally assume anything I write/make to be under WTFPL/CC0 anyway :)

The language that's there now looks good to me.

@mikermcneil

This comment has been minimized.

Copy link
Member

commented Sep 16, 2015

Sweet! Thank you.

@rachaelshaw

This comment has been minimized.

Copy link
Member

commented Sep 16, 2015

Alrighty here it is live: http://sailsjs.org/security-policy
(it'll be accessible via a link from the "Support" page when the CloudFlare cache is invalidated.)

@luislobo

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2017

Follow up: now it is located in http://sailsjs.com/security

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.