🛡️ Google Cloud の自律SDLCセキュリティ — AIで脆弱性を発見・検証・修正する閉ループ設計

調査対象: Google Cloud Security が社内で AI をどう使い、「自律的なソフトウェア開発ライフサイクル (autonomous SDLC) セキュリティ」へどう近づいているか。
一次情報: Cloud CISO Perspectives: How Google Cloud Security uses AI internally (Google Cloud Blog, 2026-06-30)

概要

Google Cloud Security チームは、社内で実用化した AI セキュリティ基盤を「自律 SDLC セキュリティ (Autonomous SDLC Security)」として公開しました。中心的な主張は、ソフトウェア開発ライフサイクル全体のセキュリティを human-dependent checklists から proactive multi-agent orchestration へ 転換するというパラダイムシフトです。

従来の静的チェックや単発の AI 自動化では、脅威の検出・修正・知見の蓄積が断片化し、同じ脆弱性が繰り返し生まれる問題を防げませんでした。自律 SDLC セキュリティは、設計からデプロイ後の姿勢管理までを 閉じたループ (closed loop) として設計し、エージェントが自己反省 (self-reflection) を通じて知見を蓄積することで「複利効果 (compounding-interest effect)」を生み出します。

長期ビジョンは "immune" software development です。アプリケーションが自らの弱点をリアルタイムに発見・検証・修正できる状態を指します。Google は、AI が脆弱性悪用の経済性を覆し、従来の patching window を実質的に消したと述べ、これに機械速度で対抗する基盤として自律 SDLC セキュリティを位置づけています。

自律 SDLC セキュリティの 5 ステージ閉ループ

特徴

• 5 ステージ閉ループ: 設計レビューからコードスキャン、動的テスト、パッチ生成、姿勢管理までを単一の closed-loop として設計し、工程間の断絶を排除します。
• multi-agent orchestration: Strategist・Research・Deduplicator・Critic・Reproduction・Hallucination Cleaner・Reflection など役割特化エージェントを組み合わせ、単一 LLM では届かない精度と規模を実現します。
• Self-Reflection による状態蓄積: Reflection Agent が実行ログ・ツール履歴・人間フィードバックを解析し、成功パターンを Global Knowledge Store に永続化します。次回のエージェント起動時にコンテキストウィンドウへ注入し「複利効果」を生みます。
• stateless 失敗モードの克服: 状態を持たない AI は同じ論理的罠に繰り返し陥り、存在しないコードを幻覚します。post-hoc self-reflection loop がこの失敗モードに対処します。
• "immune software development" ビジョン: アプリケーションが自らの弱点をリアルタイムに発見・検証・修正できる状態を最終目標に掲げます。
• machine-speed threat response: 従来の週から月単位の patching window を実質的に消し、脅威を悪用前に検出・修正する速度を目指します。
• Mantis の 85% トークン削減: 階層的セキュリティサマリツリーにより、大規模リポジトリのスキャンコストを大幅に抑制します。
• Reproduction Sandbox: AI 生成の PoC エクスプロイトを隔離環境で実行し、悪用可能性を事実として確認してからパッチ生成へ進みます。
• 人間を排除しない設計: 高リスク指標と最終パッチ展開には人間の承認を残し、エージェントは検証済みの fix のみ人間レビューへ提出します。
• 産業規模へのスケール: 人員数に依存しないスケーラビリティを設計原則とします。

関連技術・系譜との関係

注: Mantis は起点ブログ本文の中核です。CodeMender・VPC Service Controls・GTIG・Confidential Computing は起点ブログと同一ページ (本文または関連セクション) で言及されています。Big Sleep・DARPA AIxCC・従来ツール群はこのブログには直接登場せず、系譜・位置づけを示すための外部補完情報です。

従来手法との比較

構造

C4 モデルを「提案フレームワークの論理構造」として読み替えて記述します (方法論を対象とするため)。

システムコンテキスト図

コンテナ図

コンポーネント図

Mantis コードスキャン

Self-Healing Fuzz Testing

Unified AI Patching Pipeline

ASPM 姿勢管理

Reflection Agent と Global Knowledge Store

閉ループのデータフロー / 制御フロー

データ

概念モデル

エンティティの所有関係を subgraph で、利用・生成関係を矢印で示します。

情報モデル

主要エンティティの属性と多重度を示します。ブログに明示のない属性は注記で補足します。

エンティティ説明

標準データモデルとの対応

構築方法

