GitHub Actionsで構築するAIエージェント向けDevSecOps：プロンプト注入からシークレット漏洩まで4段階パイプライン設計

AIエージェント開発におけるDevSecOpsの新たな課題：なぜ従来のCI/CDでは不十分なのか

自律型AIエージェントは、従来のWebアプリケーションとは根本的に異なる攻撃面を持つ。コードの静的な解析だけでなく、実行時に外部APIやツールを動的に呼び出すため、ランタイムでの振る舞いそのものがセキュリティの要となる。従来のCI/CDパイプラインが想定する検知対象——ソースコードの静的解析、依存関係の脆弱性スキャン、ユニットテストの実行——では、エージェント特有のリスクを十分にカバーできない。

従来のCI/CDでは検知できない3つのギャップ

第一に、シークレット混入のリスクである。自律型エージェントのデプロイでは、APIキーやMCP認証トークンなどのシークレットがソースコードに混入する可能性がある（Enterprise AI Agents向けDevSecOpsパイプライン設計）。従来のSASTツールはコードの構造を解析するが、プロンプトテンプレート内に埋め込まれた認証情報や、動的に組み立てられる設定ファイルへの対応は限定的だ。

第二に、プロンプトインジェクション（OWASP LLM01）や過度な権限付与（OWASP LLM05）といったLLM特有の脆弱性である。これらはコードの構文や型では検知できず、エージェントの「意図」や「行動」に対してテストを実施する必要がある（同記事）。

第三に、動的なツール呼び出しロジックの検証である。エージェントが実行時にどのツールをどの引数で呼び出すかは入力依存で変化するため、静的なコードレビューでは攻撃経路を完全に把握できない。入力空間が自然言語である以上、テストケースの設計自体が従来の単体テストとは異なる思考を要する。

本記事の位置づけ

本記事では、これらの課題をGitHub Actions上で自動化する4段階のDevSecOpsパイプライン設計を解説する。各ステージの役割、使用するツール、判断基準、そしてトレードオフを具体的に提示し、実装の判断材料とする。対象読者は、AIエージェントのCI/CDパイプライン構築とセキュリティ対策を担当するシニアエンジニアおよび技術責任者である。

全体アーキテクチャ：4段階の防御ラインとGitHub Actionsでの実装方針

パイプライン全体を4つのステージに分割する設計思想は、「早期停止によるフィードバック速度の最大化」と「最終関門の厳格さ」の両立にある。各ステージが独立した防御ラインとして機能し、いずれか一箇所でも失敗すればデプロイをブロックする。

各ステージの役割と実行順序

Stage 1（シークレット検知）とStage 2（プロンプト検証）は、変更差分に対する高速な反応を重視する。push直後に数分以内に結果を返すことで、開発者が次のコミットを書く前に問題を認識できるようにする。Stage 3（依存関係検査）は変更されたパッケージマニフェストに対してのみ実行し、差分がない場合はスキップする。Stage 4（静的解析）は本番同等の厳格なスキャンとして最終関門に配置し、ここを通過した時点でデプロイ可能と判断する。

GitHub Actionsでの実装では、各ステージを独立したjobとして定義し、needs で依存関係を明示する。Stage 1とStage 2は並列実行にし、Stage 3とStage 4はそれらに続く。環境変数やAPIキーはGitHub Secretsから注入し、ジョブのoutputには機微情報を含めない。各ステージの失敗時対応も設計時に決める：Stage 1の失敗は即ブロック、Stage 2は警告とブロックの二層構造、Stage 3はCVEの重大度に応じてブロック、Stage 4はCVSS閾値超過時のみブロック——というように、ステージごとに失敗の重みを変えて開発者の負担を最小化する。

flowchart LR
    A["Push / PR"] --> B["Stage 1: シークレット検知 (Gitleaks)"]
    B --> C["Stage 2: プロンプト検証 (Giskard)"]
    C --> D["Stage 3: 依存関係検査 (Dependabot/Snyk等)"]
    D --> E["Stage 4: 静的解析 (SonarQube等)"]
    E --> F["デプロイ"]
    B -->|失敗| G["パイプライン停止"]
    C -->|失敗| G
    D -->|失敗| G
    E -->|失敗| G

