Skip to main content

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

サプライ チェーンの終端を保護する方法 (成果物の構築と配布に使用するシステム) に関するガイダンス。

このガイドについて

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

リスクとは

ソフトウェア サプライ チェーンに対する攻撃の一部は、ビルド システムを直接対象とします。 攻撃者がビルド プロセスを変更できる場合は、個人アカウントやコードを侵害することなく、システムを悪用するおそれがあります。 ビルド システムだけでなく、個人のアカウントやコードも忘れずに保護することが重要です。

ビルド システムのセキュリティによる保護

ビルド システムに必要なセキュリティ機能がいくつかあります。

  1. ビルドの手順は明確で繰り返すことができる必要があります。

  2. ビルド プロセス中に何が実行されていたかを正確に把握する必要があります。

  3. 各ビルドは新しい環境で開始する必要があるため、侵害されたビルドは今後のビルドに影響を与えることはありません。

GitHub Actions は、これらの機能を満たすのに役立ちます。 ビルド手順は、コードと共にリポジトリに格納されます。 ご自分でホストする Windows、Mac、Linux、ランナーなど、ビルドを実行する環境を選びます。 各ビルドは新しいランナー イメージから始まり、ビルド環境に攻撃が持続することは困難になります。

GitHub Actions を使用すると、セキュリティ上の利点に加えて、頻繁かつ高速なビルドのために、ビルドを手動で、定期的に、またはリポジトリの Git イベントでトリガーできます。

GitHub Actions は大きなトピックですが、作業を開始するには、「GitHub Actions について」のほかに、「GitHub ホストランナーの選択」、「ワークフローのトリガー」を参照してください。

ビルドに署名する

ビルド プロセスがセキュリティで保護されたら、誰かがビルド プロセスの最終的な結果を改ざんできないようにする必要があります。 これを行う優れた方法は、ビルドに署名することです。 ソフトウェアをパブリックに配布する場合、多くの場合、公開/秘密の暗号化キー ペアで行われます。 秘密キーを使用してビルドに署名し、公開キーを公開して、ソフトウェアのユーザーがビルドの署名を使用する前に確認できるようにします。 ビルドのバイトが変更された場合、署名は検証されません。

ビルドに正確に署名する方法は、記述しているコードの種類とユーザーによって異なります。 多くの場合、秘密キーを安全に格納する方法を知ることは困難です。 ここでの基本的なオプションの 1 つは、GitHub Actions 暗号化されたシークレットを使用することですが、それらの GitHub Actions ワークフローにアクセスするユーザーを制限するように注意する必要があります。 秘密キーがパブリック インターネット (Microsoft Azure、HashiCorp Vault など) 経由でアクセスできる別のシステムに格納されている場合、より高度なオプションは OpenID Connect で認証することであるため、システム間でシークレットを共有する必要はありません。 秘密キーにアクセスできるのがプライベート ネットワークからのみの場合は、GitHub Actions にセルフホステッド ランナーを使用することもできます。

詳しくは、「暗号化されたシークレット」、「OpenID Connect によるセキュリティ強化について」、 および「セルフホステッド ランナーについて」を参照してください。

GitHub Actions のセキュリティを強化する

さらに GitHub Actions をセキュリティで保護するために、さらに多くの手順を実行できます。 特に、サードパーティのワークフローを評価する場合は注意が必要です。また、ワークフローに変更を加えることができるユーザーを制限するために CODEOWNERS を使用することを検討してください。

詳しくは、「GitHub Actions のセキュリティ強化」、特に「サードパーティ アクションを使用する」および「変更の監視に CODEOWNERS を使用する」を参照してください。

次の手順