Djangoのセキュリティポリシー
Djangoの開発チームは、セキュリティ関連の問題の責任ある報告と開示に力を注いでいます。 そのため、私たちはその理想に準拠し、Djangoの公式ディストリビューションおよびサードパーティディストリビューションにタイムリーなセキュリティアップデートを提供できるようにすることを目的とした一連のポリシーを採用し、それに従います。
セキュリティ問題の報告
ショートバージョン：[email protected] にメールでセキュリティの問題を報告してください。
Djangoのほとんどの通常のバグは私たちのパブリックTracインスタンスに報告されますが、セキュリティ問題の機密性のため、この方法で公開されないようにお願いします。
代わりに、セキュリティに影響を与える何かをDjangoで見つけたと思われる場合は、問題の説明を[email protected]に電子メールで送信してください。 そのアドレスに送信されたメールは、セキュリティチームに届きます。
電子メールで問題を送信すると、48時間以内にセキュリティチームのメンバーから確認が届きます。実行するアクションによっては、さらにフォローアップの電子メールが届く場合があります。
暗号化されたレポートの送信
暗号化された電子メール（オプション）を送信する場合、[email protected]の公開鍵IDは0xfcb84b8d1d17f80bであり、この公開鍵は最も一般的に使用されるキーサーバーから入手できます。
サポートされているバージョン
Djangoチームはいつでも、Djangoのいくつかのバージョンに対して公式のセキュリティサポートを提供しています。
- Djangoの次のメジャーリリースとなるGitHubでホストされているメイン開発ブランチは、セキュリティサポートを受けています。 メインの開発ブランチにのみ影響し、安定したリリースバージョンには影響しないセキュリティの問題は、開示プロセスを経ることなく公開で修正されます。
- 最新の2つのDjangoリリースシリーズはセキュリティサポートを受けています。 たとえば、Django 1.5のリリースに至る開発サイクル中に、Django1.4とDjango1.3のサポートが提供されます。 Django 1.5のリリース時に、Django1.3のセキュリティサポートは終了します。
- 長期サポートリリースは、指定された期間、セキュリティアップデートを受け取ります。
セキュリティ上の理由で新しいリリースが発行された場合、付随する通知には影響を受けるバージョンのリストが含まれます。 このリストは、Djangoのサポートされているバージョンのみで構成されています。古いバージョンも影響を受ける可能性がありますが、それを判断するための調査は行われず、これらのバージョンのパッチや新しいリリースは発行されません。
Djangoがセキュリティの問題を開示する方法
セキュリティの問題を非公開の議論から公開に移すための私たちのプロセスには、複数のステップが含まれます。
一般公開の約1週間前に、次の2つの通知を送信します。
まず、 django-announce に、今後のセキュリティリリースの日付とおおよその時刻、および問題の重大度を通知します。 これは、アナウンスのトリアージを処理し、必要に応じてDjangoをアップグレードするためのスタッフを確保する必要がある組織を支援するためです。 重大度レベルは次のとおりです。
高：
- リモートコード実行
- SQLインジェクション
中程度：
- クロスサイトスクリプティング（XSS）
- クロスサイトリクエストフォージェリ（CSRF）
- サービス拒否攻撃
- 壊れた認証
低：
- 機密データの公開
- 壊れたセッション管理
- 未検証のリダイレクト/転送
- 珍しい構成オプションを必要とする問題
次に、人と組織のリストを通知します。これらは、主にオペレーティングシステムベンダーとDjangoの他のディストリビューターで構成されています。 このメールは、 Djangoのリリースチームの誰かのPGP鍵で署名されており、次のもので構成されています。
- 問題と影響を受けるバージョンのDjangoの完全な説明。
- 問題を解決するために実行する手順。
- Djangoに適用されるパッチ（ある場合）。
- Djangoチームがこれらのパッチを適用し、新しいリリースを発行し、問題を公開する日付。
開示当日、以下の措置を講じます。
- 関連するパッチをDjangoのコードベースに適用します。
- Python Package Index とDjangoWebサイトに新しいパッケージを配置し、Djangoのgitリポジトリで新しいリリースにタグを付けて、関連するリリースを発行します。
- 公式のDjango開発ブログに公開エントリを投稿し、問題とその解決策を詳細に説明し、関連するパッチと新しいリリースを示し、問題のレポーターにクレジットを付与します（レポーターが公開を希望する場合）識別）。
- ブログ投稿にリンクしている django-announce および [email protected] メーリングリストに通知を投稿してください。
報告された問題が特に時間に敏感であると考えられる場合（たとえば、野生での既知のエクスプロイトのため）、事前通知から一般公開までの時間が大幅に短縮される可能性があります。
さらに、報告された問題がPython / Webエコシステムの他のフレームワークまたはツールに影響を与えると考える理由がある場合は、適切なメンテナと非公開で連絡して話し合い、独自の開示と解決を彼らと調整することがあります。
Djangoチームは、Django で開示されているセキュリティ問題のアーカイブも保持しています。
事前通知を受け取るのは誰か
セキュリティ問題の事前通知を受け取る人と組織の完全なリストは公開されておらず、今後も公開されません。
また、開示前の機密情報の流れをより適切に管理するために、このリストを可能な限り小さく保つことを目指しています。 そのため、通知リストはではなく単なるDjangoのユーザーのリストであり、Djangoのユーザーであることは通知リストに掲載される十分な理由ではありません。
大まかに言えば、セキュリティ通知の受信者は次の3つのグループに分類されます。
- Djangoパッケージの問題を報告するため、または一般的なセキュリティ報告のために、適切に一般的な（つまり、ではなく個人の電子メールアドレス）連絡先アドレスを提供するDjangoのオペレーティングシステムベンダーおよびその他のディストリビューター。 いずれの場合も、そのようなアドレスは公開メーリングリストやバグトラッカーに転送してはなりません。 個々のメンテナまたはセキュリティ応答の連絡先のプライベート電子メールに転送するアドレスは許容されますが、プライベートセキュリティトラッカーまたはセキュリティ応答グループが強く推奨されます。
- ケースバイケースで、これらの通知に対応し、責任を持って行動することへのコミットメントを示した個々のパッケージメンテナー。
- ケースバイケースで、Django開発チームの判断で、保留中のセキュリティ問題を認識する必要がある他のエンティティ。 通常、このグループのメンバーシップは、Djangoの既知のユーザーまたはディストリビューターの中で最大の、および/または深刻な影響を受ける可能性が最も高いもので構成され、責任を持って受信し、機密を保持し、これらの通知に基づいて行動する実証済みの能力が必要になります。
セキュリティ監査およびスキャンエンティティ
ポリシーとして、これらのタイプのエンティティを通知リストに追加しません。
通知のリクエスト
あなたまたはあなたが代表する権限を与えられている組織が上記のグループのいずれかに該当すると思われる場合は、[email protected]に電子メールを送信して、Djangoの通知リストへの追加を依頼できます。 件名「セキュリティ通知リクエスト」をご利用ください。
リクエストには次の情報が含まれている必要があります。
- 氏名、代表する組織の名前（該当する場合）、およびその組織内での役割。
- あなたまたはあなたの組織が上記の基準の少なくとも1つのセットにどのように適合するかについての詳細な説明。
- セキュリティ通知を要求する理由の詳細な説明。 繰り返しになりますが、これはではなく Djangoのユーザー向けのリストであり、圧倒的多数のユーザーは django-announce に登録して、セキュリティの事前通知を受け取る必要があることに注意してください。詳細な通知を要求するのではなく、問題の詳細なしでリリースが行われます。
- 通知リストに追加したいメールアドレス。
- そのアドレスに送信されたメールを誰が受信/レビューするかについての説明、および実行される自動化されたアクションに関する情報（つまり、バグトラッカーでの機密問題の提出）。
- 個人の場合、必要に応じて、受信した電子メールを確認し、送信された電子メールを暗号化するために使用できる、アドレスに関連付けられた公開鍵のID。
送信されると、リクエストはDjango開発チームによって検討されます。 30日以内にリクエストの結果を通知する返信が届きます。
また、個人または組織にとって、セキュリティ通知の受信はDjango開発チームの独自の裁量で付与される特権であり、この特権は説明の有無にかかわらずいつでも取り消すことができることにも注意してください。
必要なすべての情報を提供する
最初の連絡先で必要な情報を提供しなかった場合、リクエストを承認するかどうかを決定する際にカウントされます。