判断基準の設計原則

各ステージで「失敗」と判定する閾値は、検知コストと誤検知率のバランスで決める。Stage 1は高エントロピー文字列の出現だけで失敗とする（誤検知は低い）。Stage 2は注入テストの成功率で判定するが、テストケース数が限られるため警告とブロックの二層構造を採用する。Stage 4はCVSSスコアで閾値を設け、既存の既知欠陥はベースラインで除外する。このようにステージごとに判定ロジックを分けることで、開発者が「どのステージで何を修正すべきか」を即座に判断できるようにする。

Stage 1: レポジトリの即時防御——シークレット混入の検知と防止

Stage 1は、レポジトリに機微情報が混入する前にパイプラインを停止させる即時防御層である。GitleaksやTruffleHogを用い、git diffおよびコミット履歴から高エントロピーな文字列を検知し、検知された場合はパイプラインを即座に失敗させる（Enterprise AI Agents向けDevSecOpsパイプライン設計）。

エージェント開発におけるシークレット混入の特殊性

自律型エージェントのデプロイでは、APIキーやMCP認証トークンなどのシークレットがソースコードに混入するリスクが特に高い（同記事）。エージェントの設定ファイルやプロンプトテンプレートに認証情報をハードコードしてしまうケースは少なくない。従来のSASTツールはコードの構造を解析するが、自然言語で書かれたプロンプト内に埋め込まれたキーや、YAML/JSONの設定ファイルで動的に参照されるトークンへの対応は限定的だ。

ここで設計上の判断が一つある。Gitleaksは正規表現ベースのパターンマッチングで、既知のキー形式（AWS、OpenAI、GitHubトークン等）にマッチする。TruffleHogはエントロピー解析と検証リクエストの両方を行う。エージェント開発では、MCPサーバーの認証トークンや内部APIのキーのように、既知パターンにマッチしない形式のシークレットも存在するため、両方を併用し、TruffleHogの検証リクエストで「実際に有効なトークンか」まで確認する設計が堅牢である。

Push ProtectionとBypass権限の活用

GitHubのPush Protection機能は、リポジトリへのpush時にシークレットを検知し、検知された場合はpush自体を拒否する（GitHub公式ドキュメント）。CIパイプラインのStage 1と併用することで、ローカルpush時点とCI実行時点の二重防御を構成できる。

ただし、誤検知が発生した場合や、意図的にテスト用のダミーキーをコミットする必要がある場合など、Bypass権限を付与した信頼できるアクターによる除外制御が求められる。Bypass権限の付与範囲を最小限に絞り、誰がいつバイパスしたかを監査ログで記録しておくことが重要だ。権限を広く付与すると、かえってセキュリティホールになる。

ローカルフックとの連携でCIリソースを節約する

CIサーバーのリソース消費を抑えるため、開発者のローカル環境にもプレコミットフックとしてGitleaksを配置する。ローカルで検知された場合はコミット前に修正を促し、CI側ではマージリクエストの差分に対してのみスキャンを実行する。これにより、フル履歴スキャンの頻度を下げつつ、マージ時の最終チェックを確保する。

name: devsecops-stage1
on:
  pull_request:
    branches: [main]

jobs:
  secret-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0   # 履歴スキャンのため全履歴を取得
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}

fetch-depth: 0 で全履歴を取得することで、過去のコミットに混入したシークレットも検知対象にする。ただし、レポジトリの規模が大きい場合は履歴スキャンに時間がかかるため、差分スキャン（fetch-depth: 1）に切り替えてもよい。この判断は、レポジトリのコミット頻度と履歴の長さに基づいて行う。

Stage 2: ロジックとプロンプトの検証——LLM特有の脆弱性への対応

Stage 2では、AIエージェントの「振る舞い」の安全性を検証する。従来のCI/CDがコードの構文や型安全性を検証するのに対し、エージェントではプロンプトテンプレートや動的なツール呼び出しロジック自体が攻撃面となる。OWASP LLM01（Prompt Injection）やOWASP LLM05（Excessive Agency）といった脆弱性が、エンタープライズ環境での主要な攻撃ベクトルとして報告されている（Architecting a Resilient DevSecOps Pipeline for Enterprise AI Agents）。

