GitHub Actions 自己ホスト型Mac Runnerのシークレット漏えい対処：2026年調査ガイド

ワークフローのログに認証情報らしき値が出た、またはMac Runnerが見覚えのない処理を始めた。
まず疑わしいワークフローを止め、対象Runnerを隔離し、露出の可能性がある認証情報を失効・更新します。環境と権限を確認し、信頼できるコードで再検証するまでジョブを戻さないでください。

自分のリポジトリでmacOSビルドを行い、秘密情報の露出を疑っている個人開発者向けです。
顧客のリポジトリを扱うフリーランスや、異常なワークフロー通知を受けた小規模チームも対象です。
導入方法ではなく、止血から復旧判断までを順に確認します。

最初に兆候を分類し、漏えい確定と決めつけない

「シークレットらしい文字列が出た」「不審なプルリクエストが実行された」「Runnerの動作が変わった」は、それぞれ異なる兆候です。単独の通知だけで漏えい確定とは判断せず、実行履歴とワークフローの設定を照合してください。

選択肢・兆候	先に確認すること	判断と初動
ログやビルド出力に認証情報らしき値がある	該当ジョブ、出力元、使われたシークレットやトークン	ワークフローを停止し、値が有効なら失効・更新を進めます
信頼できないコードが実行された可能性がある	イベントの種類、コードの出所、承認条件、トークン権限	Runnerを隔離し、コードが触れた可能性のある認証情報を調査します
Runnerに見覚えのない挙動がある	ジョブ履歴、実行時刻、変更された設定やファイル	新たなジョブを受け付けないようにし、組織の対応手順に従って調査します
通知はあるが実行記録に不審点が見つからない	通知対象のイベント、該当ログ、設定変更履歴	追加証拠を確認します。兆候が解消するまでは監視を続けます

この段階では、ログの存在だけでなく、何のイベントがワークフローを起動し、どのコードがRunner上で実行されたかが重要です。GitHubの安全な利用に関する説明では、セルフホストRunnerが常にクリーンで一時的な環境になるとは限らず、信頼できないワークフローのコードがRunnerやアクセス可能な認証情報を危険にさらす可能性を示しています。

プルリクエスト経由でコードが動いた経路を追う

プルリクエストが起点なら、イベント名だけで安全性を判断しないでください。リポジトリがフォークからのプルリクエストを受け付けているか、承認前の実行が許されているか、ワークフローがどのブランチやコミットのコードをチェックアウトしたかを確認します。

特に、pull_request_targetを使うワークフローが、信頼されていないプルリクエストのコードを取得して実行していないかを確認してください。GitHubのpull_request_targetに関する注意事項は、イベントの権限と、実行するコードの信頼性を分けて扱うよう説明しています。レビューや承認を回避する設定変更ではなく、実行元と承認条件を保ったままリスクを調べます。

そのうえで、ワークフローファイルのイベント条件、ジョブ単位のpermissions、参照するActionの出所を照合します。ワークフロー構文の権限設定を見ながら、不要な書き込み権限が付与されていないかを確認してください。

ログのマスキングを漏えい否定の根拠にしない

ログに値が表示されていなくても、秘密情報が安全だったとは限りません。自動マスキングは保護の補助手段であり、すべての変換・加工された値や、出力方法を保証するものではありません。GitHub Secretsの取り扱いに関する説明を確認し、ログの表示だけでなく、実行された処理と認証情報の利用範囲を追跡します。

最初に、露出の可能性があるものを分類します。リポジトリ、環境、組織に登録されたシークレットなのか、GITHUB_TOKENなのか、外部サービスのキーなのかを分けて記録してください。個々のシークレット値には48 KBの上限がありますが、サイズ上限は安全性を示すものではありません。上限はGitHub Secretsの仕様で確認できます。

GITHUB_TOKENはワークフロー実行のジョブごとに発行され、ジョブが終わると期限切れになります。ただし、実行中に使われた権限や、別途渡された認証情報まで無効になるわけではありません。GitHubのGITHUB_TOKENの説明を参照し、トークンの種類ごとに処置を分けてください。

ログにシークレットが見えないことは、「外部へ渡らなかった」証拠ではありません。実行されたコード、権限、外部サービス側の利用記録も合わせて確認します。

受け付け停止から再開判定までを時系列で進める

1. 対象ワークフローの新規実行を止める

疑わしいワークフローの起動条件を一時的に止め、実行中のジョブがあれば状況を記録してから停止を判断します。ほかの正常なビルドまで広く止める前に、対象リポジトリ、イベント、Runnerを特定してください。

2. Runnerを隔離し、記録を残す

対象Runnerがジョブを受け付けない状態にし、必要なイベント時刻、ワークフロー名、実行ID、関連するコミットやプルリクエストを記録します。調査前にログや設定を消さず、組織のインシデント対応手順に沿って保全範囲を決めます。

ジョブの記録はGitHub Actionsのワークフローログ手順を参照して確認してください。ログを調べるために、隔離したRunnerへ別の未検証コードを実行するのは避けます。

3. 該当する認証情報を無効化または更新する