自律 SDLC セキュリティを自社で検証・再現する出発点としては、Google が OSS 公開している Mantis Skills が使えます (README は "demonstration purposes only" と明記しており、そのままの本番導入は想定されていません)。Mantis Skills はコードスキャン・PoC 再現・パッチ生成などの中核スキルを実装しています。残りのステージ (設計ゲート・ASPM) は既存ツールや CI/CD パイプラインと組み合わせて構成します。

以降のコード例は、一次ブログの設計思想を自社環境で再現するための 実装案 です。Mantis のスキル名・状態ファイル名は github.com/google/mantis の README で確認済みですが、コーディングエージェントへの組み込み方法は利用するエージェント (Gemini CLI / Claude Code 等) の仕様に従って調整してください。

Mantis Skills の取得

Mantis Skills は「Portable Toolkit for Building Security Review Harnesses」として GitHub に公開された、Coding Agent 向けのセキュリティレビュー用 Skills 群です。

• リポジトリ: https://github.com/google/mantis (Apache-2.0)
• 構成: README は中核パイプラインを "ten distinct components (one supervisor and nine execution stages)" と定義します。これに前処理・補助スキル (/mantis_history・/mantis_summarize・/mantis_chain・/mantis_calibrate・/mantis_pipeline_adapter) を含め、リポジトリには計 16 個の SKILL.md モジュールがあります。/mantis_meta_agent (スーパーバイザ) が継続レビューループを統括します
• 公開範囲: ブログは「core skills を OSS 公開、より完全な版を社内運用」と述べています
• 注意: README は "not an officially supported Google product"、"USE AT YOUR OWN RISK"、そして "intended for demonstration purposes only. It is not intended for use in a production environment." と明記しています。本番相当の利用には自社での大幅な追加ハードニングと検証が前提です

# Mantis Skills を取得 (実装案)
# 参考: https://github.com/google/mantis README
git clone https://github.com/google/mantis
# 各 mantis_* ディレクトリの SKILL.md を、利用するコーディングエージェントが
# スキルとして発見できる場所に配置する (配置方法はエージェント仕様に従う)

前提条件

作業ディレクトリ構造

Mantis のスキル群は、スキャン対象リポジトリ配下に状態ファイル群を読み書きします (README で確認)。

<target-repo>/
├── workspace/
│   ├── findings/   # finding ごとの JSON (workspace/findings/<id>.json)
│   └── kb/         # Markdown ナレッジベース (THREAT_MODEL.md 等。architecture / threat_model が生成)
├── <dir>/mantis_summary.md   # ディレクトリ別サマリ (mantis_summarize が生成)
├── plan.json                 # 調査計画 (mantis_plan が生成)
├── learnings.jsonl           # Reflection / Critic / Patch が追記、architecture が次ループ開始時にクリア
└── historical_learnings.jsonl # mantis_history が VCS 履歴から抽出

後続の利用方法 YAML 例に出てくる threat_model.json / patch.json / reproduce.json / calibrate.json などのファイル名は、CI に組み込む際の 実装案の例示 です。Mantis 本体の finding は workspace/findings/<id>.json 単位で管理され、脅威モデルは workspace/kb/THREAT_MODEL.md に出力されます (README)。

Mantis スキルパイプラインの全体像

README の Architecture によると、パイプラインは /mantis_meta_agent (スーパーバイザ) が統括し、以下のステージが状態ファイルを介して順次連携します。Pat から Rep への「Re-attack Bypass Loop」、Ref から Arch への「Next Loop Iteration」で継続学習ループを構成します。

隔離サンドボックス環境の要件 (実装案)

自律実行を本番相当の環境で動かす場合、README が求める隔離要件を満たす構成例を示します。

GCE ハードニング VM 構成 (実装案)
├── ネットワーク分離
│   ├── VPC Service Controls ペリメータ設定
│   ├── 外部インターネット接続を禁止
│   └── 信頼済みプロキシ経由のみ許可
├── IAM 最小権限
│   ├── カスタムロール: モデル推論に必要な権限のみ付与
│   └── 専用サービスアカウントによる実行
└── ストレージ
    └── GCS バケット: 追記専用 (append-only) + バージョニング有効

利用方法

各ステージの具体的な実装案を示します。コード例は実装案であり、一次ブログに存在しない実装詳細は補完元 (Mantis README / OSS 公式) を出典として明示します。

ステージ 1: 設計ゲート (GitHub Actions 例)

