セキュリティポリシー

Sailsは安全なフレームワークを提供し、疑わしいセキュリティの脆弱性には迅速に対応することに尽力しています。コントリビューターはベストプラクティスを確実に遵守するために注意深く作業していますが、セキュリティ問題の発見、報告、および修復に関しては、コミュニティに大きく依存しています。

Sailsにおけるセキュリティ問題の報告

Sails、Waterline、またはSailsコアチームが保守する他のモジュールにセキュリティの脆弱性があると判断した場合は、critical at sailsjs dot comまでメールでお知らせください。責任ある開示の精神に基づき、そのメールアドレスにセキュリティの脆弱性を非公開で報告し、詳細を公開する前に問題を修正する時間をください。

セキュリティの脆弱性とは何か？

セキュリティの脆弱性とは、本番環境でSails.jsアプリケーションを危険にさらす可能性のある、重大なバグまたは意図しない結果です。

たとえば、非標準のGruntタスクを使用する場合に開発環境でSailsがクラッシュする問題は、セキュリティの脆弱性ではありません。一方、本番環境で動作し、文書化されたベストプラクティスを使用しているSailsクラスタに対して、些細なDoS攻撃を実行できる場合（Express/Connect body parserの問題など）、それはセキュリティの脆弱性であり、お知らせいただきたいと考えています。

この定義には、依存関係の1つに起因する脆弱性も含まれます。この場合、依存関係の異なるバージョンへのアップグレードは常に必要とは限りません。たとえば、Express 3でコアのマルチパートアップロードサポートが非推奨になった場合、Sails.jsはSkipperと呼ばれるmultipartyモジュールをラップすることで、機能の不一致に対処しました。

メールに含めるべきもの

• セキュリティの脆弱性が見つかったモジュールの名前とNPMバージョン文字列（例：Sails、Waterline、その他のコアモジュール）。
• 脆弱性の概要
• 脆弱性を発見した際に使用したコード、または脆弱性のコード例（どちらか短い方）。
• ご自身の関与を公開してほしいかどうか。参照を希望する場合は、希望する名前とリンク（例：Jane DoeのGitHubアカウントへのリンク）を記載してください。

コアチームのプライバシーを尊重し、文書化されていない使用方法、質問、または機能要求に起因するバグをこのメールアドレスに送信しないでください。

プロセス

脆弱性を報告すると、プロジェクトメンバーの1人が最大72時間以内に返信します。この返信は、レポートを受信し、ただちに調査を開始したことを確認するものになる可能性が最も高いです。ほとんどのセキュリティの脆弱性に対するパッチ適用目標期間は14日です。

脆弱性の性質と修正に必要な時間に基づいて、壊れた機能を無効にするパッチを送信するか、修正にかかる時間の概算を提供するか、または本番環境の問題を回避するためのベストプラクティスを文書化します。

脆弱性に対する解決策の進捗状況と、ご経験に関するその他の質問について、フォローアップメールが届きます。

解決策が達成されたら、次のことを行います。

• 通知します。
• NPMでパッチをリリースします。
• Node Securityと協力してアドバイザリを発行し、（明示的に匿名を希望しない限り）クレジットします。
• 当社のニュースグループでリリースを公表します。

これはSLAですか？

いいえ。SailsフレームワークはMITライセンスに基づいて提供されており、サービスレベルアグリーメントは含まれていません。しかし、コアチームとコントリビューターはSailsを非常に重視しており、私たち全員が本番環境でSails上で動作するウェブサイトとAPIを持っています。私たちは、単なる好意だけでなく、私たちのアプリケーション（そして顧客のアプリケーション）にも影響を与える可能性があるため、深刻なセキュリティの脆弱性に対する修正を常にできるだけ早く公開します。

その他のサポートオプションについては、https://sails.dokyumento.jp/supportを参照してください。