露出した可能性があるキー、トークン、シークレットを特定し、発行元サービス側で失効できるものは失効させます。更新後の値を登録するだけでは旧値は無効になりません。必要に応じてアクセスログを確認し、同じ認証情報を使っていた別のワークフローや担当者にも影響範囲を確認します。

4. Runnerとリポジトリの権限を再点検する

ワークフローのイベント条件、ジョブごとのGITHUB_TOKEN権限、保護された環境の承認条件、第三者Actionの参照先を確認します。顧客のリポジトリを扱う場合は、顧客側とRunner管理側のどちらが秘密情報の失効や環境再構築を担当するかも明確にしてください。

5. 環境の清掃・再構築を終えてから登録を判断する

不審なコードがRunner上で実行された可能性がある場合、登録解除と再登録だけで環境が安全になったとは扱えません。調査結果に応じて組織の責任者が清掃・再構築の要否を判断し、その作業後にRunnerを再登録するか決めます。セルフホストRunnerの削除手順を使う場合も、登録情報の扱いとホスト環境の対応を別々に確認してください。登録トークンの有効期限は1時間です。これはRunnerへの登録に使うトークンの期限であり、侵害済み環境を安全に戻す期限ではありません。

6. 信頼できるコードで復旧を検証する

環境の対応と権限の見直しが済んだ後、確認済みのコードを使った制御下のワークフローを実行します。Runnerの状態、シークレットが渡るジョブの範囲、必要なビルド結果を確かめ、不要な書き込み権限やログ出力が残っていないことも見直してから通常運用へ戻します。

一連の確認には、macOS環境の接続・保護範囲を整理したリモートMac環境の確認ガイドも参考になります。ホスト環境の管理責任と、リポジトリ内の権限設定は別の項目として確認してください。

FAQ：停止・認証情報・復旧の確認ポイント

漏えいの疑いが出たら、最初に何を止めますか？
対象ワークフローの新規実行と、疑わしいRunnerへのジョブ配信を止めます。実行履歴を保全し、影響するシークレットやトークンを特定して失効・更新を進めます。通知だけで漏えい確定とせず、イベント、コードの出所、権限を照合してください。

プルリクエストのコードにシークレットが渡ったか、どこを見ますか？
イベント条件、フォークからの変更を実行する承認条件、ワークフローが取得したコードを確認します。高い権限を持つイベントで未検証のコードを実行していないかも調べてください。マスキングされたログだけでは、シークレットが使われなかったとは判断できません。

不審なコードを動かしたRunnerは再登録すればよいですか？
再登録だけでは不十分です。Runner環境が変更された可能性を調べ、組織の対応方針に従って隔離、清掃または再構築を行ってから登録を検討します。環境の状態を確認できない場合は、ジョブの受け付けを再開しないでください。

シークレットを更新すれば、古い認証情報は使えなくなりますか？
値を更新しただけでは、外部サービスに残った古いキーやトークンは失効しません。発行元で無効化し、利用記録と権限を確認します。その後、制御したワークフローで新しい認証情報の利用範囲とビルド結果を検証してください。

自前のMacをRunnerに使う方式は、ホストの状態やネットワーク、持ち出し端末の管理を自分で担う必要があります。移動中の開発でホストの維持が負担なら、Mac環境を遠隔利用する選択肢もありますが、レンタルへ移ってもリポジトリ権限やシークレット管理の責任がなくなるわけではありません。導入前にデータ保護に関する案内で管理範囲を確かめ、必要な期間だけ環境を用意したい場合はmacminirentのMacレンタルの条件と責任分界を確認してから判断してください。

よくある質問

セルフホストRunnerで漏えいの疑いが出たとき、まず何を止めればよいですか？

最初に対象ワークフローの新しい実行を止め、Runnerがジョブを受け取らない状態にします。次に該当する認証情報の利用を制限し、ログや実行履歴を保全してください。兆候だけで漏えい確定とはせず、実行イベント、コードの出所、トークン権限を突き合わせます。

プルリクエストのコードにGitHub Actionsのシークレットが渡ったか、どう確認しますか？

イベント種別、承認条件、実行されたワークフローファイル、チェックアウトしたコードの出所を確認します。特に、信頼されていないコードを高い権限のイベントで実行していないかを調べてください。ログに値が見えないことだけでは、シークレットが使われなかった証明にはなりません。

不審なコードを実行したMac Runnerは、登録し直せば使えますか？

登録解除と再登録だけで安全になったとは判断できません。不審なコードがRunner環境や永続データを変更した可能性がある場合は、組織の対応手順に従って隔離し、調査・清掃または再構築を済ませてから再登録を検討します。新しい登録情報を既存環境に渡す前に、責任範囲も確認してください。

GitHub Actionsのシークレットを更新した後、古い認証情報が使えないことをどう確かめますか？

サービス側で古いキーやトークンを失効させ、関連する認証ログや権限設定で旧情報が拒否されることを確認します。値を新しいシークレットに置き換えただけでは、コピー済みの認証情報は無効になりません。安全な環境から制御したワークフローを実行し、必要な権限だけで処理が完了するかも確認してください。