🛡️

【GitHub Actions】サプライチェーン攻撃を防ぐ！2026年版セキュリティ・ベストプラクティス

に公開
GitHub Actions
Security
DevSecOps
Supply Chain
tech

はじめに

GitHub Actionsは、CI/CDパイプラインを自動化するための強力なツールですが、その利便性の裏にはセキュリティリスクが潜んでいます。特に、サプライチェーン攻撃の脅威が増大する現代において、GitHub Actionsのセキュリティ設定はもはや無視できません。2025年には、人気のあるActionへの侵害事例も報告されており、攻撃手法は年々高度化しています。本記事では、GitHub Actionsを利用する開発者やDevOpsエンジニア向けに、2026年最新のセキュリティ・ベストプラクティスを解説し、サプライチェーン攻撃からプロジェクトを守るための具体的な対策を提示します。

※ 本記事は、複数の商用SaaSでGitHub Actionsを本番CI/CDとして運用し、OIDC移行やSelf-Hosted Runnerの侵害リスク評価を行ってきた実務経験をもとに整理しています。

サプライチェーン攻撃とは？なぜGitHub Actionsが狙われるのか？

GitHub Actionsサプライチェーンセキュリティの全体像

サプライチェーン攻撃の脅威

サプライチェーン攻撃とは、ソフトウェア開発やデリバリーの過程に存在する脆弱性を悪用し、最終的な製品やサービスに悪意のあるコードを混入させる攻撃手法です。近年、その被害は増加の一途を辿っており、企業にとって深刻な脅威となっています。

GitHub Actionsが狙われる理由

GitHub Actionsは、コードのビルド、テスト、デプロイといった重要なプロセスを自動化するため、多くの権限を持つことがあります。もしGitHub Actionsのワークフローが侵害されれば、攻撃者はリポジトリへの不正アクセス、機密情報の窃取、悪意のあるコードのデプロイなど、甚大な被害を引き起こす可能性があります。

GitHub Actionsセキュリティ対策の全体像

対策カテゴリ 概要 具体的なアクション
権限の最小化 ワークフローに必要最小限の権限のみを付与する permissions キーによる制御、OIDCの活用
シークレット管理 機密情報を安全に扱い、漏洩リスクを低減する GitHub Secretsの利用、OIDCによるシークレットレス認証
依存関係の保護 外部依存関係（Action、パッケージ）の安全性を確保する サードパーティActionの固定（SHA）、Dependabotによる脆弱性スキャン
環境の分離 開発・ステージング・本番環境の分離と保護 環境保護ルール、承認フローの導入
監視と監査 不審なアクティビティを検知し、迅速に対応する GitHub Advanced Security、監査ログの活用

2026年版！GitHub Actionsセキュリティ・ベストプラクティス

1. 権限の最小化（Least Privilege）の徹底

GitHub Actionsのワークフローは、デフォルトで広範な権限を持つことがあります。これを必要最小限に絞り込むことが、セキュリティ強化の第一歩です。

permissions キーによる制御

ワークフローファイル内で permissions キーを使用し、ジョブやワークフロー全体に付与する権限を明示的に指定します。これにより、意図しない権限の悪用を防ぎます。

name: CI/CD Pipeline
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read # リポジトリの読み取り権限のみ
      packages: write # パッケージの書き込み権限
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test

  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write # OIDC認証のために必要
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to AWS
        run: | # OIDCを利用したデプロイコマンド
          aws configure set default.region ap-northeast-1
          aws sts assume-role-with-web-identity \
            --role-arn arn:aws:iam::123456789012:role/github-actions-role \
            --role-session-name GitHubActions \
            --web-identity-token $ACTIONS_ID_TOKEN_REQUEST_TOKEN \
            --duration-seconds 3600
          # ... デプロイ処理 ...

OpenID Connect (OIDC) によるシークレットレス認証

OIDCを利用することで、AWSやGCPなどのクラウドプロバイダーに対し、長期的な認証情報（シークレットキー）をGitHub Secretsに保存することなく、一時的な認証情報で安全に認証を行うことができます。

