GitHub Actionsのセキュリティ点検｜権限・SHA固定・OIDCの確認チェックリスト

冒頭要約：ビルドが成功していても、権限の点検は必要

GitHub Actionsは、テストだけでなく、パッケージ公開や本番デプロイも自動化できます。その分、実行するコードや渡す認証情報を誤ると、リポジトリの外へ影響が及びます。

まず、本番に届くWorkflowから、誰が起動できるか・何のコードを実行するか・どこまで操作できるかを確認してください。外部ActionのSHA固定、最小権限、OIDC、承認を、それぞれ違う問題を防ぐ対策として組み合わせます。

この記事は特定の被害発生を伝えるニュースではなく、開発者・情シス・SaaS管理者向けの防御的な点検ガイドです。不審な実行を見つけた場合の停止、記録、認証情報の確認、再開判断まで扱います。攻撃の再現や漏えい値の動作確認は行いません。

GitHub Actionsのセキュリティで見る「3つの権限」

Workflowは自動処理の定義、Jobはその中の実行単位、RunnerはJobを実行する環境、Actionは処理を再利用する部品です。初心者は「自動処理専用の担当者に、どの鍵を渡しているか」と考えると整理できます。

権限・認証情報	何に使うか	点検先
GITHUB_TOKEN	WorkflowのリポジトリでGitHub APIなどを利用する	組織・リポジトリの既定設定と、Workflow・Jobのpermissions
保存したSecrets	PAT、npmトークン、クラウドキーなどで外部サービスへ接続する	Organization・Repository・Environmentの配布範囲と、発行元の権限
OIDCによるクラウド認証	Jobの識別情報をもとに、クラウドの短期資格情報を得る	JobのIDトークン取得権限と、クラウド側の信頼条件・ロール権限

GITHUB_TOKENはJobごとに発行されます。しかし、そのpermissionsを読み取り専用にしても、別に渡したPATやクラウドキーまで読み取り専用になるわけではありません。最小権限は、この3つを分けて適用します。

OIDC（OpenID Connect）では、GitHubが示すJobの識別情報をクラウド側が検証し、条件に合えば資格情報を発行します。id-token: writeはIDトークンを取得する許可であり、それ自体が本番データへの書き込み許可ではありません。実際にできる操作はクラウド側のロールなどで決まります。

読者別の影響：誰が何を担当するか

読者	主な確認対象	最初の成果物
個人開発者・OSS管理者	外部からのPR、公開用トークン、利用Action	公開権限を持つJobと管理者の一覧
開発者・CI管理者	Workflow、再利用Workflow、Runner、成果物	起動条件からデプロイ先までの実行経路
情シス・SaaS管理者	Organization設定、Secrets配布、管理者権限	複数リポジトリで共有する権限と連絡先
クラウド・SRE担当者	OIDCの信頼条件、本番ロール、監査ログ	GitHubの実行とクラウド操作を結ぶ記録
CSIRT・インシデント対応者	不審な変更、露出した権限、影響期間	封じ込め範囲、調査担当、再開承認者

すべてのWorkflowを一度に読み直すより、パッケージ公開、本番デプロイ、組織共通のSecretsを使うものから始めます。外部委託のCIであっても、自社の発行した認証情報やデプロイ先の責任者は明確にします。

まず確認すること：設定場所と合格条件のチェックリスト

以下は編集部による点検用の整理です。単なる「設定済み」ではなく、根拠となるファイル・設定・確認者を残してください。機能の利用可否は契約プランやリポジトリの可視性によって異なります。

1. 起動条件とGitHubの権限

• 起動条件：Workflowのonと呼び出し元を確認した。PR、手動実行、定期実行、別Workflowからの呼び出しについて、誰の変更が処理に入るか説明できる。
• 最小権限：設定画面とJobのpermissionsを確認した。読み取りを基準とし、書き込みは必要なJobと用途に限られ、理由が記録されている。
• 変更の承認：.github/workflows/などを変更するPRに適切な担当者のレビューが必要になっている。CODEOWNERSを置くだけでなく、ブランチ保護やRulesetsで必要なレビューが実際に要求されることを確認した。

