【ITニュース解説】GitHub Actions Secrets: 8 Common Mistakes and Fixes

ウェブサイトの運営や自動化を進める上で、GitHub Actionsは非常に便利なツールだが、セキュリティ、特に「シークレット（秘密情報）」の扱いは注意が必要だ。シークレットとは、APIキー、パスワード、トークン、Webhook URLなど、他人に知られてしまうと、あなたの代わりにサービスを操作したり、アカウントを不正利用したり、費用を発生させたりする可能性のある、極めて重要な情報のことだ。これらの情報が外部に漏れると、取り返しのつかない事態につながる危険性があるため、その管理には細心の注意を払わなければならない。

シークレットが漏洩する原因は、巧妙なサイバー攻撃ばかりではない。多くの場合、開発者が意図せず、あるいは軽い気持ちで犯してしまう、単純なミスによって引き起こされる。ここでは、GitHub Actionsでシークレットが漏洩しがちな8つの一般的な間違いと、その対処法について解説する。

まず一つ目の間違いは、シークレットをコードやワークフローファイルの中に直接書き込んでしまう「ハードコーディング」だ。これは最も基本的なミスであり、一度コミットしてしまうと、たとえ後でファイルを削除しても、Gitの履歴には残り続けてしまう。この問題を解決するには、GitHubリポジトリの「Settings」→「Secrets and variables」→「Actions」でシークレットを登録し、ワークフロー内ではsecrets.SECRET_NAMEのように参照する方法を使う。例えば、Webhook URLを環境変数として渡すことで、実際の値がコードに現れることを防ぎ、安全に利用できる。環境変数経由で渡す方法は、直接コマンドに埋め込むよりも、引用符の問題を避けたり、コマンドのテキストから値を隠したりする上で推奨される。

二つ目の間違いは、デバッグのためにシークレットの値をログに出力してしまうことだ。GitHubはログ内のシークレットを自動的に隠そうとするが、完全に一致する値でなければ機能しない場合がある。例えば、すべての環境変数を表示するようなデバッグコマンドを使うと、意図せず多くの秘密情報が公開されてしまう危険性がある。デバッグが終わったら、ログに出力する行は必ず削除し、シークレットが設定されているか確認したい場合は、その値が空でないかだけをチェックするようにするべきだ。

三つ目の間違いは、GitHubのログマスキング機能を過信することだ。GitHubの自動マスキングは便利だが、そのドキュメントにも示されているように、値がエンコードされたり、断片化されたりすると、元の値と一致せず、マスキングが適用されないことがある。このリスクを減らすためには、一つのシークレットには一つの値を保存し、JSONやYAMLの塊全体を一つのシークレットとして保存しないようにする。また、ワークフロー内で生成される敏感な値については、echo "::add-mask::$VALUE"のように明示的にマスキングする指示を与えることで、確実に隠すことができる。

四つ目の間違いは、ジョブが必要とする以上の権限を持つキーを使用することだ。例えば、メッセージを投稿するだけの自動化に、削除や設定変更ができるキーを与えてしまうと、そのキーが漏洩した際の被害は甚大になる。常に「最小権限の原則」に従い、その作業に必要な最低限の権限だけを持つキーを使用するべきだ。また、プロジェクトごとに異なるキーを使うことで、一つのキーが漏洩しても他のプロジェクトに影響が及ぶのを防ぎ、必要に応じて特定のキーだけを無効化できる。リポジトリに書き込み権限を持つユーザーはシークレットを読み取れるため、共同作業者を追加する際も慎重な判断が必要となる。

五つ目の間違いは、組み込みのGITHUB_TOKENに過剰なアクセス権限を与えてしまうことだ。このトークンはワークフローがリポジトリと対話するために使われるが、デフォルトでは必要以上の権限を持っている場合がある。GitHubは、デフォルトの権限を読み取り専用に設定し、特定のジョブで書き込みなど追加の権限が必要な場合にのみ、そのジョブに限定して付与することを推奨している。ワークフローファイルの冒頭にpermissions: contents: readと記述することで、この設定を簡単に適用できる。