プロンプト注入テストの実施方法

具体的には、LLMによるコードレビューと併せて、Giskardなどのツールを用いてプロンプトテンプレートの注入テストを実施する。テストの設計思想は「敵対的入力を与えたとき、エージェントが意図しない外部システムにアクセスしないか」を確認することにある。例えば、ユーザー入力に埋め込まれた指示語が、エージェントのツール呼び出し権限を上書きできるかを検証する。

ここで重要な設計判断は、テスト対象の絞り込みである。プロンプトテンプレートは複数存在する場合が多く、すべてのテンプレートに対して全注入パターンを実行すると計算コストが指数関数的に増加する。現実的なアプローチは、外部APIを呼び出すエントリポイントや、ユーザー入力が直接プロンプトに組み込まれる箇所を優先対象として設定することだ。

また、プロンプトテンプレートの変更履歴を追跡することも有効である。テンプレートの変更が意図しない出力パターンを生み出していないか、差分ベースで影響範囲を評価することで、回帰テストの範囲を制御できる。

このステージの失敗時対応としては、注入テストで脆弱性が検知された場合、単にパイプラインを停止するだけでなく、どのテンプレートのどの変数代入箇所が攻撃に成功したかをレポートに含めることが重要である。これにより、開発者が修正箇所を特定するコストを下げられる。

Stage 3: 依存関係の可視化——SCA AgentによるSBOMとCVEの相関

AIエージェントは外部APIやツールを呼び出す設計上、多数のサードパーティライブラリに依存する。Stage 3では、これらの依存関係に存在する既知の脆弱性を早期に検知し、サプライチェーン攻撃への備えとする。

Veracode Agent-Based SCAは、GitHub Actionsのrunner環境内でパッケージマニフェストを直接検査し、SBOM（Software Bill of Materials）を生成すると同時にCVEデータベースと相関させることが可能である（Architecting a Resilient DevSecOps Pipeline for Enterprise AI Agents）。従来の「SBOMを別途生成して照合する」2ステップ構成とは異なり、スキャンと相関が単一プロセスで完結するため、パイプライン全体の所要時間を短縮できる可能性がある。

セキュリティポリシーとの連携

単に脆弱性を列挙するだけでは、開発チームが「どのレベルのCVEを許容するか」の判断を毎回行う必要がある。Veracode Platformでは、アプリケーションプロファイルやSCAワークスペースにセキュリティポリシーを割り当ててコンプライアンスを評価する仕組みが用意されている（Manage security policies | Veracode Docs）。

ここで注意すべき実装上の制約として、SCA Agentのスキャン結果でポリシー違反を正確に確認するには、プロジェクトをアプリケーションプロファイルにリンクしておく必要がある（Manage security policies | Veracode Docs）。このリンク設定が未実施の場合、スキャン自体は実行されるが、ポリシー判定の結果が反映されないため、パイプラインのゲートとして機能しない。初期設定時にこのリンクを忘れることが最も多い失敗パターンであり、ワークフローの初回実行前に確認すべきチェック項目として位置づけるべきである。

エージェント開発における依存関係の特殊性として、LLMフレームワークやMCP（Model Context Protocol）関連のパッケージは更新頻度が高く、新バージョンのリリースとCVEの公開の間に時間差が生じやすい。このため、Stage 3のスキャン頻度をPRごとに設定するだけでなく、定時スキャン（例えば毎日）を併用して、マージ後に新規CVEが公開された依存パッケージをキャッチする設計が望ましい。

Stage 4: 厳格な静的解析——Pipeline Scanによる最終関門の設計

Stage 4はパイプラインの最終関門として、Veracode Pipeline Scanを用いた厳格な静的解析を行う。Pipeline ScanはStatic Analysis Engineにパッケージ化されたアーティファクトをアップロードして解析を実行する（Veracode Pipeline Scan | Veracode Docs）。

閾値設計とベースライン管理