pull_request_targetやworkflow_runなどを利用している場合は、イベント名だけで安全と判断しません。高い権限を持つ処理へ、未承認のPRコードや未信頼の成果物が渡って実行されないかを確認します。外部からの変更をテストする経路と、公開・デプロイする経路の境界が不明なら、CI管理者へレビューを依頼します。

2. 外部Actionと再利用Workflow

• 参照の固定：外部Actionと再利用Workflowのusesを棚卸しした。採用した提供元の、内容を確認した完全なコミットSHAに固定している。
• 更新の管理：SHAの出所、対応するリリース、確認者を記録した。更新提案には差分レビューとテストがあり、固定したまま更新を放置しない担当者がいる。
• 実行内容：Action自身の処理だけでなく、実行時に取得するスクリプト、依存関係、コンテナなども確認対象にした。更新可能な参照が残る場合はリスクと代替策を記録した。

タグは後から別のコミットを指す可能性があります。完全なSHAへの固定は「レビューした参照先を変えない」ための対策であり、そのコードが無害である証明ではありません。SHAを知らない第三者の投稿からコピーせず、提供元のリポジトリとレビューした内容を照合します。供給元を含む点検は開発ツール供給網の確認チェックリストへ進んでください。

3. Secrets・OIDC・本番承認

• Secretsの配布：Organization・Repository・Environmentそれぞれで、名前、発行元、所有者、用途、利用先を確認した。不要な配布や用途不明の値が残っていない。
• OIDCの信頼条件：クラウド側で、期待する発行者・対象者（aud）・主体（sub）など、対応する条件を確認した。意図したリポジトリと実行条件に限定され、組織名だけなどの広すぎる許可になっていない。
• クラウド権限：短期資格情報で利用するロールが、必要な環境・リソース・操作だけに限定されている。認証の条件と、認証後にできる操作の両方を確認した。
• 本番承認：デプロイJobが保護されたEnvironmentを参照し、必要な承認とブランチ・タグ制限を満たしてから進む。Environment secrets以外に同じ本番権限を渡す経路がない。

OIDCの条件を、別チームの設定からそのままコピーしないでください。Environmentを使う場合などは主体の表現が変わり、クラウドによって評価可能な属性も違います。ブランチ制約を信頼ポリシーだけで表せない構成では、Environment側のデプロイ制限などを併せて確認します。長期キーをOIDCへ移行しても、不要になった旧キーを残したままでは露出箇所は減りません。

4. Runner・ログ・成果物

• 実行環境の分離：未信頼コードを実行するRunnerが、本番権限を持つ処理や社内ネットワークへ不用意に接続できない。self-hosted runnerは利用リポジトリ、管理者、隔離・再構築方法が明確になっている。
• ログの扱い：秘密値を出力しない設計であり、閲覧者と保存先が適切である。マスキングだけを安全の根拠にしていない。
• 成果物の出所：本番に進めるファイルについて、生成したRun、ソースのコミット、確認者を追跡できる。別の信頼レベルのキャッシュや成果物を無条件に使っていない。

すべてを確認できなかった項目は「問題なし」ではなく「未確認」とします。担当者、期限、未確認の間に制限する権限を決めれば、棚卸しを実行可能な改善計画にできます。

不審な実行を見つけた時の初動対応

やること：停止・認証情報・証拠を並行して扱う

1. 対象を識別する：発見時刻、Repository、Workflow、Run ID、再実行の回数、実行者、起動イベント、ソースのコミットSHAを記録し、CI管理者とセキュリティ担当へ連絡します。被害の確定を待つ必要はありません。
2. 新規実行と実行中の処理を分けて止める：権限のある担当者が対象Workflowを無効化して新規実行を止めます。それとは別に、進行中・待機中のRunを確認してキャンセルし、停止状態を確認します。クラウドへすでに依頼したデプロイなどは、GitHub側のキャンセルだけでは止まらない場合があるため、実行先でも確認します。
3. 届き得た認証情報を封じ込める：該当Jobの権限と、到達可能だったSecretsを洗い出します。露出した、または不審コードがアクセスできた有効な資格情報は、発行元で失効・更新を進めます。Secret名、対象ID、実施時刻で管理し、値を共有しません。
4. クラウド側を確認する：OIDCの信頼条件の制限と、発行済み資格情報・セッションへの対応は別作業です。クラウド担当者がサービス固有の失効・アクセス拒否手段と監査ログを確認します。Jobの停止だけで全セッションが直ちに無効になると仮定しません。
5. 証拠と成果物を保全する：Workflowの当時の版、利用ActionのSHA、Run・デプロイ記録、閲覧可能な監査ログを承認された場所へ保存します。疑わしい成果物は本番への昇格・配布を保留します。Runner侵害が疑われる場合は、担当者の手順に従い隔離と保全を行います。