ブログの説明: エージェントが設計を 200+ のセキュリティ要件カタログと照合し、静的な脅威モデルを動的な product dossier に置換します。

実装案として、PR 作成時に設計ドキュメントと脅威モデルの差分を AI エージェントでレビューし、要件カタログと照合するゲートを CI に組み込みます。

# .github/workflows/security-design-gate.yml (実装案)
# 参考: GitHub Actions 公式ドキュメント https://docs.github.com/en/actions
name: Security Design Gate
on:
  pull_request:
    paths:
      - 'docs/design/**'
      - 'docs/threat-model/**'
      - 'src/**'
jobs:
  design-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run threat model skill (coding agent)
        env:
          GOOGLE_APPLICATION_CREDENTIALS: ${{ secrets.GCP_SA_KEY }}
        run: |
          # コーディングエージェントから /mantis_threat_model スキルを実行する
          ./scripts/run-agent-skill.sh mantis_threat_model
      - name: Check findings against requirements catalog
        run: |
          python3 scripts/check_requirements.py \
            --findings workspace/findings/threat_model.json \
            --catalog docs/security-requirements.json \
            --fail-on critical,high
      - name: Upload SARIF report
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: workspace/findings/sarif_output.sarif

• security-requirements.json に 200 以上の要件を定義し、check_requirements.py が照合結果を SARIF 形式で出力する構成が実用的です。要件ファイルの最小スキーマ例 (実装案):

{
  "version": "1.0",
  "requirements": [
    {
      "id": "SR-001",
      "category": "Authentication",
      "risk_level": "critical",
      "description": "外部通信を行うコンポーネントは相互 TLS 認証を必須とする",
      "control_catalog_ref": "NIST SP 800-53 IA-3"
    }
  ]
}

• ゲート閾値 (--fail-on) は初期は critical のみにし、安定後に high へ引き上げることが推奨されます (参考: GitHub Advanced Security)

ステージ 2: コードスキャン (Mantis)

ブログの説明: Mantis がトークンオーバーヘッドを 85% 超削減しながら大規模リポジトリ全体の構造コンテキストを保持します。素朴な AI コードスキャンの true-positive rate が 7% 未満という問題に対処します。

実装案として、ターゲットリポジトリに対して Mantis のコアスキャンパイプラインを順次実行します。

# コーディングエージェントから Mantis スキルを順次実行する (実装案)
# 参考: https://github.com/google/mantis README

cd <target-repo>

# Phase 1: ナレッジベース構築
#   /mantis_history     (任意・VCS 履歴抽出)
#   /mantis_summarize   (任意・ディレクトリ別サマリ)
#   /mantis_architecture (workspace/kb/ 構築)

# Phase 2: 調査計画と実行
#   /mantis_threat_model
#   /mantis_plan
#   /mantis_researcher

# Phase 3: 偽陽性除去
#   /mantis_dedupe
#   /mantis_review
#   /mantis_critic

• Mantis は階層的なセキュリティサマリツリーを構築し、ブルートフォースなコード取り込みを排除します。これがトークン削減の核心メカニズムです (ブログ記載)
• /mantis_meta_agent をスーパーバイザとして使うと、上記ループの起動・監視・findings アーカイブを自動化できます (README 記載)

ステージ 3: 動的テスト (OSS-Fuzz-Gen による Fuzz Harness 自動生成)

ブログの説明: self-healing fuzz testing。AI 生成 PoC exploit を隔離環境で実行し実際の悪用可能性を検証します。

実装案として、Google の oss-fuzz-gen を使い、LLM で fuzz harness を自動生成して OSS-Fuzz インフラで実行します。

# oss-fuzz-gen のセットアップ (実装案)
# 参考: https://github.com/google/oss-fuzz-gen
git clone https://github.com/google/oss-fuzz-gen
cd oss-fuzz-gen
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

# Vertex AI 認証
gcloud auth application-default login
export CLOUD_ML_PROJECT_ID=<your-gcp-project>
export VERTEX_AI_LOCATIONS=us-central1

• OSS-Fuzz-Gen は Fuzz Introspector でカバレッジの低い関数を特定し、その関数をターゲットにした harness を LLM で生成します (公式ドキュメント記載)
• ビルドエラーが出た場合は別の LLM クエリで自動修正する反復修正ループを内蔵します
• Mantis 連携では /mantis_reproduce がサンドボックス内で PoC を実行し、/mantis_chain がマルチステップ exploit チェーンを構築します

