GitHub ActionsのセルフホストMac Runnerは安全？2026年の受け入れチェックリスト

PR検証と署名付き公開が同じMac Runnerに集まり、秘密情報まで見える状態になっていませんか。

今週は、未信頼コードを署名環境から切り離し、Runnerのアクセス範囲とジョブ後の清掃を記録してください。分離を証明できないRunnerは、署名情報を使う本番公開に使わないでください。

GitHub ActionsのセルフホストMac Runnerの安全性は、Macかどうかだけでは決まりません。誰がコードを実行させられるか、タスクと資格情報が隔離されているか、作業後の状態を検証できるかで判断します。プライベートリポジトリや環境承認を設定しただけで、安全とみなすのは避けてください。

GitHub ActionsでiOSアプリを構築する個人開発者は、イベントとRunnerの実行条件を照合できます。
署名・公開情報を管理する小規模チームは、秘密鍵やトークンの閲覧範囲を確認できます。
複数リポジトリを運用する担当者は、Runnerの共有先と管理権限を点検できます。

未信頼のPRを処理する環境は、署名用Runnerと分ける

公開リポジトリからのPR検証は、変更者が信頼できないコードを実行する可能性を前提に設計します。GitHubは、自托管Runnerがワークフロー内のコードによる影響を受ける可能性を示しているため、PRのビルド結果が成功することと、ホストが安全であることは別の確認事項です。GitHubのActions安全利用ガイドを読み、実行されるコードと資格情報の関係を確かめてください。

pull_request と pull_request_target は、名称だけで安全性を判断できません。イベントによる権限の違いと、実際にチェックアウトして実行するコードを確認し、特権を持つイベントで未信頼のPRコードを実行しないでください。イベントの動作はGitHubのワークフロートリガー資料と、pull_request_targetの安全な利用に関する説明で照合できます。

環境承認は承認の流れを制御する仕組みであり、Runnerのファイルやキーチェーンを未信頼コードから隔離した証拠にはなりません。同じホストでPR検証と署名処理を行うなら、PRジョブが署名用の秘密情報を参照できないことを、ワークフローと実行環境の両方から確かめます。

信頼済みブランチでも、権限とRunnerの利用者を絞る

信頼済みブランチの構築でも、ワークフローに付与した権限が過剰なら、侵害時や設定ミス時の影響範囲が広がります。GITHUB_TOKENには必要な権限だけを設定し、書き込みが不要な構築ジョブでは読み取りに限定できるかを確認してください。ワークフロー構文の権限設定と、GitHubの安全利用ガイドを根拠に、設定ファイル上の権限と実際の処理を突き合わせます。

permissions:
  contents: read

この例は権限を検討する出発点であり、すべてのワークフローに適用すべき設定ではありません。リリース処理が追加権限を必要とするなら、その理由と利用するジョブを明記し、検証用ジョブにまで同じ権限を広げないでください。

第三者Actionは、提供元と参照方法を調査し、バージョン固定の方針を決めます。また、そのRunnerをどのリポジトリやチームが利用できるかを設定画面で確かめます。GitHubのセルフホストRunnerのアクセス管理資料を参照し、登録した場所だけでなく、実際にジョブを割り当てられる範囲を記録してください。

iOS署名の秘密情報は、公開ジョブだけに渡す

Appleの説明では、コード署名に使う署名アイデンティティは、証明書と対応する秘密鍵を含みます。Appleの署名証明書に関する資料に照らし、証明書だけを管理しているつもりにならず、秘密鍵の所在と利用者も把握してください。

iOS署名資格情報の管理では、秘密情報ごとに「どのジョブが使うか」「どこから参照できるか」「失敗時に何が残るか」を整理します。App Store Connect向けの資格情報も、通常のビルドやPR検証で必要かどうかを分けて判断します。認証情報をログへ出力しないことに加え、一時ファイルや失敗したビルド成果物に含まれないかを確認します。実際の鍵やトークンの値をサンプルとして記録に貼り付ける必要はありません。

秘密情報をCIの設定画面に登録しただけでは、Runner上でのアクセスやジョブ後の残留まで制御できたことにはなりません。読み取り権限のある処理、ログ、作業領域、成果物を一緒に点検してください。

ジョブ間の残留と複数リポジトリ共有を別々に検査する

