GitHub Actionsの怪しいワークフロー保留とは｜実行前承認を初心者向けに解説

この記事でわかること

• GitHub Actionsが悪性の疑いがあるワークフローを実行前に保留する仕組み
• 承認待ちになったときに、何を確認すればよいか
• public repositoryとGitHub Enterprise Serverでの適用範囲の違い
• .github/workflows/、GITHUB_TOKEN、secretsを見る理由
• 自動保護に頼りすぎないCI/CD運用の考え方

結論・重要ポイント

1. 2026年7月28日のGitHub公式Changelogで、悪性の疑いがあるGitHub Actionsの実行を承認待ちにする保護が案内されました。
2. 対象になったワークフローは、書き込み権限を持つ共同作業者が確認・承認するまで実行されません。
3. この保護はGitHub側で自動適用され、記事執筆時点の公式説明では、github.com上のpublic repositoryが対象です。
4. 承認画面が出たら、特に**.github/workflows/**、外部Action、GITHUB_TOKENの権限、secretsの扱いを確認します。
5. 自動保留は入口の安全策であり、レビュー、最小権限、ログ確認、Code Ownersなどの運用を置き換えるものではありません。

対象読者と前提知識

この記事は、GitHubでコードを管理していて、GitHub Actionsのチェックやデプロイを使い始めた初学者向けです。

前提知識は、Pull Request、CI、ワークフローという言葉を見たことがある程度で問題ありません。ここでは、外部からの攻撃手法を深掘りするのではなく、承認待ちが出たときに落ち着いて確認する流れを扱います。

3人による授業形式の会話

コード・操作手順・具体例

1. 承認待ちで最初に見る場所

承認待ちになったら、まずPull Requestの差分で**.github/workflows/**配下を確認します。

.github/workflows/build.yml
.github/workflows/deploy.yml

ワークフロー変更がある場合は、次の観点を順番に見ます。

1. どのイベントで動くか
2. どの権限で動くか
3. どの外部Actionを使うか
4. どのコマンドを実行するか
5. secretsや環境変数へ触れていないか
6. デプロイ、削除、課金、外部公開につながらないか

削除、上書き、外部公開、課金、認証情報に関わる処理がある場合は、承認前にレビュー担当者を増やす方が安全です。

2. GITHUB_TOKENを最小権限にする例

GITHUB_TOKENは便利ですが、既定のまま広い権限で使うより、必要な権限だけに絞る方が安全です。次は、内容の読み取りだけを基本にする例です。

name: check

on:
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

この例は考え方を示すものです。実際のプロジェクトでは、テスト、成果物アップロード、コメント投稿、デプロイなど、必要な操作に応じて権限を追加してください。

3. 強い権限が必要な処理を分ける例

デプロイのように外部公開へつながる処理は、通常のPull Requestチェックと分けると確認しやすくなります。

pull_request:
  目的: 変更内容の検査
  権限: できるだけ読み取り中心
  secrets: 原則として使わない

push to main:
  目的: mainへ入った内容のビルド・公開
  権限: 必要最小限の公開権限
  secrets: 必要なものだけ使う

「Pull Requestでテストする処理」と「mainへ入った後に公開する処理」を分けると、未確認の変更が強い権限で動くリスクを下げやすくなります。

4. 外部Actionの参照を確認する

GitHub Docsでは、外部Actionを使うときの注意として、信頼できる参照方法やレビューの重要性が説明されています。特に、タグだけを信用する運用では、タグの移動や削除の影響を受ける可能性があります。

uses: actions/checkout@v4
uses: owner/action-name@0123456789abcdef0123456789abcdef01234567

どちらを使うかは、更新しやすさと固定しやすさのバランスです。重要なリポジトリでは、外部Actionの作者、更新履歴、参照先、権限を確認してから採用してください。

5. 承認前チェックリスト

承認ボタンを押す前に、最低限この順番で確認します。

□ .github/workflows/ の変更を確認した
□ pull_request_target や workflow_run の使用理由を確認した
□ GITHUB_TOKEN の permissions を確認した
□ secrets を使うジョブか確認した
□ 外部Actionの参照先を確認した
□ 削除、上書き、外部公開、課金につながる処理がないか確認した
□ 不安な場合は承認せず、詳しい人にレビューを依頼した

承認は「安全と判断した」という記録にもなります。迷う場合は、急いで承認するより、差分を小さくしてもらう、権限を下げてもらう、担当者を増やす方が安全です。

よくある誤解や失敗

GitHubが止めたら必ず攻撃だと思ってしまう

保留は、実行前に確認するためのサインです。必ず攻撃と断定するのではなく、何が変わったか、どの権限で動くかを確認します。

自動保留があるからレビュー不要だと思ってしまう

自動保留はレビューの代わりではありません。公式Docsでも、ワークフローや秘密情報、トークン権限を安全に扱う考え方が説明されています。

public repository以外にも同じように効くと思ってしまう

記事執筆時点の公式Changelogでは、対象はgithub.com上のpublic repositoryと説明されています。GitHub Enterprise Serverではこの保護は追加されていないとされています。

承認者を増やさず1人で判断してしまう

デプロイ、課金、削除、顧客データに関わるワークフローでは、1人で急いで判断しない方が安全です。CODEOWNERSや運用ルールで、誰が確認するかを決めておくと迷いにくくなります。

secretsをログに出していないから安全だと思ってしまう

秘密情報は、変換やエラー出力によってログへ出る可能性があります。GitHub Docsでは、秘密情報の扱い、マスク、ローテーション、権限の最小化が重要な実務として説明されています。

Q&A

Q. この保護を設定する必要はありますか？

A. 公式Changelogでは、GitHubが自動で適用すると説明されています。ただし、保護が出たときの社内確認手順は別途決めておく必要があります。

Q. 保留されたら、承認しないとテストも動きませんか？

A. 公式発表では、保留されたワークフローは承認されるまで実行されないと説明されています。必要なテストか、危険な処理を含むかを見て判断します。

Q. forkからのPull Request承認と同じものですか？

A. 似ている部分はありますが、今回の記事で扱うのは、悪性の疑いがあるワークフロー実行を保留する2026年7月28日の公式更新です。fork由来のワークフロー承認については、GitHub Docsに別の手順が用意されています。

Q. 個人や小規模チームでも気にする必要がありますか？

A. あります。小さなリポジトリでも、CIがデプロイ、通知、クラウド操作、パッケージ公開へつながっている場合は、ワークフロー変更の確認が重要です。

要点まとめ

• GitHub Actionsには、悪性の疑いがあるワークフローを実行前に保留する保護が追加されました。
• 保留されたワークフローは、書き込み権限を持つ共同作業者が確認・承認するまで実行されません。
• 記事執筆時点では、github.com上のpublic repositoryが対象として説明されています。
• 承認前には、.github/workflows/、イベント、権限、外部Action、secrets、公開処理を確認します。
• 自動保留に任せきりにせず、最小権限、レビュー担当、ログ確認、承認ルールを整えることが大切です。

授業に登場する3人については、MAO先生のIT授業 キャラクター紹介で確認できます。

公式資料・参考資料

• GitHub Changelog: GitHub Actions holds potentially malicious workflows for approval
• GitHub Docs: Approving workflow runs from forks
• GitHub Docs: Secure use reference

内容に合うCTA

GitHub Actionsは、テストやデプロイを自動化できる便利な仕組みです。一方で、ワークフローが強い権限や秘密情報を扱う場合、承認手順が曖昧だと、危険な変更を見落としやすくなります。

小規模チームや業務システムで、CI/CDの権限、承認フロー、GitHub運用ルールを整理したい場合は、MAO工房へご相談ください。