Sails 致力於提供安全的框架,並快速回應任何可疑的安全性漏洞。貢獻者們仔細工作以確保最佳實踐,但在發現、報告和修復安全性問題方面,我們也非常依賴社群。
如果您認為在 Sails、Waterline 或 Sails 核心團隊維護的其他模組中發現了安全性漏洞,請發送電子郵件至 critical at sailsjs dot com。秉持著責任揭露的精神,我們要求您透過該電子郵件地址私下報告任何安全性漏洞,並給予我們時間修補問題,然後再發布詳細資訊。
安全性漏洞是指任何可能危害生產環境中 Sails.js 應用程式的重大錯誤或非預期後果。
例如,當使用非標準 Grunt 任務時,Sails 在開發環境中崩潰的問題並不是安全性漏洞。 另一方面,如果可以對在生產環境中運行並使用已記錄最佳實踐的 Sails 集群執行簡單的 DoS 攻擊(類似於 Express/Connect body parser 問題),那就是安全性漏洞,我們希望知道。
請注意,此定義包括因我們的依賴項之一而存在的任何此類漏洞。 在這種情況下,不一定需要升級到不同版本的依賴項:例如,當 Express 3 棄用核心中的 multipart 上傳支援時,Sails.js 通過實作一個名為 Skipper 的 multiparty 模組的包裝器來處理功能不匹配的問題。
請尊重核心團隊的隱私,不要將因未記錄的使用方式、問題或功能請求而產生的錯誤發送到此電子郵件地址。
當您報告漏洞時,專案成員之一將在最多 72 小時內回覆您。 此回覆很可能是確認我們已收到報告,並將立即進行調查。 我們針對大多數安全性漏洞的目標修補時間範圍是 14 天。
根據漏洞的性質以及修復所需的時間,我們將發布禁用損壞功能的修補程式,提供修復所需時間的估計,以及/或記錄避免生產問題的最佳實踐。
您可以期待收到後續電子郵件,概述漏洞解決方案的進展以及我們可能對您的經驗提出的任何其他問題。
不。 Sails 框架根據 MIT 許可證提供,其中不包含服務等級協議。 然而,核心團隊和貢獻者們非常關心 Sails,我們所有人都有網站和 API 在生產環境中運行在 Sails 上。 我們將始終盡快發布針對任何嚴重安全性漏洞的修復程式——不僅僅是出於善意,而是因為它也可能影響我們的應用程式(以及我們客戶的應用程式)。
如需更多支援選項,請參閱 https://sails.dev.org.tw/support。