安全策略

Sails 致力于提供安全的框架，并迅速应对任何疑似安全漏洞。贡献者会仔细工作以确保最佳实践，但我们也高度依赖社区在发现、报告和修复安全问题方面的帮助。

报告 Sails 中的安全问题

如果您认为您在 Sails、Waterline 或由 Sails 核心团队维护的其他模块中发现了安全漏洞，请发送电子邮件至 critical at sailsjs dot com。本着 负责任披露 的精神，我们要求您将任何安全漏洞私下报告到该电子邮件地址，并给我们时间修复问题，然后再发布详细信息。

什么是安全漏洞？

安全漏洞是指任何可能在生产环境中损害 Sails.js 应用程序的重大错误或意外后果。

例如，在使用非标准 Grunt 任务时，Sails 在开发环境中崩溃的问题 不是安全漏洞。另一方面，如果可以对在生产环境中运行并使用文档化最佳实践（例如 Express/Connect 主体解析器问题）的 Sails 集群进行简单的 DoS 攻击，那么 就是一个安全漏洞，我们希望了解它。

请注意，此定义包括由于我们的依赖项之一而存在的任何此类漏洞。在这种情况下，升级到不同版本的依赖项并不总是必要的：例如，当 Express 3 在核心代码中弃用 multipart 上传支持时，Sails.js 通过在 multiparty 模块周围实现一个名为 Skipper 的包装器来处理功能不匹配。

电子邮件中应该包含哪些内容？

• 您发现安全漏洞的模块的名称和 NPM 版本字符串（例如 Sails、Waterline、其他核心模块）。
• 漏洞的摘要
• 您在发现漏洞时使用的代码或漏洞的代码示例（以较短者为准）。
• 您是否希望我们将您的参与公开。如果您希望这样做，请提供您希望被引用的名称和链接（例如，Jane Doe 的 GitHub 帐户链接）。

请尊重核心团队的隐私，不要将因未记录的用法、问题或功能请求而导致的错误发送到此电子邮件地址。

流程

当您报告漏洞时，项目成员之一将在最多 72 小时内回复您。此回复很可能是对我们已收到报告并会立即调查它的确认。我们大多数安全漏洞的目标修复时间框架为 14 天。

根据漏洞的性质以及修复所需的时间，我们将要么发送一个禁用损坏功能的补丁，要么提供修复所需时间的估计，要么记录应遵循的最佳实践以避免生产问题。

您可以期待后续电子邮件，概述解决方案的进展，以及我们可能对您的体验提出的任何其他问题。

当解决方案达成时，我们将执行以下操作

• 通知您
• 在 NPM 上发布补丁
• 与 Node Security 协调发布 咨询，并给予您署名（除非您明确要求不署名）。
• 通过我们的 新闻组 公开发布。

这是 SLA 吗？

不是。Sails 框架根据 MIT 许可 提供，不包含服务级别协议。但是，核心团队和贡献者非常关心 Sails，我们所有人都拥有在生产环境中运行的 Sails 网站和 API。我们 始终 会尽快发布任何严重安全漏洞的修复程序——不仅出于我们内心的善良，还因为这也会影响我们的应用程序（以及我们客户的应用程序）。

有关更多支持选项，请参见 https://sails.js.cn/support。