contentドキュメントへの更新が頻繁に発行されており、このページの翻訳はまだ行われている場合があります。最新の情報については、「英語のドキュメント」を参照してください。業界における脆弱性の開示についてGitHub上のプロジェクトの脆弱性の報告と開示について脆弱性の開示は、セキュリティの報告者とリポジトリメンテナの調整された取り組みです。業界における脆弱性の開示について脆弱性の開示は、セキュリティの研究者などの脆弱性の報告者とプロジェクトのメンテナとの間の協力が非常に重要な分野です。潜在的に有害なセキュリティの脆弱性が見つかったときから、脆弱性が世界に向けて公開され、理想的にはパッチが利用可能になるまで、どちらも協力しあって作業しなければなりません。通常は、誰かがメンテナに対してセキュリティの脆弱性について個人的に知らせると、メンテナはパッチを開発し、検証し、プロジェクトあるいはパッケージのユーザに通知します。脆弱性の初期の報告は非公開で行われ、完全な詳細はメンテナが問題を認め、理想的には対策もしくはパッチが利用可能になり、場合によってはパッチがインストールできるようさらに時間をおいてから公開されます。脆弱性報告者のためのベストプラクティス脆弱性をメンテナに非公開で報告するのは良いやり方です。可能なら、脆弱性報告者は以下を避けることをおすすめします。メンテナに対策の機会を与えることなく脆弱性を公開してしまうこと。メンテナをバイパスしてしまうこと。コードの修正バージョンが利用可能になる前に脆弱性を公開してしまうこと。パブリックなバウンティプログラムが存在しない場合に、問題の報告に補償がなされると期待すること。メンテナに連絡を取ろうとしてレスポンスがなかったり、連絡は取れたものの公開をあまりに長く待つよう頼まれたなら、一定期間後に脆弱性報告者が脆弱性を公開することは許容できます。脆弱性の報告者は、報告のプロセスの一部として、開示ポリシーの条件を明確に述べることをおすすめします。脆弱性報告者が厳密なポリシーに従っていないばあいでも、意図的な脆弱性の開示の時期についてメンテナが明確な期待を持てるようにするのは良い考えです。メンテナのためのベストプラクティスメンテナは、脆弱性の報告をいつどのように受けたいかを明確に示しておくのが良いでしょう。どのように連絡をすればいいか分からず、gitのコミット履歴から開発者のメールアドレスを取り出して適切なセキュリティに関する連絡先を見つけようとするかもしれません。これは、不和、報告の喪失、未解決の報告の公開につながるかもしれません。メンテナは、適時に脆弱性を開示すべきです。リポジトリにセキュリティ脆弱性があるなら、以下のようにすることをおすすめします。脆弱性は、レスポンスにおいても開示においても単純なバグとしてよりもセキュリティの問題として対処してください。リリースノートではその問題をセキュリティ脆弱性として明示的に言及する必要があります。脆弱性報告を受け取ったことは、たとえすぐに調査するためのリソースがない場合でも、できるだけ早く認めてください。これはあなたが迅速に対応して行動するというメッセージを送ることになり、あなたと脆弱性報告者との間のそれ以外のやりとりに肯定的なトーンが設定されます。報告のインパクトと正確性を検証する際には、脆弱性報告者にも関わってもらってください。脆弱性の報告者は、すでにその脆弱性を様々なシナリオの中で考慮するのに時間をかけているでしょう。その中には、あなたが自分では考えていなかったものがあるかもしれません。脆弱性の報告者が提供してくれた懸念点とアドバイスを慎重に考慮に入れて、適切と思われる方法で問題に対処してください。脆弱性の報告者は、しばしば特定のコーナーケースや対処のバイパスに関する知識を持っており、それらはセキュリティ研究のバックグラウンドなしでは簡単に見逃してしまうものです。発見されたことを評価する際には、常に脆弱性の報告者に感謝を示してください。できるかぎり早い修正の公開を目指してください。脆弱性を開示する際には、広汎なエコシステムがその問題と対策を認識するようにしてください。認識されたセキュリティの問題がプロジェクトの現在の開発ブランチで修正されながら、そのコミットあるいはそれ以降のリリースがセキュリティ修正あるいはリリースとして明示的に示されていない場合が珍しくありません。これによって、下流の利用者に問題が生じることがあります。セキュリティ脆弱性の詳細を開会しても、メンテナが悪く見えることはありません。セキュリティ脆弱性はソフトウェアのあらゆるところに存在し、ユーザはコード中のセキュリティ脆弱性を開示するための明確な確立されたプロセスを持つメンテナを信頼します。メンテナと連絡を取ります。アドバイザリを作成します。メンテナに直接、非公開で脆弱性の詳細を開示します。標準プロセスGitHub.com上のプロジェクトの脆弱性の報告と開示のプロセスは以下のようになります。あなたが脆弱性の報告したいと考えている人(たとえばセキュリティ研究者)なら、まず関連するリポジトリにセキュリティポリシーがあるかをチェックしてください。ポリシーの追加」を参照してください。セキュリティポリシーがあるなら、そのリポジトリのセキュリティチームに連絡する前に、それに従ってプロセスを理解してください。セキュリティポリシーがないなら、メンテナへの非公開のコミュニケーション方法を確立するための最も効率的な方法は、望ましいセキュリティの連絡先を尋ねるIssueを作成することです。そのIssueはすぐに公に見ることができるようになるので、そこにはバグに関する情報は含めないようにするべきであることには注意してください。コミュニケーションが確立できたら、将来的に利用できるよう、セキュリティポリシーを規定してもらうメンテナに提案できます。パッケージのマルウェアに関する報告を受けた場合は、お客様個人にご連絡させていただきます。あなたが適時問題に対応しない場合、私たちはその問題を開示します。GitHub.comでセキュリティ脆弱性を発見したら、私たちの調整された開示プロセスを通じてその脆弱性を報告してください。アドバイザリの概要」を参照してください。あなたがメンテナなら、リポジトリのセキュリティポリシーを設定するか、たとえばプロジェクトのREADMEファイルでセキュリティの報告方法を明確にしておくことによって、このパイプラインの開始時点からプロセスの所有権を取ることができます。ポリシーの追加」を参照してください。セキュリティポリシーがない場合、セキュリティの報告者はおそらくあなたにメールするか、非公開であなたに連絡しようとするでしょう。誰かがセキュリティの問題の詳細を含む(パブリックな)Issueをオープンするかもしれません。メンテナとしてコード中の脆弱性を開示するために、まずはGitHubでパッケージのリポジトリにドラフトのセキュリティアドバイザリを作成します。アドバイザリを使うと、リポジトリ保守管理者は、プロジェクト内でプライベートにセキュリティの脆弱性を検討して修正することができます。アドバイザリを公開して、セキュリティの脆弱性をプロジェクトのコミュニティに開示することができます。アドバイザリを公開することにより、リポジトリ保守担当者は、コミュニティがいっそう簡単にパッケージの依存関係を更新したり、セキュリティの脆弱性の影響を調べたりできるようにします。アドバイザリについて」を参照してください。アドバイザリの作成」を参照してください。リポジトリの所有者と管理者は、リポジトリでプライベート脆弱性レポートを有効にすることができます。詳しくは、「リポジトリのプライベート脆弱性レポートの構成」を参照してください。メンテナへの通知がすぐに行われます。セキュリティ研究者とリポジトリ保守担当者の詳細については、それぞれ「セキュリティの脆弱性を非公開で報告する」と「非公開で報告されたセキュリティの脆弱性の管理」を参照してください。メンテナの両方が、上記の「標準プロセス」セクションで説明されている指示に従う必要があります。servicesBlog。