同じMacでタスクを続けて実行する場合、作業ディレクトリを片付けただけでは不十分です。キーチェーンの状態、一時的に保存した資格情報、ビルド成果物、ログが次のジョブに渡らないかを、実際の清掃手順と後続ジョブで確認します。GitHubは一時的なRunnerなども安全策として案内していますが、Runnerの登録を単回にしたことだけで、ホストの状態まで清潔になったと判断することはできません。セルフホストRunnerの資料にある境界を踏まえ、基盤側の再利用方法と清掃記録を別に確認してください。

複数のリポジトリでRunnerを共有する場合は、リポジトリごとのアクセス許可、Runnerグループ、管理担当者を照合します。関係のないプロジェクトから同じホストを呼び出せる設定なら、ワークフローの作成権限とホスト上の秘密情報が交差しないかを見直してください。共有範囲を説明できない場合は、リポジトリ単位または公開責任単位でRunnerを分けます。

ここまでの点検は、iOS継続的インテグレーションの安全性を、コードの信頼度、ワークフローの起動権限、Macの隔離、署名鍵の保護、タスク後の清掃に分けて判断するためのものです。Macを使っているという理由だけで安全とも危険とも決めず、実際の権限と記録を根拠にします。

よくある運用判断を、実行条件に当てはめる

公開リポジトリの変更を検証する処理は、秘密情報のない隔離環境に限定します。信頼済みブランチのビルドは、最小権限とRunnerの利用制限を確認してから実行します。署名付きリリースは、秘密鍵を必要とするジョブだけにアクセスを許可し、通常のPR検証と分離してください。

前のタスクの状態が残らないかは、清掃コマンドを設定した事実だけでなく、検証用の後続ジョブで確かめます。Runnerを共有しているなら、同じ確認をリポジトリごとのアクセス設定と合わせて行います。

条件分岐で、本番公開に使うか決める

以下は運用判断のための採点基準です。点数は安全性の実測値ではなく、確認結果をチーム内で比較するための目安です。

条件分岐

• すべての項目を2点で記録できるなら、代表的なPR検証と公開処理を実行し、証拠を残したうえで本番利用を検討します。
• 0点がなくても1点があるなら、未確認箇所を解消するまでは署名付き本番公開を任せず、秘密情報のない構築用途に限定します。
• 未信頼コードから署名情報へ到達できる、またはタスク後の残留を否定できない場合は、そのRunnerを署名付き公開に使わず、実行環境を分離します。

公開前に記録する確認手順

起動条件とコードの出所を記録します。 PR、ブランチ、手動実行など、どのイベントが対象Runnerへ処理を割り当てるかをワークフローごとに一覧化します。実行されるコードが誰の変更か、特権イベントで未信頼コードを扱わないかも併記します。

トークンとRunnerの許可範囲を照合します。 ワークフロー構文の権限設定を確認し、各Runnerを利用できるリポジトリと管理担当者を記録します。第三者Actionの出所やバージョン固定の扱いも同じ記録に加えます。

署名情報へのアクセスを追跡します。 証明書、対応する秘密鍵、公開用資格情報を分けて棚卸しし、それぞれを必要とするジョブだけが参照できるか確認します。値そのものを記録せず、利用先と制限方法を残してください。

ジョブ終了後の清掃を実行結果で確かめます。 作業領域、キーチェーン、一時ファイル、ログ、成果物の処理方法を確認し、秘密情報を渡さない後続ジョブで残留がないか検査します。Runnerの登録解除だけで清掃完了としないことが重要です。

代表的な構築と公開処理を試し、未解決事項を残します。 成功したかだけでなく、権限、Runner割り当て、ログ、成果物、清掃の証拠を保存し、未確認のリスクと担当者を記載します。すべての確認項目について記録がそろわない間は、署名付き公開を本番に移さないでください。

現行Runnerが日常のPR検証と署名付き公開を分けられず、作業後の状態も確認できないなら、まず実行先を分離する方が安全側の判断です。Macを購入して専用機として運用する方法は、継続的に同じ環境を管理したい場合に合います。一方、保守、権限管理、清掃の検証を自分で担う必要があり、すぐに専用機を用意するほどではない検証や移行では、Macのレンタルも比較対象になります。VPSMACの利用できるMac環境の案内で交付・アクセス条件を確認し、東京のMac環境案内で接続先の選択肢も確認したうえで、実際のワークフローに必要な隔離と清掃を別途検証して選んでください。