Write and publish responsible disclosure policy

[kevinburkeshyp]

• 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]

As mentioned in the Waterline issue this would be great.

[kevinburkeshyp]

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]

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]

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?

[mikermcneil]

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

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

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

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

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

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]

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

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

[joepie91]

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]

Sweet! Thank you.

[rachaelshaw]

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]

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