具体的な失効と影響範囲の整理には、GitHub secret leak対応チェックリストとGitHubトークン漏えい対応プレイブックを使えます。npmへの公開権限が関係する場合は、npmアクセストークン漏えい時の初動対応で公開履歴やmaintainerの確認も行います。

やらないこと

• 漏えいが疑われるトークンを試したり、確認目的でSecretをログへ出力したりしない。
• 原因不明のRunをそのまま再実行しない。権限付きで同じ処理を繰り返すおそれがあります。
• 証拠の扱いを決めずにWorkflow、ログ、Runnerをまとめて削除しない。
• SHA固定やSecretの差し替えだけで、配布済み成果物やクラウド側の影響が解消したと判断しない。
• 外部Actionの異常を見ただけで、攻撃者や侵害経路を推測して対外発表しない。

記録すべきこと：秘密値を入れない対応メモ

検知日時・タイムゾーン：
対象組織／リポジトリ／Workflow：
Run ID・URL／実行回数／起動イベント／実行者：
ソースのコミットSHA／外部Actionの参照：
利用Runner／本番Environment／成果物・デプロイの識別子：
認証情報の名前・ID・発行元・権限（値は記載しない）：
新規実行の停止／実行中Runの停止状態と時刻：
失効・アクセス制限の対象／実施者／確認時刻：
確認できた事実／未確認事項／証拠の管理先：
調査担当／次の確認期限／再開承認者：

判断基準：いつ緊急対応へ切り替えるか

以下は一律の公式判定基準ではなく、編集部が整理した優先度の目安です。自組織のインシデント区分、契約、報告手順を優先してください。

状況	優先度の目安	次の判断・エスカレーション先
不審なJobに本番変更・パッケージ公開権限がある、または無断の変更が確認された	緊急	CI・クラウド担当とCSIRTへ直ちに連絡。公開・デプロイの保留、認証情報の封じ込め、配布先への影響を並行確認
不審な実行があり、Secretsへの到達やクラウド操作を否定できない	優先調査	「ログにない＝無被害」とせず、権限・実行履歴・外部サービスの監査ログを突合。届き得る権限を制限
未信頼の変更と高権限Jobの境界が不明、広すぎるOIDC条件がある	優先是正	次の権限付き実行前に管理者レビュー。兆候の有無とは別に、露出経路を先に狭める
SHA未固定などの設定不足はあるが、不審な実行の兆候は確認されていない	計画改善。ただし権限が広い場合は前倒し	対象Action、更新担当、レビュー期限を決定。設定不足だけで侵害が起きたと断定しない

顧客データ、機密情報、配布済み製品への影響が疑われる場合は、調査チームだけで完結させず、責任者・法務・顧客対応窓口へつなぎます。影響範囲が不明であること自体も共有し、確認済みの事実と推定を分けて更新します。

小さな判断例：外部Actionの参照先が想定と違った

本番デプロイJobで、タグ参照の外部Actionがレビュー時とは別のSHAになっていたとします。ログに秘密値は出ておらず、処理は成功しています。

この情報だけでは侵害も安全も確定できません。まず意図した更新かを提供元の履歴と照合し、実行された処理、Jobの権限、利用可能だった認証情報、クラウド操作を確認します。出所や変更理由を確認できない間は、同じ経路での本番実行を保留します。不審コードによる認証情報へのアクセスが否定できなければ、失効と影響調査へ進みます。