六つ目の間違いは、プルリクエスト（PR）からの危険なワークフロー実行を許してしまうことだ。特にリポジトリが公開されている場合や、フォーク可能な場合に問題となる。通常のpull_requestトリガーでは、フォークされたリポジトリからのワークフローはシークレットにアクセスできないが、pull_request_targetを使うとシークレットにアクセスできるようになる。GitHubはpull_request_targetの利用を避け、もし使う必要がある場合は、信頼できないPRのコードを実行しないよう強く警告している。見知らぬユーザーのコードがあなたのシークレットにアクセスできる状態で実行されることは、極めて危険な状況だ。個人的な自動化の場合、外部のPRからワークフローをトリガーしないのが最も安全な選択肢である。

七つ目の間違いは、信頼できないテキストを直接コマンドに貼り付けてしまうことだ。例えば、PRのタイトルや説明文を直接スクリプトのコマンドに組み込むようなケースだ。しかし、PRのタイトルは誰でも自由に記述できるため、もし悪意のあるシェルコマンドが含まれていれば、それがそのままあなたの実行環境で実行され、シークレットにアクセスされてしまう可能性がある。安全な方法は、まずその値を環境変数に格納し、その環境変数をコマンドで参照することだ。これにより、入力されたテキストはコマンドの一部ではなく、単なるデータとして扱われるため、意図しないコマンド実行を防げる。

八つ目の間違いは、サードパーティ製のアクションを吟味せずに使用することだ。uses: someone/some-action@v1のように記述して他者のコードを実行する場合、もしそのアクションにシークレットを渡せば、そのコードもシークレットにアクセスできることになる。対策としては、GitHub公式のアクションや、信頼できる有名で活発にメンテナンスされているプロジェクトのアクションを優先して使うべきだ。また、アクションのコードを実際に読んで、どのような処理をしているかを確認することも重要である。さらに、バージョンタグではなく、完全なコミットSHA（ハッシュ値）でアクションを固定することで、タグが後から別のコードに差し替えられるリスクを回避できる。バージョン番号をコメントとして残しておくと、どのバージョンのアクションを使っているか後から分かりやすくなる。

万が一シークレットが漏洩してしまった場合は、以下の順序で対応することが重要だ。まず、最も優先すべきは、漏洩したシークレットをすぐに「置き換える」ことだ。新しいキーやトークンを作成し、古いものは利用元のサービス側で直ちに無効化する。これが、あなたを実際に保護する唯一の方法だ。次に、もしログにシークレットの値が表示されてしまっていたら、そのワークフローのログを削除する。そして、サービスのアクティビティログや使用状況のページを確認し、身に覚えのない操作や利用がないかチェックする。最後に、もしシークレットがリポジトリの履歴にコミットされてしまっていた場合は、履歴から削除するなどのクリーンアップを行う。ただし、一度公開されてしまった情報はコピーされている可能性が高いため、リポジトリのクリーンアップだけで安心せず、必ずシークレットの無効化と置き換えを最優先で行うべきだ。古いキーは無効化するまで機能し続けてしまうことに注意が必要だ。

新しいワークフローをプッシュする前には、コードやワークフローファイルにシークレットが直接含まれていないか、デバッグ目的でシークレットをログに出力する行がないか、各シークレットが単一の値として保存されているか、それぞれのキーが必要最低限の権限しか持っていないか、permissions: contents: readが設定されているか（より多くの権限が必要なジョブを除く）、pull_request_targetを本当に使う必要があるのか、信頼できないテキストが環境変数経由で扱われているか、サードパーティ製のアクションが信頼され、コミットSHAで固定されているか、そしてリポジトリのセキュリティ設定でシークレットスキャンとプッシュ保護が有効になっているか、といった点を必ず確認するべきだ。

GitHub Actionsのシークレットは、適切に扱えば安全だが、その安全性はワークフローの設計にかかっている。意図しないログ出力、信頼できないコードへの渡し方、過剰な権限の付与など、ちょっとした不注意が漏洩の原因となる。シークレットをファイルに残さず、ログに出力せず、必要最小限のアクセス権限を与える。これらを守ることで、ほとんどのリスクをカバーできる。