Skip to main content

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

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

このガイドについて

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

リスクとは何か?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通信トークンの保護

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

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

ノート: Secret scanning is available for organization-owned repositories in GitHub AE. This is a GitHub Advanced Security feature (free during the beta release).

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

GitHub AEで使用するシークレットの安全なストレージ

コードに加えて、他の場所にあるシークレットを使う必要もあるでしょう。 たとえばGitHub Actionsワークフローが他のシステムと通信できるようにするためです。 シークレットの安全な保存と利用方法に関する詳しい情報については「Actionsの暗号化されたシークレット」を参照してください。

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

ノート: Code scanning is available for organization-owned repositories in GitHub AE. This is a GitHub Advanced Security feature (free during the beta release). For more information, see "GitHub's products."

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

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

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

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

次のステップ