Estontinc公開日 5 分で読めます
CI/CDパイプラインを守る方法：GitHub Actionsのロックファイルから始める
サプライチェーン攻撃は、ソフトウェアをビルドし出荷するツールを狙うことがよくあります。タグの移動がパイプラインに与える影響、GitHubの新しいロックファイル、CI/CDを守るチェックリストをまとめました。
CI/CDパイプラインはどう守ればよいのでしょうか。 多くのチームはレビューやテストでアプリのコードを守っていますが、そのコードをビルドし出荷するパイプラインでは、誰も再確認しないサードパーティのアクションが動いていることがよくあります。2026年10月14日、GitHubはGitHub Actions向けのワークフロー依存関係ロックファイルをパブリックプレビューとして公開しました。ワークフローの実行を、確認済みのコミットに固定する仕組みです。
この記事では、ロックファイルが防ぐリスク、その仕組み、そしてどのCI/CDパイプラインにも使える実践的なチェックリストを解説します。
リスク：移動したタグが別のコードを実行する
ワークフローは通常、v4のようなタグやブランチでアクションを参照します。GitHubは問題をはっきり説明しています。ワークフローを確認した後でもタグやブランチは移動できるため、後の実行で別のコードが動く可能性があります。アクションが侵害されると、移動したタグやブランチによって、リポジトリを一切変更しないまま悪意のあるコードがワークフローに入り込むことがあります。
パイプラインはデプロイ用の認証情報や本番環境へのアクセスを持つことが多いため、これは重要です。そこで動くコードは、リポジトリよりはるかに広い範囲に届きます。
GitHub Actionsのロックファイルでできること
- 依存関係の固定： GitHub CLIの拡張機能gh actions-lockが、アクション、その推移的な依存関係、再利用可能なワークフローのレビュー可能なコミットを記録した.github/workflows/actions.lockを生成します。
- 段階的な導入： ワークフローは1つずつ導入できます。導入後は依存関係のロックファイルエントリが必須になり、タグやブランチが移動しても記録されたコミットが実行されます。
- 古いロックファイルの検出： ファイルを変更せずにロックファイルが最新か確認でき、CIのチェックにも組み込めます。
- 必須化： Require lockfileポリシーで、エンタープライズ、組織、リポジトリの管理者がロックファイルの使用を必須にできます。
- Dependabotで最新に： 導入済みのワークフローでDependabotがアクションを更新すると、同じプルリクエストで対応するロックファイルエントリも再生成されます。
このプレビューはGitHub Enterprise CloudとGitHub Enterprise Cloud with data residencyで利用できます。GitHubは重要な注意点も挙げています。ロックしても依存関係が安全かどうかは判断されないため、ロックする前に依存関係を確認してください。
CI/CDセキュリティのチェックリスト
ロックファイルは対策のひとつに過ぎません。私たちのプロジェクト経験から、パイプラインを安全に保つ習慣は次のとおりです。
- アクションを確認済みのコミットに固定する。 可能ならロックファイルを使い、タグが移動しても実行内容が変わらないようにします。
- ロックする前に依存関係を確認する。 固定された悪意のあるアクションは、依然として悪意のあるアクションです。
- 更新はプルリクエストで行う。 すべての依存関係の変更を見える形でレビューします。小さな変更がレビューしやすい理由は小さなプルリクエストの記事で解説しています。
- ワークフローの権限を最小限にする。 各ジョブに必要な権限とシークレットだけを与えます。
- シークレットをログやコードに残さない。 APIキーの守り方とログから機密データを守る方法もご覧ください。
- すべてのプルリクエストでパイプラインを確認する。 古いロックファイルのチェックも含めます。
最近のランナーの変更に合わせてワークフローの更新も必要なら、GitHub ActionsのNode 24とUbuntu 26.04への移行の記事で確認すべき点を紹介しています。
ビジネスへの影響
サプライチェーン攻撃がアプリそのものを直接狙うことはまれです。狙われるのは、アプリをビルドし出荷するツールです。確認済みのコードに固定され、権限が絞られ、ログが整ったパイプラインは、プロダクトと顧客データへの最も目立たない侵入経路のひとつを閉じます。
Estontincのサポート
Estontincはマラン（インドネシア）のソフトウェア開発会社で、6年以上にわたり100件以上のプロジェクトと50社以上のクライアントを支援してきました。クラウド・DevOpsチームが、アクションのバージョンや権限からシークレット、依存関係の更新までCI/CDパイプラインを監査し、安全なリリースの仕組みを整えます。カスタムソフトウェアサービスでは、そのパイプラインで出荷するアプリの開発と保守を行います。
お問い合わせページから、CI/CDの構成をお聞かせください。24時間以内にご返信します。
よくある質問
CI/CDパイプラインはどう守ればよいですか？
サードパーティのアクションを確認済みのコミットに固定し、信頼する前に依存関係を確認し、更新はプルリクエストで行い、各ジョブには必要な権限とシークレットだけを与え、シークレットをログに残さず、すべてのプルリクエストでパイプラインを確認します。GitHub Actionsでは、最初の手順にロックファイルが役立ちます。
GitHub Actionsのワークフローロックファイルとは何ですか？
.github/workflows/actions.lockに、ワークフローが使うアクション、推移的な依存関係、再利用可能なワークフローの正確なコミットを記録するファイルです。導入後は、タグやブランチが移動しても記録されたコミットが実行されます。2026年10月14日からパブリックプレビューです。
タグでアクションを参照するのはなぜ危険ですか？
ワークフローを確認した後でも、タグやブランチは移動できます。アクションが侵害されるとタグが悪意のあるコードに向けられ、次の実行ではリポジトリに変更がないままそのコードが動きます。確認済みのコミットに固定すれば、実行されるコードは確認したものと同じになります。
ロックファイルを使えばアクションは安全になりますか？
いいえ。GitHubによると、ロックしても依存関係が安全かどうかは判断されません。ロックファイルが保証するのは、毎回同じ確認済みのコミットが実行されることだけです。ロックする前に各アクションを確認し、Dependabotがプルリクエストで提案する更新も引き続き確認してください。
出典
この記事の事実と数値は、以下の公式情報に基づいています。
- Cloud & DevOps
- Security
- GitHub
- CI/CD