ステージ 4: パッチ生成 (patch → regression → 人間レビュー)

ブログの説明: 脆弱性 finding を検証済みコード修正に変換する multi-stage pipeline。再コンパイル + テスト実行の regression loop 後、検証済み fix のみ人間レビューへ提出します。

実装案として、Mantis の /mantis_patch でパッチを生成し、/mantis_calibrate でリスクスコアを算出し、CI で regression を通過したものだけ PR として提出します。

# .github/workflows/security-patch-review.yml (実装案)
# 参考: GitHub Actions 公式ドキュメント
name: Security Patch Regression Check
on:
  pull_request:
    branches: [security/*]
jobs:
  regression-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build patched code
        run: make build
      - name: Run regression tests
        run: make test SUITE=regression
      - name: Verify vulnerability fix
        run: |
          python3 scripts/verify_patch.py \
            --findings workspace/findings/patch.json \
            --exploit workspace/findings/reproduce.json
      - name: Auto-label PR with risk score
        uses: actions/github-script@v7
        with:
          script: |
            const score = require('./workspace/findings/calibrate.json').risk_score;
            const label = score >= 8 ? 'security:critical' : score >= 5 ? 'security:high' : 'security:medium';
            github.rest.issues.addLabels({
              ...context.repo,
              issue_number: context.payload.pull_request.number,
              labels: [label]
            });

• 高リスクスコアの場合は自動的に Security チームへのレビュー依頼をトリガする運用が実用的です
• パッチの最終展開権限は人間レビュアーが保持します (ブログ記載の human-in-the-loop 設計)

ステージ 5: 姿勢管理 (ASPM 的な Config Drift 検知)

ブログの説明: 本番の config drift を継続チェックし、違反時に agentic remediation を自動トリガします。

実装案として、Open Policy Agent (OPA) や Conftest による設定検証を CI/CD + cron ジョブで継続実行し、違反検知時に修復スキルを起動します。

# .github/workflows/config-drift-detect.yml (実装案)
# 参考: OPA 公式ドキュメント https://www.openpolicyagent.org/docs/latest/
name: Config Drift Detection
on:
  schedule:
    - cron: '0 */6 * * *'
  push:
    paths:
      - 'infra/**'
      - 'k8s/**'
jobs:
  drift-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Conftest
        run: |
          curl -L https://github.com/open-policy-agent/conftest/releases/latest/download/conftest_Linux_x86_64.tar.gz | tar xz
          sudo mv conftest /usr/local/bin/
      - name: Check config against policy baseline
        id: drift
        run: |
          conftest test infra/ --policy policies/security/ --output json > drift_report.json
      - name: Trigger agentic remediation on violation
        if: steps.drift.outputs.violations != '0'
        run: |
          ./scripts/run-agent-skill.sh mantis_patch --input drift_report.json

• ASPM 専用ツール (Cycode / Wiz 等) との連携も選択肢です。これらはコード・クラウド間の追跡機能を備えます

Reflection agent と Global Knowledge Store の運用

ブログの説明: ワークフロー完了後に Reflection agent が実行ログ・ツール履歴・人間フィードバックを分析し、成功 trajectory を global knowledge store に永続化します (compounding-interest effect)。

Mantis では /mantis_reflect が trajectory を解析して learnings.jsonl に追記し、次ループ開始時に /mantis_architecture がこれを読み込みつつクリアします。この継続学習ループにより、エージェントが同じ論理的罠を繰り返すことを防ぎます。

運用

監視・可観測性の設計

• Reflection agent は各ワークフロー完了後に実行ログ・ツール履歴・人間フィードバックを分析します。リアルタイム監視ではなく事後分析 (post-hoc) が基本設計です。
• エージェントに非人間アイデンティティ (non-human identity) を割り当て、パッケージ取得・API コール・ツール呼び出しを監査ログへ記録します。
• ログは不変かつクエリ可能な形式で保存します。コンプライアンス証跡がエンジニアリングプロセスの副産物として自動生成されるよう設計します。
• 既存の observability スタックに AI エージェントのメトリクス (実行回数・失敗率・トークン消費量) を統合します。

人間レビュー gate の運用

• Gate は 3 層で設計します。
  1. 設計レビュー gate: 高リスク指標 (外部通信・権限昇格・暗号変更等) を自動 triage で人間エンジニアへエスカレーションします。
  2. パッチ提出 gate: 再コンパイル + テスト実行の regression loop を通過した fix のみ人間レビュアーへ提出します。
  3. 展開最終 gate: パッチ展開の最終承認権限を人間が保持します。
• gate の閾値 (high-risk 判定基準) はポリシーファイルで明文化し、バージョン管理します。
• progressive autonomy を採用します。低リスクシステムで修正提案のみの半自律から始め、一貫性を確認後に自動化範囲を拡大します。

知識ストアの保守

• 知識ストアにはバージョン管理と検証プロセスが必要です。誤った学習パターンが蓄積すると、全エージェントの挙動が一様に劣化します。
• 知識エントリの削除・修正権限を SecOps チームが保持し、定期キュレーションサイクル (例: 四半期レビュー) を設けます。
• 知識ストアへの注入は context 汚染を防ぐため、関連性スコアで上位 N 件に絞ります。

ASPM による config drift 監視

• 200 以上のセキュリティ要件カタログをプログラマブルなスキルファイルとして管理し、本番システムの config drift を継続チェックします。
• 違反検出時は agentic remediation を自動トリガします。修復試行ログを監査証跡として保存します。
• 違反ルールのオーナーシップ (チーム / サービス) を台帳で管理します。
• config drift の検出から修復確認までのサイクルタイムを SLO として定義します (例: Critical 違反は 4 時間以内)。

エージェント実行の観測

• 各エージェント起動に一意の実行 ID を付与し、使用ツール・呼び出し順序・入出力ハッシュを構造化ログとして記録します。
• Mantis の Strategist → Research → Deduplicator → Reviewer → Critic の各エージェント間で実行トレースを連結し、finding の来歴を再現可能にします。
• Hallucination Cleaner agent が介入した箇所をログに記録し、幻覚の傾向をトラッキングします。

ベストプラクティス

human-in-the-loop 境界の設計

• 自律化の対象を限定します: 定型的な修正 (既知 CVE の既存パッチ適用・設定値修正) は自律化候補です。複雑なアーキテクチャ変更・ビジネスロジック変更は人間判断を必須とします。
• エスカレーション基準を事前定義します: 高リスク指標 (外部 API 通信変更・認証フロー変更・暗号アルゴリズム変更) はポリシーで明示します。
• 「検証済み fix のみレビューへ」を厳守します: パッチが regression loop を通過した証拠 (テスト結果ログ) をレビュー UI に表示します。

false positive 抑制

• 素朴な AI コードスキャンの true-positive rate は 7% 未満です (一次ブログ)。単体の LLM スキャンを本番アラートに直結させません。
• Mantis の多段フィルタリングを参考にパイプラインを構成します。
  1. Deduplicator agent で重複 finding を除去します。
  2. Reviewer + Critic agents で文脈を考慮した false positive 除去を行います。
  3. Reproduction sandbox で AI 生成 PoC を隔離環境で実行し、実際の悪用可能性を確認してからアラート発報します。
• LLM を SAST の後段フィルタとして使う手法が実証されています (Datadog)。CWE マッピングと周辺コードを LLM に評価させ、true/false positive を判定します。

stateless 失敗モード対策 (self-reflection)

• stateless AI は同じ論理的罠に繰り返し陥り、特に存在しないコードを修正しようとする幻覚が起きやすいです。
• 対策として self-reflection ループを導入します。ワークフロー完了後に実行ログを分析し、失敗 trajectory を次回起動時の context に注入します。
• リアルタイムのフィードバックループも有効です。コンパイラ・リンカエラーを即時 Hallucination Cleaner agent へフィードし、幻覚サイクルを断ち切ります。

エージェント workload の隔離 (VPC Service Controls perimeter)

• VPC Service Controls (VPC-SC) をエージェント workload のネットワークレベル・宛先ベースのペリメータとして設定します。有効な IAM 認証情報を持つ侵害済みエージェントからのデータ持ち出しも防げます。
• エージェントに IAM principal として個別アイデンティティを付与し、ingress/egress ルールで制御します。
• MCP ツール粒度の条件付きアクセスを設定します。read 権限のみを許可し、外部書き込みを明示的に拒否します。

責任境界とレビュー工程の再設計

• AI エージェントが生成したパッチの責任所在を人間が保持することを組織ポリシーで明文化します。AI の高い確信度スコアは人間の判断を代替しません。
• どのエージェント・モデル・バージョンが修正を生成したかを追跡できるよう provenance を整備します。SLSA の provenance 要件に対応する基盤になります。
• NIST SSDF (SP 800-218) の PW.4 (レビュー)・PW.8 (テスト) を AI 工程にマッピングし、既存の SDLC 証跡体系に統合します。
• 規制対応システム (金融・医療・個人情報処理) では、自律修正の適用範囲を事前に監査委員会と合意します。

SecOps の職務分解

自律化により SecOps の役割は「脆弱性を手動でトリアージ・修正する人」から「AI パイプラインを設計・監督・改善する人」へシフトします。

トラブルシューティング

反証・限界の明示 (過信しないための注意点)

• AI 生成パッチの品質懸念: 素朴な LLM ベースのコードスキャンの true-positive rate 7% 未満は、あくまで検出 (scan) 段階の指標であり、多段フィルタなしでは大半がノイズであることを意味します。これとは別に、AI 生成コード (パッチ) 自体が新たな脆弱性源になり得るという研究・観測報告もあります。検出精度とパッチ品質は分けて評価する必要があります。
• 自律修正の責任所在: AI が自律的にパッチを生成・適用しても、法的・規制的な責任は組織と人間エンジニアが負います。「検証済み」ラベルは人間の最終判断を代替しません。
• 規制・監査要件との整合: SLSA の provenance attestation、NIST SSDF の人間レビュー記録、OWASP の agentic AI リスク評価をそれぞれ別途満たす必要があります。AI 生成コードには従来のコミット履歴が乏しく、アーティファクト要件を満たすための工夫が要ります。
• 知識ストア汚染のリスク: 失敗した trajectory が成功として誤記録されると、Global Knowledge Store 経由で全エージェントの挙動が一様に劣化します。成功と誤記録は同じ形式を持つため検出が難しく、発覚の契機がパッチ品質の突然の低下になりがちです。記録条件に「regression 全通過」を課し、知識エントリへ品質スコアと有効期限を付与し、汚染時に切り戻せるよう知識ストアをバージョン管理することが対策になります。
• 適用条件: 本パターンは Google のような大規模セキュリティチームと成熟した ML インフラを前提とします。小規模組織では多段エージェントパイプラインの構築・保守コストが効果を上回るリスクがあります。自律 SDLC セキュリティは「人間不要」ではなく、人間の役割が「実行者」から「設計者・監督者」へ変化することを意味します。

まとめ

Google Cloud は社内のセキュリティ業務を、設計レビューからコードスキャン・動的テスト・パッチ生成・姿勢管理までを閉じた multi-agent のループとして再設計し、Reflection による知見の蓄積で精度を継続的に改善しています。本記事ではその 5 ステージ構成と中核 OSS である Mantis Skills、そして自律化に伴う人間の責任境界と限界までを構造化しました。AI に「何を任せ、どこに人間の判断を残すか」を設計する観点で読んでいただければ幸いです。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

一次情報 (Google 公式)

• Cloud CISO Perspectives: How Google Cloud Security uses AI internally (2026-06-30)
• Mantis Skills — GitHub (Apache-2.0)
• OSS-Fuzz-Gen — GitHub (LLM powered fuzzing via OSS-Fuzz)
• OSS-Fuzz — GitHub
• Securing agentic AI: What's new in VPC Service Controls (Google Cloud Blog)

系譜・関連プロジェクト

• Introducing CodeMender: an AI agent for code security — Google DeepMind
• Cloud CISO Perspectives: Our Big Sleep agent makes a big leap — Google Cloud Blog
• DARPA's AI Cyber Challenge reveals winning models — CyberScoop
• GTIG AI Threat Tracker — Google Cloud Blog

データモデル・標準

• SARIF v2.1.0 仕様 (OASIS)
• OSS-Fuzz LLM target generation 公式ドキュメント
• The 2026 Guide to Software Supply Chain Security (Cloudsmith)
• NIST SSDF (SP 800-218)
• SLSA Framework v1.0 仕様
• CVSS v3.1 Specification (FIRST)

反証・限界・運用知見

• Agentic Remediation: The New Control Layer for AI-Generated Code (Software Analyst)
• Addressing AI Hallucinations in Security Operations (Bridewell)
• Using LLMs to filter out false positives from static code analysis (Datadog)
• OWASP Top 10 for Large Language Model Applications
• OWASP Top 10 for Agentic AI Applications (Promptfoo)
• AI-Powered Vulnerability Detection and Patch Management: A Systematic Review (MDPI, 2025)
• A Survey on Agentic Security: Applications, Threats and Defenses (arXiv)