サプライ チェーンのコードをセキュリティで保護するためのベスト プラクティス

サプライ チェーンの中心、つまり記述するコードと依存するコードを保護する方法に関するガイダンスです。

この記事で

このガイドについて

このガイドでは、コードのセキュリティを向上させるために行うことができる最も影響が大きい変更について説明します。 各セクションで、セキュリティを向上させるためにプロセスに対して行うことができる変更の概要を示します。 変更は影響が大きい順に示されます。

リスクとは

開発プロセスの主なリスクは次のとおりです。

  • 攻撃者が悪用する可能性がある、セキュリティの脆弱性を含む依存関係の使用。
  • 攻撃者がリソースへのアクセスに使用できる、認証資格情報またはトークンの漏洩。
  • 攻撃者が悪用する可能性がある、脆弱性の自身のコードへの取り込み。

これらのリスクによって、リソースとプロジェクトが攻撃を受け入れるようになります。また、それらのリスクが、作成したパッケージを使用するすべてのユーザーに直接引き継がれます。 次のセクションでは、これらのリスクに対して自身とユーザーを保護する方法について説明します。

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

依存関係の脆弱性管理プログラムを作成ことで、依存するコードをセキュリティで保護できます。 概要としては次を保証するプロセスが含める必要があります。

  1. 依存関係のインベントリを作成します。

  2. セキュリティ脆弱性が依存関係に含まれたときに把握します。

  3. pull request に依存関係のレビューを適用します。

  4. その脆弱性がコードに及ぼす影響を評価し、実行するアクションを決定します。

自動インベントリ生成

最初の手順として、依存関係の完全なインベントリを作成することをお勧めします。 リポジトリの依存関係グラフに、サポートされているエコシステムの依存関係が表示されます。 依存関係をチェックインする場合、または他のエコシステムを使用する場合は、これを補完するために、サードパーティ製ツールのデータを使用したり、依存関係を手動で指定したりする必要があります。 少なくともリポジトリへの読み取りアクセス権がある場合は、GitHub UI または GitHub REST API を使って、リポジトリの依存関係グラフを SPDX 互換のソフトウェア部品表 (SBOM) としてエクスポートできます。 詳しくは、「リポジトリのソフトウェア部品表のエクスポート」をご覧ください。

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

          Dependabot は、依存関係を監視し、既知の脆弱性が含まれている場合に通知することで役立ちます。 依存関係をセキュリティで保護されたバージョンに更新するプル要求を自動的に発生させる Dependabot を有効にすることもできます。 詳細については、「[AUTOTITLE](/code-security/dependabot/dependabot-alerts/about-dependabot-alerts)」および「[AUTOTITLE](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates)」を参照してください。

