Skip to main content
ドキュメントへの更新が頻繁に発行されており、このページの翻訳はまだ行われている場合があります。 最新の情報については、「英語のドキュメント」を参照してください。

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

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

このガイドについて

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

リスクとは

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

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

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

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

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

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

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

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

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

自動インベントリ生成

最初の手順として、依存関係の完全なインベントリを作成することをお勧めします。 リポジトリの依存関係グラフに、サポートされているエコシステムの依存関係が表示されます。 依存関係をチェックインする場合、または他のエコシステムを使用する場合は、これを補完するために、サードパーティ製ツールのデータを使用したり、依存関係を手動で指定したりする必要があります。 詳細については、「依存関係グラフの概要」を参照してください。

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

Dependabot は、依存関係を監視して、既知の脆弱性が含まれる場合に通知することで役立ちます。 さらに、依存関係をセキュアなバージョンに更新するための pull request を Dependabot が自動的に生成できるようにすることもできます。詳しくは、「Dependabot alerts について」および「Dependabot のセキュリティ更新プログラムについて」を参照してください。

pull request の脆弱性の自動検出

dependency review action によって pull request に依存関係レビューが適用され、ユーザーは pull request によってリポジトリに脆弱なバージョンの依存関係が導入されるかどうかを簡単に確認できます。 脆弱性が検出された場合、dependency review action は pull request のマージをブロックできます。 詳しい情報については、「依存関係レビューの適用」を参照してください。

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

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

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

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

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

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

注: ご自分のエンタープライズで GitHub Advanced Security のライセンスがある場合、GitHub Enterprise Server の Organization 所有のリポジトリで Secret scanning が利用できます。 詳細については、「GitHub Enterprise Server の secret scanning について」と「GitHub Advanced Security について」を参照してください。

注: この機能を使うには、サイト管理者が your GitHub Enterprise Server instance の secret scanning を有効にする必要があります。 詳しくは、「アプライアンスでの secret scanning の構成」をご覧ください。

プロバイダーが多い

secret scanningを構成して、多くのサービス プロバイダーによって発行されたシークレットを確認し、それらが検出されたときに通知できます。 また、カスタム パターンを定義して、リポジトリ、組織、またはエンタープライズ レベルで追加のシークレットを検出することもできます。 詳細については、「シークレット スキャンについて」と「シークレット スキャン パターン」を参照してください。

GitHub Enterprise Server で使用するシークレットのストレージをセキュリティで保護する

コード以外に、他の場所でシークレットを使用する必要がある可能性があります。 たとえば、GitHub Actions ワークフローまたは Dependabot が他のシステムと通信できるようにする場合です。 シークレットを安全に格納して使用する方法について詳しくは、「アクションでの暗号化されたシークレット」および「Dependabot の暗号化されたシークレットの管理」を参照してください。

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

注: Code scanning は、GitHub Enterprise Server の Organization 所有のリポジトリで利用できます。 この機能には、GitHub Advanced Security のライセンスが必要です。 詳細については、「GitHub Advanced Security について」を参照してください。

注: この機能を使うには、サイト管理者が your GitHub Enterprise Server instance の code scanning を有効にする必要があります。 詳細については、「アプライアンスでの code scanning の構成」を参照してください。

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

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

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

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

次の手順