ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

サブミットされたアプリケーションに対するセキュリティレビューのプロセス

GitHubのセキュリティチームは、GitHub Marketplaceにサブミットされたすべてのアプリケーションをレビューし、それらがセキュリティの要件を満たしていることを確認します。 このレビューのプロセスに備えるために、以下のベストプラクティスに従ってください。

ここには以下の内容があります:

承認のためにアプリケーションをサブミットすると、GitHubのセキュリティチームはそのアプリケーションと全体的なセキュリティプログラムに関するセキュリティアンケートへの回答を求めます。 レビューの一環として、回答をサポートするためのドキュメンテーションを提供することもできます。 GitHub Marketplaceが承認される前に、インシデントレスポンス計画脆弱性管理ワークフローという2つの必須ドキュメントを提出しなければなりません。

セキュリティのベストプラクティス

セキュリティレビューを成功させ、セキュアなユーザ体験を提供するために、以下のベストプラクティスに従ってください。

認可、認証、アクセスコントロール

OAuth Appよりは、GitHub Appをサブミットすることをおすすめします。 GitHub Appsは、データへのアクセスについてより細やかな権限を提供することから、GitHubとのインテグレーションのための公式に推奨される方式ですが. 詳細については、「GitHub AppsとOAuth Appsの違い」を参照してください。

  • アプリケーションは「最小の権限の原則」を用いなければならず、要求するOAuthのスコープやGitHub Appの権限は、意図された機能を実行するのにアプリケーションが必要とするものだけにすべきです。
  • アプリケーションは、サポート担当者にメールや連絡をすることなく、顧客が自分のアカウントを削除する方法を提供しなければなりません。
  • アプリケーションは、異なる実装間でトークンを共有してはなりません。 たとえば、デスクトップのアプリケーションはWebベースのアプリケーションとは別のトークンを持つべきです。 個々のトークンを使うことで、それぞれのアプリケーションはGitHubのリソースに必要なアクセスを個別にリクエストできます。
  • ユーザの種類に応じて求められる機能によって、様々なユーザのロールを持たせてアプリケーションを設計してください。 たとえば、標準的なユーザは管理機能を利用できるべきではなく、支払いマネージャーはリポジトリのコードにプッシュアクセスできるべきではありません。
  • アプリケーションは、SaaSサービスを管理するためのメールやデータベースサービスのようなサービスアカウントを共有するべきではありません。
  • アプリケーションで使用されるすべてのサービスは、固有のログインとパスワードクレデンシャルを持たなければなりません。
  • プロダクションのホスティングインフラストラクチャへの管理権限でのアクセスは、管理業務を持つエンジニアや従業員にのみ与えられるべきです。
  • アプリケーションは、認証に個人アクセストークンを使うことはできず、OAuth AppあるいはGitHub Appとして認証されなければなりません。

データの保護

  • アプリケーションは、パブリックなインターネット上で転送されるデータを、有効なTLS証明書を用いたHTTPSもしくはSSH for Gitで暗号化しなければなりません。
  • アプリケーションは、クライアントIDとクライアントシークレットキーをセキュアに保存しなければなりません。 それらは環境変数に保存することをおすすめします。
  • アプリケーションは、ユーザからの要求を受けてから30日以内、あるいはユーザのGitHubとの法的な関係が終了してから30日以内に、すべてのGitHubユーザデータを削除しなければなりません。
  • アプリケーションは、ユーザにGitHubパスワードの提供を求めてはなりません。
  • アプリケーションは、トークン、クライアントID、クライアントシークレットを暗号化すべきです。

ロギング及びモニタリング

  • アプリケーションは、ロギング及びモニタリングの機能を持たなければなりません。 アプリケーションのログは最低でも30日間保存され、最低でも1年間アーカイブされていなければなりません。 セキュリティログは以下を含まなければなりません。
    • 認証及び認可イベント
    • サービス設定の変更
    • オブジェクトの読み書き
    • すべてのユーザ及びグループの権限変更
    • ロールの管理者への昇格
    • 各イベントに対する一貫したタイムスタンプ
    • 記録されたすべてのアクションのソースユーザ、IPアドレス及びホスト名

