GitHubは、攻撃者が以前は安全だったバージョンタグを悪意のあるコミットに移動させるサプライチェーン攻撃を軽減するため、ワークフロー・ロックファイルをリリースしました。この新機能により、開発者は設定ファイル内でバージョンタグ(`v7.0.1`など)の可読性を維持しながら、システムがロック時にそのタグに関連付けられていた正確なコミットSHAを自動的に強制することができます。

可変なタグのリスク

標準的なGitHub Actionsの設定では、開発者はアクションを参照するためにタグを使用することがよくあります。しかし、タグは可変であるため、攻撃者が信頼されたタグを新しい悪意のあるコミットに向けた場合、サプライチェーン攻撃が発生する可能性があります。これを防ぐための以前のベストプラクティスは、アクションをフルSHAに直接ピン留めすることでしたが、これは人間にとって読みづらく、手動での管理も困難でした。

「ロックファイルを使用することで、参照先が移動したとしても、ロックした正確なコミットを実行しながら、ワークフロー内で読みやすいタグやブランチの参照を維持できます。」

— GitHub Actions workflow lockfiles are generally available - GitHub Changelog

ロックファイルの仕組み

新しいロックファイルシステムは、可読性とセキュリティの間のギャップを埋めます。`gh actions-lock`拡張機能を使用することで、開発者はワークフローをスキャンしてマシン読み取り可能な`.github/workflows/actions.lock`ファイルを生成するコマンドを実行できます。このファイルは、YAMLファイルで使用される人間が読みやすいタグを、それらが表す特定のコミットハッシュにマッピングします。

依存関係をピン留めするgh actions-lockコマンドの出力を表示するターミナルウィンドウ。
gh actions-lock CLI拡張機能は、人間が読みやすいタグを特定のコミットハッシュにマッピングするマシン読み取り可能なロックファイルを生成します。github.blog

この画像は、仕組みのセクションで言及されているgh actions-lockツールの実用的なアプリケーションを示しています。

ワークフローが実行されると、GitHub Actionsはロックファイルをチェックします。依存関係がリストされている場合、ランナーは現在のタグが指しているものではなく、記録されたコミットを実行します。これにより、実行されるコードがロックプロセス中に検証されたものと正確に一致することが保証されます。

自動化と検証

これらのロックを長期的に維持するために、GitHubはRenovateおよびDependabotのサポートを統合しました。これらのツールがバージョン更新のためのプルリクエストを開く際、ロックファイル内の対応するエントリを自動的に再生成します。これにより、ロックのセキュリティ保証を損なうことなく、依存関係の自動更新が可能になります。

GitHubはまた、CIパイプライン内でロックファイルを検証することも推奨しています。開発者は専用のジョブを使用して`gh actions-lock --verify`を実行でき、これによりロックファイルがワークフローの設定と同期しており、破損や手動での改ざんが行われていないことを確認できます。

現在の制限とトレードオフ

ロックファイルは重要なセキュリティレイヤーを提供しますが、依存関係が本質的に「安全」であるかどうかを判断するものではありません。ロックされた以降に依存関係が変更されていないことのみを保証します。ユーザーは、ロックファイルにコミットする前に引き続き依存関係を確認することが推奨されます。

現在、複雑なワークフローに関しては技術的な制限があります。ロックファイルは、再利用可能なワークフローや複合アクションを直接ロックすることをサポートしていません。複合アクションは呼び出し箇所を通じて間接的にのみロックされ、個々の呼び出し元は安全な状態に保たれますが、複合アクション自体は他の潜在的な呼び出し元に対してはロックされていない状態のままとなります。

Hacker Newsの読者の反応

  • 技術的な指摘: 関連プロジェクトのメンテナーであるあるコメント投稿者は、現在のロックファイルの実装には、再利用可能なワークフローや複合アクションを直接ロックできないといった制限があることを指摘しました。 コメント ↗
  • 懐疑的: 複数のコメント投稿者は、アクションの内部ロジックが外部の依存関係を読み込んだり、任意のシェルコマンドを実行したりする場合、ロックファイルでは悪意のある動作を防げない可能性があるという懸念を表明しました。 コメント ↗
  • 代替案: あるユーザーは、外部アクションをインポートする代わりに、完全な制御を維持するために必要なスクリプトを直接設定ファイルにコピー&ペーストすることを提案しました。 コメント ↗

Hacker Newsのスレッドで出た意見の要約です。事実として検証されたものではありません。 議論の全文を読む ↗