GitHub Actions ワークフローのトリガーを制御する機能を公開プレビューへ
GitHub はエンタープライズ向けにワークフロー実行保護機能を公開プレビューとして導入し、誰がトリガーできるか、どのイベントを許可するかを管理するルールを設定可能にした。
キーポイント
ワークフロー実行保護の公開
GitHub Enterprise および組織・リポジトリレベルで、誰が GitHub Actions ワークフローを実行できるか、どのイベントを許可するかを管理する「ワークフロー実行保護」機能が公開プレビューとして利用可能になった。
ルールベースの包括的管理
既存の Rulesets フレームワークを活用し、組織全体または特定のリポジトリに適用できるポリシーを一元管理可能になり、YAML ファイルごとの個別設定から脱却する。
攻撃パターンの防止
プルリクエストからの汚染されたパイプライン実行や、権限のないユーザーによる手動トリガー濫用など、実在する攻撃手法をブロックするための具体的なルール（イベント制限、アクタ制限）を提供する。
評価モードとロールアウト
ポリシー適用前に「評価モード」でシミュレーション実行が可能であり、既存ワークフローを壊すリスクを抑えながら段階的な導入を実現できる。
影響分析・編集コメントを表示
影響分析
この機能は、DevSecOps において最も脆弱なポイントの一つである CI/CD パイプラインの信頼性を劇的に高めるものであり、特に大規模組織やオープンソースプロジェクトにおけるサプライチェーン攻撃への防御策として不可欠となる。YAML ファイルごとの設定管理から脱却し、中央集権的なポリシー制御を可能にすることで、セキュリティ運用の負荷軽減とリスク低減の両面で業界標準のベストプラクティスを更新する。
編集コメント
CI/CD パイプラインの信頼性を確保する上で、コードの実行権限を分離管理できるこの機能は、セキュリティ運用において即座に導入すべき重要なアップデートです。
GitHub Enterprise、組織、およびリポジトリ向けに、ワークフロー実行保護機能がパブリックプレビューとして利用可能になりました。この新機能により、企業管理者は許可リストを定義して、誰が GitHub Actions ワークフローを実行できるか、またどのイベントがその実行を許可されるかを制御できます。これにより、予測可能で安全なワークフロー実行が可能になります。
従来、ワークフローはそれをトリガーしたコミットに含まれるワークフローファイルに基づいて実行されていました。リポジトリへのアクセス権を持つ攻撃者は、そのファイルを改変して悪意のあるコードを実行させることが可能でした。ワークフロー実行保護機能はこの隙間を埋めます。管理者がルールを定義し、GitHub Actions が実行前にそれを評価するため、不正なアクターやイベントが望ましくないワークフローの実行を引き起こすことは決してありません。
一つのポリシーで全リポジトリに対応
ワークフロー実行保護機能は GitHub のルールセットフレームワークに基づいて構築されているため、ルールセットから既に知っているターゲット指定機能がここでも利用可能です。組織全体のルールセットを使用して企業全体に保護を適用し、リポジトリ固有のカスタムプロパティを使って特定のレポジトリにスコープを限定できます。つまり、セキュリティについて YAML ファイルごとに個別に検討する必要がなくなり、広範な保護を一つの場所で可視化して強制できるようになります。また、評価モードを使用してルールをシャドウ実行することもでき、ポリシーを適用・展開する前に、ルールが具体的に何をブロックするかを確認できます。これにより、既存のワークフローを破損させるリスクを防ぐことができます。
まずは二つのルールタイプ
イベントとアクターが最初の二つのルールタイプであり、将来的にはさらに追加される予定です。
アクタールールは、ワークフローを実行できる主体を制御します。これには個別のユーザー、リポジトリロール（例：Read、Maintain、Admin）、GitHub Apps、Copilot、Dependabot が含まれます。
イベントルールは、許可されるイベントを制御します。具体的には push、pull_request、pull_request_target、workflow_dispatch などです。
デフォルトでは、リポジトリに書き込み権限を持つすべてのユーザーがワークフローを実行できます。アクタールールを使用すると、コードの貢献者と CI を実行する者を分離できるため、貢献者に書き込み権限を付与しても、ワークフローの実行権限は付与する必要がありません。
一般的な攻撃者の手法を阻止する
ワークフロー実行保護機能は、現実世界で頻繁に発生するいくつかの攻撃パターンを妨害します：
プルリクエストからの汚染されたパイプライン実行：pull_request_target を組織全体、特に最も悪用されやすい公開リポジトリでも制限または禁止します。
手動トリガーの濫用：workflow_dispatch をメンテナーに限定し、信頼できないアイデンティティがワークフローを開始できないようにします。
信頼できないアクターによる実行：低信頼度のアイデンティティがワークフローを完全にトリガーできないようにブロックします。
設定ミスの悪用：単一の設定ミスのあるワークフローファイルでも即座に無効化する中央ポリシーを適用します。
はじめに
「Actions」セクション内の新しい「Policies」セクションで、組織およびリポジトリ設定にてワークフロー実行保護機能を見つけることができます。この「Policies」セクションは新しく、既存の「General」アクション設定とは別に設けられています。
詳細については、GitHub Actions ドキュメントの「ワークフロー実行保護機能」に関する記事をお読みください。
GitHub コミュニティ内での議論に参加してください。
「誰が、何が GitHub Actions ワークフローをトリガーするかを制御する」という投稿は、最初に The GitHub Blog で掲載されました。
原文を表示
Workflow execution protections are now in public preview for GitHub Enterprise, organizations, and repositories. This new capability lets enterprise administrators define an allow list that controls who can trigger GitHub Actions workflows and which events are permitted to run them, giving you predictable, secure workflow execution.
Previously, a workflow ran based on the workflow file in the commit that triggered it. An attacker with repository access could modify that file to run malicious code. Workflow execution protections close that gap. Administrators define the rules and GitHub Actions evaluates them before a run, so an unauthorized actor or event can never trigger an unwanted workflow execution.
One policy, every repository
Workflow execution protections are built on the GitHub rulesets framework, so the targeting you already know from rulesets works here too. You can apply protections across your enterprise with organization-wide rulesets and scope them to specific repositories using repository custom properties. That means you stop reasoning about security one YAML file at a time and instead make broad protections visible and enforceable in one place. You can also use evaluate mode to run your rules in shadow, so you can see exactly what a rule would block before you enforce it and roll out policies. This helps prevent you from breaking existing workflows.
Two rule types to start
Event and actor are the first two rule types, and we’ll add more over time.
Actor rules control who can trigger workflows, including individual users, repository roles (e.g., Read, Maintain, and Admin), GitHub Apps, Copilot, and Dependabot.
Event rules control which events are permitted, such as push, pull_request, pull_request_target, and workflow_dispatch.
By default, every user with write access to a repository can trigger workflows. Actor rules let you separate who contributes code from who runs your CI, so you can grant a contributor write access without granting them the ability to execute workflows.
Stop common attacker techniques
Workflow execution protections disrupt several real-world attack patterns:
Poisoned pipeline execution from pull requests: Restrict or prohibit pull_request_target across your organization, including in public repositories where it’s most often exploited.
Manual-trigger abuse: Limit workflow_dispatch to maintainers so untrusted identities can’t kick off workflows.
Untrusted-actor execution: Block low-trust identities from triggering workflows entirely.
Misconfiguration exploitation: Apply central policy that short-circuits any single misconfigured workflow file.
Getting started
You’ll find workflow execution protections in your organization and repository settings under “Actions”, in the new “Policies” section. This “Policies” section is new and separate from your existing “General” Actions settings.
To learn more, read about workflow execution protections in the GitHub Actions documentation.
Join the discussion within GitHub Community.
The post Control who and what triggers GitHub Actions workflows appeared first on The GitHub Blog.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み