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

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2022-06-03. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてく� さい。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してく� さい。

サプライチェーン中のコードの保護のベストプラクティス

サプライチェーンの中心である、あなたが書くコードと依存するコードの保護の方法に関するガイダンス。

このガイドについて

このガイドは、コードのセキュリティを高めることができる、もっと影響の大きい変更について説明します。 各セクションは、セキュリティを改善するためにプロセスに� えることができる変更の概要を説明します。 影響の大きい変更から最初にリストされています。

リスクとは何か?

開発プロセス中のキーとなるリスクは以下を含みます。

  • 攻撃者が悪用できるセキュリティ脆弱性を持つ依存関係の利用。
  • 攻撃者がリソースへのアクセスに利用できる認証情� �やトークンの漏洩。
  • 攻撃者が悪用できる脆弱性のコードへの導入。

これらのリスクによって、リソースやプロジェクトが攻撃に対してオープンになり、それらのリスクはあなたが作成するパッケージを使う人に直接渡ります。 以下のセクションは、あなた自身とあなたのユーザをこれらのリスクから保護する方法を説明します。

依存関係に対する脆弱性管理プログラ� の作成

依存関係に対する脆弱性管理プログラ� を作成することによって、依存するコードを保護できます。 高いレベルでは、これには以下を保証するプロセスが含まれていなければなりません。

  1. 依存関係のインベントリの作成。

  2. 依存関係にセキュリティ脆弱性がある� �合に把握すること。

  3. 自分のコードに対するその脆弱性のインパクトを評価し、行うべきアクションを判断すること。

自動的なインベントリの生成

最初のステップとして、依存関係の完全なインベントリを作成します。 リポジトリの依存関係グラフは、サポートされているエコシステ� の依存関係が表示されます。 依存関係をチェックインするか、他のエコシステ� を使うと、これをサードパーティのツールからのデータで補足するか、手動で依存関係をリストする必要があります。 詳しい情� �については、「依存関係グラフについて」を参照してく� さい。

依存関係内の脆弱性の自動検出

Dependabotは、依存関係をモニタリングし、既知の脆弱性が含まれている� �合に通知することによって助けてくれます。 詳しい情� �については「Dependabotアラートについて」を参照してく� さい。

脆弱性のある依存関係からのリスクへの暴露の評価

たとえばライブラリやフレー� ワークなど、脆弱性のある依存関係を使っていることが判明した� �合、プロジェクトの露出レベルを評価し、取るべきアクションを決定しなければなりません。 脆弱性は通常、その影響がどの程度重要になるかを示す重要度スコアとともに� �告されます。 この重要度スコアは有益なガイドですが、コードに対する脆弱性の完全な影響を示しはしません。

コードに対する脆弱性の影響を評価するには、そのライブラリをどのように使っているかを考慮し、実際にどの程度のリスクがシステ� にもたらされるかを判断する必要もあります。 その脆弱性はあなたが使用していない機能の一部かもしれず、影響されるライブラリをアップデートして通常のリリースサイクルを継続できるかもしれません。 あるいはあなたのコードはひどくリスクにさらされており、影響されているライブラリをアップデートしてすぐに更新されたビルドを出荷する必要があるかもしれません。 この判断は、そのライブラリをシステ� 中でどのように使っているかに依存するものであり、判断するための知識を持っているのはあなた� けです。

通信トークンの保護

コードはしばしば、ネットワークを介して他のシステ� と通信しなければならず、認証のためのシークレット(パスワードやAPIキーなど)を必要とします。 システ� が実行されるためにはそれらのシークレットにアクセスできなければなりませんが、それらをソースコードには含めないのがベストプラクティスです。 これは特にパブリックリポジトリで重要ですが、多くの人々がアクセスするかもしれないプライベートリポジトリでも重要です。

リポジトリのコミットされたシークレットの自動検出

ノート: Secret scanning is available for organization-owned repositories in GitHub Enterprise Server if your enterprise has a license for GitHub Advanced Security. For more information, see "GitHub's products."

Note: Your site administrator must enable secret scanning for GitHub Enterprise Serverインスタンス before you can use this feature. For more information, see "Configuring secret scanning for your appliance."

多くのサービスプロバイダが発行したシークレットをチェックし、検出されたときには通知してくれるようsecret scanningを設定できます。 リポジトリ、Organization、Entepriseのレベルで、追� のシークレットを検出するためのカスタ� パターンを定義することもできます。 詳しい情� �については「Secret scanningについて」及び「Secret scanningのパターン」を参照してく� さい。

リポジトリからの脆弱性のあるコーディングパターンの排除

ノート: Code scanning is available for organization-owned repositories where GitHub Advanced Security is enabled. 詳しい情� �については、「GitHub Advanced Security について」を参照してく� さい。

Note: Your site administrator must enable code scanning for GitHub Enterprise Serverインスタンス before you can use this feature. For more information, see "Configuring code scanning for your appliance."

Pull Requestレビュープロセスの作成

コードの品質とセキュリティを、すべてのPull Requestがマージ前にレビューされ、テストされていることを保証することによって改善できます。 GitHubには、レビューとマージのプロセスの制御に使える多くの機能があります。 「保護されたブランチ」を見て始めていってく� さい。

脆弱性のあるパターンを探してコードをスキャン

安全でないコードパターンは、支援なしではレビューアが特定するのが難しいことがよくあります。 シークレットを探してコードをスキャンするのに� えて、セキュリティ脆弱性に関連するパターンを探してコードをチェックできます。 たとえばメモリセーフではない関数や、インジェクション脆弱性につながるかもしれないユーザの入力のエスケーピングの失敗などです。 GitHubは、コードをスキャンする方法とタイミングの両方にアプローチする様々な方法を提供します。 「Code scanningについて」を見て始めていってく� さい。

次のステップ