インシデントレスポンスのワークフロー

  • GitHubと連携するには、GitHub Marketplaceアプリケーションのリストをサブミットする前に、インシデントレスポンスプランを用意しておかなければなりません。
  • サードパーティのベンダを利用するよりは、自社内にセキュリティ及び運用インシデントレスポンスチームを持つことをおすすめします。
  • インシデントの確認後24時間以内にGitHubに通知する機能を持っていなければなりません。
  • インシデントレスポンスワークフローの要件に関する追加の詳細を含む、GitHub Marketplace開発者契約のセクション3.7.5 - 3.7.5.6に馴染んでおかなければなりません。

脆弱性管理とパッチ適用ワークフロー

  • プロダクションインフラストラクチャーの定期的な脆弱性スキャンを行わなければなりません。
  • 脆弱性スキャンの結果をトリアージし、脆弱性の修正までの期間を定義して同意しなければなりません。
  • 脆弱性管理とパッチ適用ワークフローの要件に関する追加の詳細を含む、GitHub Marketplace開発者契約のセクション3.7.3に馴染んでおかなければなりません。

セキュリティプログラムのドキュメンテーション

Marketplaceのセキュリティレビューの間に、インシデントレスポンスプランと脆弱性管理のワークフローの提出を求められます。 それぞれのドキュメントには、日付スタンプ付きの経営陣が署名した会社ブランドでの声明が含まれていなければなりません。

インシデントレスポンスプラン

インシデントレスポンスプランのドキュメンテーションには、会社が従う現在のプロセス、責任者、連絡先の人物もしくはインシデント発生時に想定される連絡先の人物が含まれていなければなりません。 「NIST Computer Security Incident Handling Guide」は、インシデントレスポンスを全般的に取り上げたドキュメントの素晴らしい例です。 セクション2.3の"Incident Response Policy, Plan, and Procedure Creation"は、特にこのポリシーを取り上げています。 もう1つの素晴らしい例としては「SANS Data Breach Response Policy」があります。

脆弱性管理のワークフロー

脆弱性管理のワークフロードキュメンテーションには、使用されている脆弱性管理及びパッチ適用プロセスについて会社が従う現在のプロセスが含まれていなければなりません。 完全な脆弱性管理のプログラムがないなら、パッチ適用のプロセスの作成から始めると役立つでしょう。 パッチ管理ポリシーの作成のガイダンスとしては、「Establish a patch management policy」を読んでください。

ノート: インシデントレスポンス及び脆弱性管理ワークフローのドキュメントは、大規模な正式のポリシーあるいはプログラムドキュメントだとは想定されていません。 やることを書いた1〜2ページのドキュメントには、長いポリシーテンプレートよりも価値があります。

GitHub Marketplaceセキュリティプログラムアンケート

アプリケーションのサブミットの過程で、弊社のGitHub Marketplaceオンボーディングチームからセキュリティプラクティスに関する情報を求めるアンケートが送られてきます。 このドキュメントは、以下を証明する書面による記録となります。

  • アプリケーションが必要とする認証方式とスコープ。
  • OAuthの制限とGitHub Appの利用を考慮した上で、アプリケーションが意図された機能を実行するのに必要となる以上のスコープやGitHubのアクセスを要求していないこと。
  • SaaS、PaaS、IaaSといったサードパーティのサービスあるいはインフラストラクチャの利用。
  • インシデントレスポンスの手順が存在すること。
  • アプリケーションによるキー/トークンの処理方法。
  • 責任ある開示方針及び手続きがあること、もしくは6ヶ月以内に実施されること。
  • 脆弱性管理のワークフローもしくはプログラム。
  • ロギング及びモニタリングの機能があること。 関連するアプリケーションのログが少なくとも30日間保持され、少なくとも1年間アーカイブされるという証拠も提供しなければなりません。

Did this doc help you?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

OR, learn how to contribute.