スキャンは90秒以内に完了し、CVSSスコア7.0以上の欠陥が検出された場合のみパイプラインを失敗させる（Architecting a Resilient DevSecOps Pipeline for Enterprise AI Agents）。CVSS 7.0という閾値は、CriticalとHighの境界付近に設定されており、中程度の脆弱性（CVSS 4.0〜6.9）はパイプラインを止めずにチケット化して後日修正する、という開発速度と安全性のバランスを考慮した判断である。

スキャン結果はデフォルトでresults.jsonに保存される。このファイルをベースラインとして利用することで、前回スキャンで既に報告済みの欠陥を除外し、新規発見のみをパイプラインの失敗条件にできる（Veracode Pipeline Scan | Veracode Docs）。レガシーコードを含むプロジェクトでは、このベースライン方式が不可欠であり、既存の数百件の脆弱性を一度に修正する現実的な負担を回避できる。

実行環境の制約

Pipeline Scanの実行にはJava 8以降のランタイムが必要であり、APIアクセスにはHTTPSポート443への到達性と、IPアドレスのホワイトリスト登録が必須である（Veracode Pipeline Scan | Veracode Docs）。GitHub Actionsのホストランナーではポート443が既定で開放されているため問題ないが、セルフホストドランナーやオンプレミスのビルド環境で利用する場合は、ファイアウォール設定とIPホワイトリストの両方を事前に確認する必要がある。

ベースラインファイルの管理方針としては、results.jsonをGitHub ActionsのArtifactとして保存すると同時に、レポジトリ内の特定ディレクトリにコミットしてバージョン管理下に置く二重管理が有効である。Artifactは一定期間で自動削除されるため、長期的なトレンド分析にはレポジトリ内のコピーが参照源となる。ただし、results.jsonには脆弱性の詳細情報（ファイルパス・行番号）が含まれるため、レポジトリの公開範囲と整合させる必要がある。

トレードオフと設計判断：速度 versus 安全性のバランス

4段階パイプラインの設計において、最も頻繁に直面する判断軸は「開発速度」と「検知の網羅性」のトレードオフである。各ステージで何を許容し、どこで厳格にするかを明確にしないと、パイプライン自体が開発のボトルネックに転じる。

Stage 4のスキャン時間とアーティファクト範囲

Veracode Pipeline Scanは90秒以内に完了するが、これはパッケージ化されたアーティファクトのサイズに依存する。モノレポで数百のモジュールを含むプロジェクトでは、全アーティファクトをアップロードするとスキャン時間が想定を超え、CIタイムアウトに抵触する可能性がある。対策として、変更されたモジュールのアーティファクトのみをアップロードする差分スキャン、あるいは複数ジョブに分割して並列実行する方式が考えられる。前者は検知範囲が狭くなるリスクを持ち、後者はランナーのコスト増と引き換えに速度を維持できる。プロジェクトの規模と変更頻度に応じて選択すべきである。

Stage 2の計算コストと対象範囲

プロンプト注入テストはLLMへのAPI呼び出しを伴うため、1回あたりの実行コストがStage 1や3に比べて桁違いに高い。すべてのプロンプトテンプレートに対して全テストケースを実行すると、パイプライン全体の実行時間が数倍に膨らむ。現実的な方針は、外部入力を受け取るエントリポイントとなるプロンプトテンプレートのみを対象に絞り、内部処理用のテンプレートはステージ4の静的解析に委ねるという階層化である。これにより、攻撃面が最も広い箇所を集中的に検証しつつ、全体のCI時間を抑制できる。

Push ProtectionとBypass権限の管理

GitHubのPush Protectionはシークレットのプッシュを即座にブロックする強力な仕組みだが、Bypass権限を持つアクターはこれを無視してプッシュできる。この権限を広範囲に付与すると、意図せずシークレットがレポジトリに混入する経路が残る。Bypass権限はセキュリティチームの少数メンバーに限定し、その使用は監査ログで追跡する運用が不可欠である。

上記の閾値や対象範囲は、プロジェクトのリスクプロファイルに応じて調整すべきである。特にCVSS 7.0という失敗閾値は、High严重度以上の脆弱性が本番環境に到達することを許容しないという設計判断に基づく。社内規程や業界コンプライアンス要件が異なる場合は、この値を再検討する必要がある。

