信頼できないトリガーに対する GitHub Actions キャッシュの読み取り専用化
GitHub は、信頼できないトリガーからのキャッシュ汚染攻撃を防ぐため、デフォルトブランチのワークフローイベントに対して読み取り専用キャッシュトークンを発行するセキュリティ強化を実施した。
キーポイント
セキュリティリスクの解消
外部アクターが影響可能なトリガー（例：pull_request_target）からデフォルトブランチへ書き込まれるキャッシュ汚染攻撃を防ぐため、読み取り専用トークンへの切り替えが行われた。
適用条件の明確化
「信頼できないトリガー」かつ「共有されたデフォルトブランチ SHA の文脈」の両方が満たされる場合にのみ、書き込み権限が剥奪され読み取り専用となる。
影響を受けるワークフロー
push や schedule などの信頼できるトリガーや、非デフォルトブランチスコープを使用する場合は引き続き読み書きが可能だが、特定の条件下ではキャッシュ保存が警告付きでスキップされる。
開発者への対応策
キャッシュ機能のメリットを維持するには、信頼できるイベント（例：push）でキャッシュを保存し、他のワークフローから読み取るという分離した構成が必要となる。
影響分析・編集コメントを表示
影響分析
この変更は、CI/CD パイプラインにおけるサプライチェーン攻撃や権限昇格攻撃に対する防御力を劇的に向上させるものであり、開発者にとって重要なセキュリティ基盤の強化です。一方で、セキュリティ対策を優先するあまりキャッシュ機能が一時的に低下するケースが生じるため、ワークフロー設計の見直しが必要となり、運用コストが若干増大する可能性があります。
編集コメント
セキュリティと利便性のトレードオフをどう取るかが問われる重要なアップデートであり、CI/CD パイプラインの設計を見直す絶好の機会です。
GitHub Actions は、リポジトリへの書き込み権限なしにトリガーできるワークフローイベントに対して、デフォルトブランチのキャッシュに対して読み取り専用トークンを発行するようになりました。これにより、キャッシュに対する最小特権の原則が適用され、キャッシュ汚染を介した一般的な権限昇経路が防止されます。
以前は、Actions サービスは pull_request_target、issue_comment、fork-pull-request の workflow_run カスケードなどのトリガーを含むすべてのワークフローイベントに対して読み書き可能なキャッシュトークンを発行していました。外部アクターが影響を与える可能性のある（例えば、スクリプト注入や「pwn リクエスト」を通じて）ワークフローコードがデフォルトブランチのキャッシュに書き込みを行うと、push や schedule といった信頼されたワークフローが後でその汚染されたエントリを復元してしまいます。これにより、これらのより信頼されたワークフロー内で任意のコードを実行したり、本番環境のシークレットを外部へ流出させたりする経路が開かれていました。
この経路を塞ぐため、GitHub は以下の 2 つがともに真である場合に読み取り専用のキャッシュトークンを発行します：
トリガーイベントが信頼できないこと。つまり、リポジトリのコラボレーター以外の誰かがそのイベントをトリガーできる状態であること。
ワークフローの実行コンテキストとキャッシュのスコープが、共有されたデフォルトブランチの SHA に由来すること。
デフォルトブランチのキャッシュに書き込みを行う最も一般的なワークフロートリガーは、完全な読み書きキャッシング権限を維持します。これらのトリガーには、push、schedule、workflow_dispatch、repository_dispatch、delete、registry_package、page_build が含まれます。また、pull_request や release のように非デフォルトブランチのスコープを使用するすべてのトリガーも、読み書きキャッシング権限を保持します。
影響を受ける人々
この変更は、デフォルトブランチの SHA コンテキストからキャッシュへ書き込む限られた数の信頼できないワークフローにおけるキャッシング機能に後退をもたらします。書き込みが制限された場合、actions/cache は実行中に警告をログ出力し、ジョブは保存せずに続行されます。復元操作には影響はありません。
これらのワークフローでキャッシングの恩恵を維持するには、push などのイベントによってトリガーされ、キャッシュへの読み書きアクセス権を持つ別個のワークフローを用意する必要があります。これにより、キャッシュへの読み取り専用アクセス権を持つ後続のワークフローがキャッシュを復元して利用できるようになります。
この変更は、github.com およびデータ居住性を備えた GitHub の両方に適用されます。詳細については GitHub Actions キャッシュドキュメントをご参照ください。また、GitHub コミュニティでの議論にもご参加ください。
「信頼できないトリガーに対する読み取り専用 Actions キャッシュ」という記事は、最初に The GitHub Blog で公開されました。
原文を表示
GitHub Actions now issues read-only cache tokens to the default branch for workflow events that can be triggered without write permissions to the repository. This applies least privilege to the cache and prevents common privilege-escalation paths through cache poisoning.
Previously, the Actions service issued read-write cache tokens for every workflow event, including triggers like pull_request_target, issue_comment, and fork-pull-request workflow_run cascades. Workflow code that an external actor can influence (e.g., through script injection or “pwn requests”) could write to the default-branch cache, and a trusted workflow such as push or schedule would later restore those poisoned entries. This opened up a path to run arbitrary code and exfiltrate production secrets in these more trusted workflows.
To close that path, GitHub now issues a read-only cache token when both of these are true:
The triggering event is untrusted, meaning someone other than a repository collaborator can trigger the event.
The workflow execution context and cache scope come from the shared default-branch SHA.
The most common workflow triggers that write to the default-branch cache keep full read-write caching. These triggers are push, schedule, workflow_dispatch, repository_dispatch, delete, registry_package, and page_build. Additionally, any trigger that uses a non-default-branch scope, such as pull_request and release, keeps read-write caching permission.
Who’s affected
This change regresses caching for a small set of untrusted workflows that write to the cache from a default-branch-SHA context. When a write is restricted, actions/cache logs a warning in the run and the job continues without saving. Restores are unaffected.
To keep the benefit of caching in these workflows, you will need to have a separate workflow triggered by an event with read-write cache access such as push which does cache saves. This will enable following workflows with read-only cache access to restore and use the cache.
This change ships to both github.com and GitHub with Data Residency. Check the GitHub Actions cache documentation to learn more, and join the discussion in GitHub Community.
The post Read-only Actions cache for untrusted triggers appeared first on The GitHub Blog.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み