重要：Trust Policyでの sub クレームの制限
OIDCを利用する際は、クラウド側の信頼ポリシー（Trust Policy）で sub (Subject) クレームを厳格に検証することが必須です。単にリポジトリ全体を許可するのではなく、特定のブランチや環境（Environment）に限定することで、いわゆる「Confused Deputy（混乱した代理人）」攻撃のリスクを最小化できます。

// AWS Trust Policy Example (Strict)
"Condition": {
  "StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
  }
}

2. 依存関係の保護：サードパーティActionとパッケージの安全性

外部のActionやライブラリは便利ですが、悪意のあるコードが含まれていたり、脆弱性が発見されたりするリスクがあります。

サードパーティActionの固定（SHAハッシュの使用）

uses キーでActionを指定する際、バージョンタグ（例: v4）ではなく、コミットのSHAハッシュ（例: actions/checkout@b4d746a6e297072676781177287965904574974c）を使用することで、Actionの変更による意図しない挙動やセキュリティリスクを防ぎます。

steps:
  - uses: actions/checkout@b4d746a6e297072676781177287965904574974c # SHAハッシュで固定
  - uses: actions/setup-node@60edb5dd545a775178f528d6a85fa69e32d5dd1e # SHAハッシュで固定

組織レベルでのAction許可リスト（Allow List）

企業や組織で利用する場合、開発者が任意のActionを自由に利用できる状態はリスクになります。GitHub Organizationの設定で「Allow specific actions and reusable workflows」を有効にし、利用可能なActionを、GitHub公式や認証済みクリエイター、または自社で管理しているものだけに制限することを強く推奨します。

Dependabotによる脆弱性スキャン

Dependabotを有効にすることで、プロジェクトが依存するライブラリやパッケージの既知の脆弱性を自動的に検出し、修正を促すプルリクエストを生成してくれます。これにより、常に最新のセキュリティ状態を保つことができます。

3. 環境の分離と保護

本番環境へのデプロイは、厳重な管理下で行われるべきです。

環境保護ルール（Environment Protection Rules）

GitHub Environmentsを活用し、本番環境（Production）には以下の保護ルールを適用します。

  1. Required Reviewers（必須レビュアー）: 特定のチームメンバー（QAチームやテックリードなど）の承認がない限り、ジョブを実行させない。
  2. Wait Timer（待機時間）: デプロイ前に一定の待機時間を設けることで、緊急時のキャンセル猶予を持たせる。
  3. Deployment Branches: 特定のブランチ（例: main, release/*）からのみデプロイを許可する。

4. 監視と監査：StepSecurity Harden Runnerの活用

標準のログだけでは見えない、ビルド中の「振る舞い」を監視することも重要です。

StepSecurity Harden Runner

StepSecurity Harden Runner は、GitHub Actionsランナーにエージェントとして導入され、以下のセキュリティ機能を提供します。

5. Runnerのセキュリティ（Self-Hosted vs Ephemeral）

Self-Hosted Runnerを利用する場合は、Ephemeral（短命・使い捨て） な構成にすることが2026年の鉄則です。
永続的なVMをRunnerとして使い回すと、前のジョブによるディスク上の残留データが次のジョブに悪影響を与えたり、攻撃者がRunnerに永続化（Persistence）するリスクがあります。
AWSやKubernetes上でコントローラーを用いて、ジョブごとに新しいVM/Podを起動し、終了後は破棄する構成を採用しましょう。

おわりに

GitHub Actionsのセキュリティ対策は、一度設定すれば終わりではありません。常に最新の脅威とベストプラクティスに目を向け、継続的に改善していくことが重要です。本記事で紹介した対策を参考に、皆様のプロジェクトをサプライチェーン攻撃から守り、安全なCI/CDパイプラインを構築してください。

まずは小規模なワークフローからOIDCの導入を試したり、Dependabotを有効にするといったスモールスタートから始めることをお勧めします。

関連記事

https://zenn.dev/shineos/articles/github-actions-cicd-patterns
https://zenn.dev/shineos/articles/cloud-security-basics-small-team

本記事ではGitHub Actionsの基本的なセキュリティ対策に焦点を当てましたが、より高度なガバナンス設計や、複数のリポジトリ・組織を横断するセキュリティポリシーの適用については、Shineos Tech BlogのPart 2記事で詳しく解説します。乞うご期待ください！
https://blog.shineos.com

Discussion