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

このガイドについて

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

リスクとは

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

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

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

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

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

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

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

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

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

自動インベントリ生成

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

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

Dependabot は、依存関係を監視して、既知の脆弱性が含まれる場合に通知することで役立ちます。 Dependabot を有効にして、依存関係をセキュリティで保護されたバージョンに更新する pull request を自動的に発生させることもできます。 詳細については、「Dependabot アラートについて」および「Dependabot のセキュリティ アップデート」を参照してください。

pull request の脆弱性の自動検出

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

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

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

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

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

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

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

組織がGitHub Advanced Securityを使用する場合、プライベート リポジトリを含め、組織が所有する任意のリポジトリにシークレット スキャンを有効にできます。 さらに、シークレット スキャンはユーザーが所有するリポジトリ。

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

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

コード以外に、他の場所でシークレットを使用する必要がある可能性があります。 たとえば、GitHub Actions ワークフローまたは Dependabot が他のシステムと通信できるようにする場合です。 シークレットを安全に保管して使う方法について詳しくは、「GitHub Actions でのシークレットの使用」と「Dependabot のプライベート レジストリへのアクセスの構成」をご覧ください。

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

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

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

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

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

次のステップ

• エンドツーエンドのサプライ チェーンのセキュリティ保護

• アカウントをセキュリティで保護するためのベスト プラクティス

• ビルド システムをセキュリティで保護するためのベスト プラクティス