実装ステップ：GitHub Actionsワークフローの構成例

以下は4段階パイプラインをGitHub Actionsで定義するワークフローファイルの構成例である。各ステージを独立したジョブとして定義し、依存関係で実行順序を制御する。シークレットはGitHub Secretsに格納し、ジョブ実行時に環境変数として注入する。

# 構造例：実際のツールコマンドは各製品の公式ドキュメントを参照
# ※ 本例はパイプラインの構造とジョブ間の依存関係を示すもの

name: ai-agent-devsecops
on:
  push:
    branches: [main]
  pull_request:

jobs:
  # Stage 1: シークレット検知
  secret-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # 全履歴を取得（コミット履歴スキャン用）

      - name: Gitleaks scan
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  # Stage 2: プロンプト検証（Stage 1の成功後に実行）
  prompt-validation:
    runs-on: ubuntu-latest
    needs: secret-scan
    steps:
      - uses: actions/checkout@v4
      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - name: Run prompt injection tests
        # Giskard等のツールでプロンプトテンプレートを検証
        # 対象は外部入力を受けるエントリポイントのみ
        run: |
          pip install -r requirements-dev.txt
          python tests/prompt_injection/test_injection.py \
            --target prompts/entry_points/ \
            --fail-on-high

  # Stage 3: 依存関係検査（Stage 1の成功後に実行）
  sca-scan:
    runs-on: ubuntu-latest
    needs: secret-scan
    steps:
      - uses: actions/checkout@v4
      - name: Run SCA Agent scan
        # Veracode Agent-Based SCAでパッケージマニフェストを検査
        # SBOMとCVEを相関させ、ポリシー違反を検知
        env:
          VERACODE_API_KEY: ${{ secrets.VERACODE_API_KEY }}
          VERACODE_API_SECRET: ${{ secrets.VERACODE_API_SECRET }}
        run: |
          # Veracode CLIでSCA Agentスキャンを実行
          # 詳細なコマンドはVeracode公式ドキュメントを参照
          echo "Run SCA Agent scan and check policy compliance"

  # Stage 4: 厳格な静的解析（Stage 2, 3の成功後に実行）
  pipeline-scan:
    runs-on: ubuntu-latest
    needs: [prompt-validation, sca-scan]
    steps:
      - uses: actions/checkout@v4
      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          java-version: '17'  # Java 8以降が必要
          distribution: 'temurin'
      - name: Package artifact
        run: |
          # 解析対象のアーティファクトをパッケージ化
          echo "Package application artifact for static analysis"
      - name: Run Pipeline Scan
        env:
          VERACODE_API_KEY: ${{ secrets.VERACODE_API_KEY }}
          VERACODE_API_SECRET: ${{ secrets.VERACODE_API_SECRET }}
        run: |
          # Static Analysis Engineにアーティファクトをアップロード
          # CVSS 7.0以上でパイプラインを失敗させる
          echo "Upload artifact and run static analysis"
      - name: Save results as baseline
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: pipeline-scan-results
          path: results.json
          retention-days: 30

この構成で重要な設計判断は、Stage 2とStage 3をStage 1の成功後に並列実行し、Stage 4をその両方の成功後に実行する点である。Stage 1でシークレット混入が検知された場合、以降のステージは実行されないため、LLM API呼び出しやSCAスキャンのリソース消費を回避できる。Stage 2と3の間に依存関係がないため、両方を並列で実行すればパイプライン全体の所要時間を短縮できる。

results.jsonの管理については、前節で述べたArtifactとレポジトリ内コピーの二重管理を適用する。Artifactは短期間のデバッグや参照に、レポジトリ内のコピーは長期トレンド分析に使用するという役割分担を明確にしておくことで、運用時の混乱を防げる。

運用と継続的改善：パイプラインの監視とポリシーの更新

パイプラインの構築が完了しても、それは運用の始まりに過ぎない。AIエージェントの脅威モデルは急速に変化するため、定期的な見直しと改善サイクルを確立することが重要である。