pull request の脆弱性の自動検出

          依存関係レビュー アクションでは、プル要求に依存関係のレビューが適用されるため、プル要求によってリポジトリに依存関係の脆弱なバージョンが導入されるかどうかを簡単に確認できます。 脆弱性が検出されると、 依存関係レビュー アクション によってプル要求のマージがブロックされる可能性があります。 詳しくは、「[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#the-dependency-review-action)」をご覧ください。

脆弱な依存関係によるリスク露出の評価

脆弱な依存関係 (ライブラリやフレームワークなど) を使用していることが判明した場合は、プロジェクトの露出レベルを評価し、実行するアクションを決定する必要があります。 通常、脆弱性は、影響がどれほど深刻であるかを示す重大度スコアを使用して報告されます。 重大度スコアは指針として役立ちますが、コードに対する脆弱性の影響を完全に示すことはできません。

コードに対する脆弱性の影響を評価するには、ライブラリの使用方法を検討し、実際にシステムにもたらされるリスクの程度を判断する必要もあります。 仮に、この脆弱性が使用しない機能に含まれているのであれば、影響を受けるライブラリを更新し、通常のリリース サイクルを続行することができます。 または、仮に、コードが重大な危険にさらされているのであれば、影響を受けるライブラリを更新し、更新されたビルドをすぐに出荷する必要があります。 この決定はシステムでライブラリを使用している方法によって異なり、それを行うために必要な知識があるのは自分だけです。

通信トークンをセキュリティで保護する

多くの場合、コードはネットワーク経由で他のシステムと通信する必要があり、認証のためにシークレット (パスワードや API キーなど) が必要です。 システムが作動するためにはこれらのシークレットにアクセスする必要がありますが、ソース コードにはシークレットを含めないことをお勧めします。 これは、多くのユーザーがアクセス権を持つリポジトリではなく、パブリック リポジトリにとって重要である場合に特に重要です。

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

メモ

Secret scanning は、次のリポジトリの種類で使用できます。

パブリック リポジトリ: Secret scanning は無料で自動的に実行されます。 * 組織所有のプライベートリポジトリと内部リポジトリ: GitHub Team または GitHub Enterprise Cloud で有効になっている GitHub Secret Protection で使用できます。 * ユーザー所有のリポジトリ: GitHub Enterprise Cloud および Enterprise Managed Users で利用可能です。 GitHub Enterprise Server で使用できるのは、エンタープライズで GitHub Secret Protection が有効になっている場合です。

          GitHub パートナーは、シークレットが自分のパブリック リポジトリと依存しているパブリック npm パッケージにコミットまたは保存されるタイミングを自動的に検出し、アカウントのセキュリティを確保するために適切なアクションを実行できるようにプロバイダーに通知します。 詳しくは、「[AUTOTITLE](/code-security/secret-scanning/managing-alerts-from-secret-scanning/about-alerts##about-partner-alerts)」をご覧ください。

組織で GitHub Secret Protection or GitHub Advanced Securityを使用している場合は、プライベート リポジトリを含め、組織が所有するすべてのリポジトリで ユーザーのシークレット スキャン アラート を有効にすることができます。 さらに、ユーザーのシークレット スキャン アラート は、GitHub Enterprise Cloud と Enterprise Managed Users のためのユーザー所有のリポジトリでは パブリック プレビュー で利用できます。

また、カスタム パターンを定義して、リポジトリ、組織、またはエンタープライズ レベルで追加のシークレットを検出することもできます。 詳しくは、「シークレット スキャン アラートについて」をご覧ください。

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

コードに加えて、他の場所でシークレットを使用する必要がある可能性があります。 たとえば、 GitHub Actions ワークフロー、 Dependabot、または GitHub Codespaces 開発環境が他のシステムと通信できるようにします。 シークレットを安全に格納して使用する方法については、「AUTOTITLE」、「AUTOTITLE」、「AUTOTITLE」を参照してください。

脆弱なコーディング パターンをリポジトリから除外する

メモ

Code scanning は、次のリポジトリの種類で使用できます。

  • GitHub.com 上のパブリックリポジトリ
  • GitHub Team、GitHub Enterprise Cloud、または GitHub Enterprise Server 上の組織所有リポジトリ。 GitHub Code Security が 有効になっています。

pull request レビュー プロセスを作成する

マージの前にすべての pull request がレビューおよびテストされるようにして、コードの品質とセキュリティを向上させることができます。 GitHub には、レビューとマージのプロセスを制御するために使用できる多くの機能があります。 概要については、「保護されたブランチについて」を参照してください。

コードの脆弱なパターンをスキャンする

多くの場合、セキュアでないコード パターンをレビュー担当者が見つけるのは困難です。 コードでのシークレットのスキャンに加え、セキュリティの脆弱性に関連するパターンがないかを確認できます。 たとえば、メモリセーフではない関数や、インジェクションの脆弱性につながる可能性があるユーザー入力のエスケープもれです。 GitHub には、コードをスキャンする方法とタイミングの両方にアプローチするためのさまざまな方法が用意されています。 概要については、「コード スキャンについて」を参照してください。

次のステップ

  •         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview)

  •         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts)

  •         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)