復旧・再開の合格条件

• 起動元、Workflowの変更、外部Actionの参照をレビューし、不審な処理が残っていない。
• 不要な書き込み権限とSecrets配布を取り除き、OIDCの信頼条件とクラウド権限を確認した。
• 影響を受けた資格情報を更新し、発行済みセッションへの対応も発行元の手順に従って確認した。
• Runnerの信頼性を確認した。侵害が疑われる環境を単に再起動して再利用せず、必要に応じて保全後に信頼できる構成から再構築した。
• 確認済みソースと実行環境で成果物を作り直すなど、公開するものの出所を確認した。
• 承認者が再開範囲を決め、権限を絞った検証から再開した。再開後のログ確認担当と確認期間を決めた。

再開の可否と、インシデント調査の完了は分けて管理できます。業務継続のために限定再開する場合も、未解決事項と補完措置を記録し、緑のチェックが付いたことだけを承認理由にしないでください。

よくある誤解

SHA固定すれば、外部Actionは安全？

固定できるのは参照するコミットです。採用したコード自体の問題や、実行時に別途取得する依存物までは保証しません。内容のレビューと、固定後の更新運用が必要です。

OIDCなら、もう漏えいや不正利用を心配しなくてよい？

長期キーを減らせますが、信頼条件が広すぎたり、許可されたJob自体が不審な処理を実行したりする問題は残ります。認証方式の変更と、実行コード・クラウド権限の点検はセットです。

Secretsがマスクされ、ログに何もなければ無被害？

マスキングはログへの露出を減らす機能で、外部への送信やすべての表現を検知する保証ではありません。Jobが到達できた範囲と発行元の履歴を確認します。監査ログにも保存期間や取得できるイベントの制約があります。

privateリポジトリやself-hosted runnerなら安心？

非公開でも、実行されるコードや管理者アカウントを無条件に信頼できるわけではありません。特に自社管理のRunnerは、接続先、残存データ、再利用、保守の責任も自社にあるため、隔離と復旧方法を決めておきます。

関連用語・関連ページ：次に何を確認するか

目的	次に読むページ
漏えい疑いを実際の対応手順へ落とす	GitHub secret leak対応チェックリスト・トークン漏えい対応プレイブック
供給元・依存関係まで広げて点検する	開発ツール供給網チェックリスト・サプライチェーン攻撃と防御のレッスン
GitHubの公開範囲を誤った	リポジトリ誤公開時の初動対応
認証と認可の区別を学ぶ	OAuthとOIDCの違い・最小権限
開発と証拠の用語を確認する	SLSA・Secret Scanning・証拠保全
理解を定着させる	OIDCを用語クイズで確認・学習進捗

公式情報・参考情報

• GitHub Docs: Secure use reference — 外部Action、最小権限、Secrets、未信頼コード、Runnerに関する安全な利用の指針。
• GitHub Docs: Secure use reference（2026年5月14日版） — 2026年5月18日以前の公式資料として確認した履歴固定版。現在の設定手順には現行ドキュメントを使ってください。
• GitHub Docs: GITHUB_TOKEN — Job用トークンの役割と適用範囲。
• GitHub Docs: OpenID Connect — Jobの識別情報、クラウドの信頼条件、短期資格情報の関係。
• GitHub Docs: Deployment environments — 本番環境への承認、ブランチ制限、Secretsの保護。
• GitHub Docs: OpenID Connect reference — 信頼条件の属性とIDトークン取得権限。条件の形式は実際のリポジトリとクラウドに合わせて確認してください。
• GitHub Docs: Canceling a workflow run — 待機中・進行中の実行をキャンセルする方法。
• GitHub Docs: Disabling and enabling a workflow — 新たなイベントによる実行を止め、必要時に再開する管理方法。
• NIST SP 800-61 Rev. 3 — インシデントの検知、対応、復旧を組織のリスク管理へつなげる考え方。

設定の点検は、権限付きの自動処理を安全に続けるための作業です。まず本番に届くWorkflowを1つ選び、未確認の権限、実行コード、認証情報を担当者と一緒に埋めるところから始めてください。