スキャン結果のトレンド分析

各ステージの検知結果を時系列で可視化し、以下の指標を週次または月次で確認する。新規脆弱性の発生件数、既存脆弱性の修正に要する平均日数、Stage 2のプロンプト注入テストの失敗率の推移である。特にStage 4のresults.jsonをベースラインとして利用する場合は、ベースラインからの差分（新規発見）の増加傾向を監視し、特定のライブラリやモジュールに脆弱性が集中していないかを確認する。集中が見られる場合は、そのライブラリのアップグレードや代替手段の検討を優先的に進めるべきである。

脅威モデルの更新とテストケースの追加

OWASP Top 10 for LLMsのような業界標準の脆弱性カタログは、AI技術の進化に伴って更新される。新種の攻撃手法が追加された場合、Stage 2のプロンプト注入テストケースにそれに対応するシナリオを追加する必要がある。具体的には、新種のインジェクションパターンを検知するためのテストプロンプトを設計し、既存のテストスイートに組み込む。この作業はセキュリティチームとAI開発チームが協働して行うべきであり、片方だけの視点ではテストケースの網羅性が不足する。

ポリシーとコンプライアンスの整合性確認

Veracode PlatformではアプリケーションプロファイルやSCAワークスペースにセキュリティポリシーを割り当ててコンプライアンスを評価する仕組みがある。新しいライブラリを追加した際や、社内セキュリティ規程が変更された際は、これらのポリシー設定を再確認する必要がある。特にSCA Agentスキャン結果でポリシー違反を確認するには、プロジェクトをアプリケーションプロファイルにリンクしておくことが前提となるため、新規プロジェクトの立ち上げ時にこのリンク設定を忘れないようチェックリストに含めておくことが有効である。

パイプラインの失敗原因を分析する際は、「真の脆弱性」「誤検知」「環境要因」の3分類で集計する。誤検知が一定割合を超えている場合は、Stage 1のGitleaks設定やStage 4のCVSS閾値を見直し、開発者のデプロイ頻度が低下していないかを確認する。セキュリティパイプラインの最終目的は、安全なデプロイを妨げることではなく、安全なデプロイを可能にすることである。

まとめ：AIエージェント開発におけるDevSecOpsの未来像

自律型AIエージェントの開発では、従来のWebアプリケーションのCI/CDでは捉えきれない攻撃面が存在する。APIキーやMCP認証トークンなどのシークレットがソースコードに混入するリスク、プロンプトインジェクションや過度な権限付与といったLLM固有の脆弱性、そしてエージェントが呼び出す外部ツールやAPIを通じたサプライチェーン攻撃。これらのリスクは、単一のツールや単一のチェックポイントでは防げない。

本記事で提示した4段階パイプラインは、これらのリスクを「検知のタイミング」と「検知のコスト」の両面から階層化して対処する設計である。Stage 1で即座に低コストなフィルタリングを行い、Stage 2でAI固有の振る舞いを検証し、Stage 3で依存関係の健全性を確認し、Stage 4で最終関門として厳格な解析を行う。各ステージの閾値や対象範囲は、プロジェクトのリスクプロファイルに応じて調整可能な設計にしている。

今後の展望としては、Stage 2のプロンプト注入テストの自動化精度が向上し、CI実行コストがさらに低下することが期待される。また、SBOMとCVEの相関分析がよりリアルタイム化すれば、Stage 3とStage 4の境界が曖昧になり、統合的な脆弱性評価が可能になる可能性もある。いずれにせよ、AIエージェントのセキュリティは「一度構築して終わり」のものではなく、脅威モデルの変化に追従して継続的に改善していくべき対象である。

関連記事

• GitHub Actionsで始めるCI/CD入門！簡単な自動テストパイプライン構築
• npm/Pythonのサプライチェーン攻撃を防ぐ！開発者が今すぐできるセキュリティ対策
• コンテナセキュリティ入門：イメージスキャンからランタイム保護まで

参考

本記事は海外の技術トレンド「Architecting a Resilient DevSecOps Pipeline for Enterprise AI Agents」（DEV）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。