お疲れ様です！IT業界で働くアライグマです！
「GitHub Actionsのシークレットって、どこまで安全なんだろう？」「悪意あるPRからシークレットが漏洩するって本当？」
CI/CD環境におけるシークレット管理は、多くのエンジニアが「なんとなく大丈夫だろう」と思いながらも、実は十分に理解していない領域です。先日公開されたZennの記事「GitHub Actionsのシークレットは簡単に見れる」がSNSで話題になったことからも、この問題への関心の高さがうかがえます。
実際のプロジェクトでは、シークレットの漏洩がインシデントにつながるケースが増えています。本記事では、GitHub Actionsにおけるシークレット管理の仕組みと、CI/CD環境を安全に運用するための実践的な対策を解説します。
GitHub Actionsのシークレット管理の基本と落とし穴
GitHub Actionsでは、APIキーやトークンなどの機密情報をSecretsとして保存し、ワークフロー内で安全に参照できます。しかし、この機能には多くの開発者が見落としがちな落とし穴があります。
シークレットの基本的な仕組み
- 暗号化保存: シークレットはLibsodium sealed boxで暗号化され、GitHubのサーバーに保存される
- ログマスキング: ワークフローのログ出力時に自動的にマスクされる（***表示）
- スコープ: リポジトリレベル、環境レベル、Organizationレベルで設定可能
見落としがちなリスク
- フォークからのPRで漏洩: pull_request_targetイベントを使うと、フォークからのPRでもシークレットにアクセスできてしまう
- ログへの間接的な出力: base64エンコードやURLエンコードなど、変換後の文字列はマスク対象外
- アーティファクトへの混入: ビルド成果物にシークレットが含まれると、ダウンロード可能になる
GitHub Actionsのセキュリティ設定については、MongoDBセキュリティ設定ガイドで紹介したDBセキュリティの考え方と同様、デフォルト設定を過信しないことが重要です。
IT女子 アラ美
ITアライグマワークフローにおける攻撃ベクトルと防御策
GitHub Actionsを狙った攻撃は、主に以下のパターンに分類されます。ここでは各攻撃手法と、それに対する具体的な防御策を解説します。
攻撃パターン1: 悪意あるPRによるシークレット窃取
最も一般的な攻撃パターンは、フォークリポジトリから悪意あるPRを送り、ワークフロー内でシークレットを外部に送信するものです。
# 危険な設定例（pull_request_targetでcheckoutするケース）
on:
pull_request_target:
jobs:
build:
runs-on: ubuntu-latest
steps:
# PRのコードをcheckoutすると、悪意あるコードが実行される
uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
run: npm install # package.jsonのpostinstallで攻撃可能
対策: ワークフローの分離とラベルベースの承認
# 安全な設定例
on:
pull_request: # pull_request_targetではなくpull_requestを使用
types: [opened, synchronize]
jobs:
# シークレット不要な処理は通常のPRイベントで実行
test:
runs-on: ubuntu-latest
steps:
uses: actions/checkout@v4
run: npm test
# シークレット必要な処理はラベル付与後に別ワークフローで実行
GitHub Actionsのベストプラクティスについては、IaCツール入門の記事でも触れたとおり、宣言的な設定で意図を明確にすることがセキュリティにもつながります。
IT女子 アラ美ITアライグマシークレットローテーションと最小権限の実装
シークレットが漏洩した場合の影響を最小化するには、ローテーションと最小権限の原則が不可欠です。
シークレットローテーションの自動化
# シークレットローテーション用ワークフロー
name: Rotate Secrets
on:
schedule:
cron: '0 0 1 * *' # 毎月1日に実行
workflow_dispatch:
jobs:
rotate:
runs-on: ubuntu-latest
steps:
name: Generate new token
id: new_token
run: |
# 新しいトークンを生成（サービス固有のAPI呼び出し）
NEW_TOKEN=$(curl -X POST ... | jq -r '.token')
echo "::add-mask::$NEW_TOKEN"
echo "token=$NEW_TOKEN" >> $GITHUB_OUTPUT
name: Update secret
uses: actions/github-script@v7
with:
github-token: ${{ secrets.ADMIN_TOKEN }}
script: |
const sodium = require('libsodium-wrappers');
await sodium.ready;
// シークレットを更新するロジック
最小権限トークンの設計
- Fine-grained Personal Access Token: リポジトリ単位で権限を絞ったトークンを使用
- GitHub App: 必要な権限だけを持つAppを作成し、Installation Tokenを使用
- OIDC連携: AWS/GCP/Azureへのアクセスは短命なトークンをOIDCで取得
OIDCによるクラウド連携については、ワークフローエンジン実装ガイドで紹介した認証パターンも参考になります。
IT女子 アラ美ITアライグマ依存関係とサプライチェーンセキュリティ
GitHub Actionsのセキュリティは、利用するActionやパッケージの安全性にも依存します。サプライチェーン攻撃への対策も重要です。
Actionのピン留め
# 悪い例: タグ指定（後から書き換えられる可能性）
uses: actions/checkout@v4
# 良い例: コミットSHA指定（イミュータブル）
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
Dependabotとセキュリティアラート
- Dependabot version updates: Actionのバージョンアップを自動PR化
- Secret scanning: 誤ってコミットされたシークレットを検出
- Code scanning: CodeQLによるワークフローファイルの静的解析
セキュリティスキャンの導入については、脆弱性検出ツール導入ガイドも参考にしてください。
IT女子 アラ美ITアライグマケーススタディ：CI/CD環境のセキュリティ強化プロジェクト
ここでは、あるWebサービス開発チームがGitHub Actionsのセキュリティを強化した事例を紹介します。
状況（Before）
- チーム規模: エンジニア8名、リポジトリ15個
- 課題: シークレットがOrganization全体で共有され、誰がどの権限を持つか不明確
- リスク: 1つのリポジトリが侵害されると、全サービスの認証情報が漏洩する恐れ
- 運用状況: シークレットのローテーションは手動で年1回程度、OIDC未導入
行動（Action）
- シークレット棚卸しを実施し: 全リポジトリのシークレット一覧を作成、不要なものを約40%削除した
- OIDC連携を導入し: AWS/GCPへのアクセスをすべてOIDCに移行したところ、長期認証情報の保存が不要になった
- 環境単位のシークレット分離を適用し: production/staging/developmentごとに別シークレットを設定した結果、影響範囲を限定できるようになった
- ワークフロー監査を導入し: pull_request_targetの使用箇所を洗い出し、3箇所を安全な実装に改修した
- 全体期間: 計画から完了まで約6週間
結果（After）
- GitHub外に保存する長期認証情報が約70%削減
- シークレットのスコープが明確化され、インシデント時の影響範囲を限定できるように
- セキュリティレビューがCI/CDプロセスに組み込まれ、新規ワークフロー追加時のチェックが定着
- チームのセキュリティ意識が向上し、開発者からの改善提案も増加
セキュリティ強化プロジェクトの進め方については、AIエージェント時代のキャリア戦略で紹介した「自動化に飲まれない価値の作り方」の視点も参考になります。
IT女子 アラ美ITアライグマ継続的なセキュリティ運用に向けて
CI/CDセキュリティは一度対策すれば終わりではなく、継続的な運用が必要です。
- 定期的な監査: 四半期ごとにシークレットとワークフローの棚卸しを実施
- インシデント対応手順: シークレット漏洩時の対応フローを事前に整備
- セキュリティ教育: 新メンバー向けにCI/CDセキュリティのオンボーディングを実施
チームセキュリティの強化については、自律型AIエージェント構築ガイドで紹介した㏄ール設計の知見も参考になります。
さらなる年収アップやキャリアアップを目指すなら、ハイクラス向けの求人に特化した以下のサービスがおすすめです。
| 比較項目 | TechGo | レバテックダイレクト | ビズリーチ |
|---|---|---|---|
| 年収レンジ | 800万〜1,500万円ハイクラス特化 | 600万〜1,000万円IT専門スカウト | 700万〜2,000万円全業界・管理職含む |
| 技術スタック | モダン環境中心 | Web系に強い | 企業によりバラバラ |
| リモート率 | フルリモート前提多数 | 条件検索可能 | 原則出社も多い |
| おすすめ度 | 技術で稼ぐならここ | A受身で探すなら | Bマネジメント層向け |
| 公式サイト | 無料登録する | - | - |
IT女子 アラ美ITアライグマまとめ
GitHub ActionsとCI/CD環境のセキュリティは、「なんとなく大丈夫」では済まされない領域です。
- シークレットの仕組みを理解する: マスキングの限界と攻撃ベクトルを把握
- pull_request_targetの取り扱いに注意: フォークからのPRでシークレットにアクセスできる設定を避ける
- OIDCで長期認証情報を減らす: クラウドへのアクセスは短命トークンで
- ActionのSHA指定とDependabot: サプライチェーン攻撃への対策
セキュリティは開発速度を下げるものではなく、安心して開発を続けるための土台です。今日からできる対策から始めてみてください。
IT女子 アラ美ITアライグマ
