このガイドについて
このガイドでは、ビルド システムのセキュリティを向上させるために加えられる最も影響が大きい変更について説明します。 各セクションで、セキュリティを向上させるためにプロセスに対して行うことができる変更の概要を示します。 変更は影響が大きい順に示されます。
リスクとは
ソフトウェア サプライ チェーンに対する攻撃の一部は、ビルド システムを直接対象とします。 攻撃者がビルド プロセスを変更できる場合は、個人アカウントやコードを侵害することなく、システムを悪用するおそれがあります。 ビルド システムだけでなく、個人のアカウントやコードも忘れずに保護することが重要です。
ビルド システムのセキュリティによる保護
ビルド システムに必要なセキュリティ機能がいくつかあります。
-
ビルドの手順は明確で繰り返すことができる必要があります。
-
ビルド プロセス中に何が実行されていたかを正確に把握する必要があります。
-
各ビルドは新しい環境で開始する必要があるため、侵害されたビルドは今後のビルドに影響を与えることはありません。
GitHub Actions は、これらの機能を満たすのに役立ちます。 ビルド手順は、コードと共にリポジトリに格納されます。 ご自分でホストする Windows、Mac、Linux、ランナーなど、ビルドを実行する環境を選びます。 各ビルドは新しいランナー イメージから始まり、ビルド環境に攻撃が持続することは困難になります。
GitHub Actions を使用すると、セキュリティ上の利点に加えて、頻繁かつ高速なビルドのために、ビルドを手動で、定期的に、またはリポジトリの Git イベントでトリガーできます。
GitHub Actions は大きなトピックですが、作業を始めるには、「GitHub Actions を理解する」のほかに、「GitHub Actions のワークフロー構文」と「ワークフローのトリガー」をご覧ください。
ビルドのアーティファクト構成証明を生成する
構成証明を使用することで、ビルドするソフトウェアに対して検証不可能な証明と整合性の保証を作成できます。 さらに、ソフトウェアを使用するユーザーは、ソフトウェアがビルドされた場所と方法の確認ができます。
ソフトウェアで成果物の構成証明を生成する場合は、ビルドの実績を確立し、次の情報など暗号署名付き要求を作成します。
- アーティファクトに関連付けられているワークフローへのリンク。
- リポジトリ、組織、環境、コミット SHA、およびアーティファクトのトリガー イベント。
- 証明の確立に使用する OIDC トークンからのその他の情報。 詳しくは、「OpenID Connect を使ったセキュリティ強化について」を参照してください。
関連するソフトウェア部品表 (SBOM) を含む構成証明を生成することもできます。 ビルドを、その中で使用されるオープンソースの依存関係の一覧に関連付けることで、透明性は提供され、コンシューマーがデータ保護標準に準拠できるようになります。
構成証明には、ビルドされた成果物に対する署名と、ソース コードとビルド手順へのリンクが含まれます。 アーティファクト構成証明を使用してビルドに署名する場合、独自の署名キー マテリアルを管理する必要はありません。 GitHub は、Microsoft が操作する署名機関で処理します。
詳しくは、「アーティファクトの構成証明を使用して構築の実績を確立する」を参照してください。
ビルドに署名する
ビルド プロセスがセキュリティで保護されたら、誰かがビルド プロセスの最終的な結果を改ざんできないようにする必要があります。 これを行う優れた方法は、ビルドに署名することです。 ソフトウェアをパブリックに配布する場合、多くの場合、公開/秘密の暗号化キー ペアで行われます。 秘密キーを使用してビルドに署名し、公開キーを公開して、ソフトウェアのユーザーがビルドの署名を使用する前に確認できるようにします。 ビルドのバイトが変更された場合、署名は検証されません。
ビルドに正確に署名する方法は、記述しているコードの種類とユーザーによって異なります。 多くの場合、秘密キーを安全に格納する方法を知ることは困難です。 ここでの基本的なオプションの 1 つは、GitHub Actions 暗号化されたシークレットを使用することですが、それらの GitHub Actions ワークフローにアクセスするユーザーを制限するように注意する必要があります。 秘密キーがパブリック インターネット (Microsoft Azure、HashiCorp Vault など) 経由でアクセスできる別のシステムに格納されている場合、より高度なオプションは OpenID Connect で認証することであるため、システム間でシークレットを共有する必要はありません。 秘密キーにアクセスできるのがプライベート ネットワークからのみの場合は、GitHub Actions にセルフホステッド ランナーを使用することもできます。
詳しくは、「GitHub Actions でのシークレットの使用」、「OpenID Connect を使ったセキュリティ強化について」、および「自己ホスト ランナーの概要」をご覧ください。
GitHub Actions のセキュリティを強化する
さらに GitHub Actions をセキュリティで保護するために、さらに多くの手順を実行できます。 特に、サードパーティのワークフローを評価する場合は注意が必要です。また、ワークフローに変更を加えることができるユーザーを制限するために CODEOWNERS を使用することを検討してください。
詳細については、「GitHub Actions のセキュリティ強化」および「GitHub のセキュリティ機能を使用して GitHub Actions の使用をセキュリティで保護する」を参照してください。