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

このガイドについて

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

リスクとは

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

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

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

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

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

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

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

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

自動インベントリ生成

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

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

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

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

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

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

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

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

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

プロバイダーが多い

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

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

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

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

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

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

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

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

次の手� �

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

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

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